PostgreSQL avec io_uring, latences I/O aléatoires sous forte charge

Question

salut les gars on a upgradé nos PG vers 14 et activé io_uring pour les I/O async. au début c'était top mais sous forte charge de requêtes on se prend des latences I/O de ouf. des fois ça monte à 500ms pour des reads ou writes. pourtant le disque est un NVMe ultra rapide. on s'attendait à mieux. # postgresql.conf
shared_buffers = 16GB
wal_buffers = 1GB
max_connections = 500
wal_writer_delay = 200ms
maintenance_work_mem = 2GB
# io_uring activé via psql -c "ALTER SYSTEM SET wal_writer_flush_method = 'io_uring'"on est sur un kernel 5.15

emilie-legoff · Answer

hmm io_uring c'est super mais faut voir la version de ton kernel. 5.15 c'est ok mais t'as vérifié les sysctls pour io_uring? genre /proc/sys/fs/io_uring/max_submission_entries. et t'as checké pg_stat_io pour voir où sont les latences, read/write data/wal

fpons · Answer

et ton filesystem c quoi? xfs? ext4? et les mount options? noatime nodiratime sont là? des fois juste ça ça change tout avec des gros volumes de logs

luce76 · Answer

kernel 5.15.0-xx. xfs avec noatime et nodiratime. les stats pg_stat_io montrent des hits de ouf sur wal_fsync mais aussi sur la data. c'est surtout les writes qui bloquent. les sysctls io_uring sont aux valeurs par défaut max_submission_entries 4096.

emilie-legoff · Answer

le truc c'est que io_uring c'est super pour les I/O async mais postgres se repose beaucoup sur fsync pour la durabilité. si tes fsync sont lents io_uring va pas magiquement les accélérer. ça pourrait être un souci de writeback du kernel.

luce76 · Answer

ouais j'ai l'impression que c'est vraiment le fsync qui prend des plombes. surtout quand y a un gros commit ou plein de petites transactions en même temps.

emilie-legoff · Answer

t'as essayé un strace -p pid_du_postgres pour voir les appels io_uring_enter et les fsyncs? et checke tes sysctls vm.dirty_background_ratio et vm.dirty_ratio. si c'est trop haut le kernel garde trop de pages sales en RAM et quand il flush c'est la cata

luce76 · Answer

le strace montre des fsyncs qui prennent parfois des centaines de ms. et vm.dirty_ratio est à 20% et dirty_background_ratio à 10%. ça me semble pas si énorme pour un serveur avec 256GB de RAM. mais quand ça flush ça flush sale

emilie-legoff · Answer

c quelle marque ton NVMe? et le firmware à jour? des fois certains contrôleurs ont des pbs avec io_uring sous charge. c rare mais ça arrive.

luce76 · Answer

c'est un samsung 980 pro. firmware à jour. pas de problème identifié de ce côté-là avec io_uring sur d'autres apps. c'est vraiment lié à la façon dont PG utilise fsync avec ça

emilie-legoff · Answer

on dirait un problème de réglage entre le comportement de pg qui veut la durabilité et le kernel qui gère le writeback. ptete tenter de réduire vm.dirty_background_bytes et vm.dirty_bytes à des valeurs fixes plus petites. genre 512mb pour background et 1gb pour dirty. ça force le kernel à flusher plus souvent mais en plus petites quantités.

luce76 · Answer

ok je vais tester de baisser ces valeurs via sysctl. ça va augmenter le nombre de fsyncs mais si chaque fsync est rapide ça devrait être mieux que des gros blocs.

emilie-legoff · Answer

exactement. l'idée c'est de lisser le trafic I/O. io_uring peut gérer plein de petites ops concurrentes c'est son avantage. mais si un fsync unique doit écrire des dizaines de gigas au disque ça va bloquer même avec io_uring pour les writes non fsyncés

luce76 · Answer

après quelques heures de test avec les nouveaux sysctls ça a l'air beaucoup mieux. les pics de latence I/O sont moins fréquents et moins hauts. le système semble plus réactif sous charge.

emilie-legoff · Answer

nickel. et pour aller plus loin tu peux regarder les cgroups pour le i/o throttling si tu as des briques qui se disputent le disque. mais c une autre bataille

luce76 · Answer

oui cgroups c'est un autre level. pour l'instant cette optimisation me sauve la mise.

luce76 · Answer

merci pour le coup de main c'était bien un souci de synchronisation du writeback du kernel avec la charge de fsync de postgres. les sysctls vm.dirty_bytes et background ont fait le taf.

PostgreSQL avec io_uring, latences I/O aléatoires sous forte charge

16 commentaires

Laisser une réponse

Introduction au rapport DORA

Ambient Mesh : Simplifiez vos microservices, réinventez l'orchestration et la sécurité

Cyber-Immunity Autonome : Quand l'Infra DevOps s'Auto-Défend

Déployez vos microservices Rust en Unikernels avec NanoVMs

Sécurisez vos secrets Kubernetes en 5 minutes chrono

Rejoindre la communauté