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

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

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

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.

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.

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.

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

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

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.

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

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.

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.

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

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.

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

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

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.