18 commentaires
hello ! io_uring sur postgres c'est pas plug-and-play. il faut que postgres soit compilé avec le support. t'es sûr de ta compilation ? et surtout quel mode d'io_uring ? poll ou non ?
oui compilé avec. j'ai les options qui vont bien. par défaut c'est pas du poll je crois. il faut activer IORING_SETUP_SQPOLL c'est ça ?
exactement ! sans SQPOLL c'est juste un AIO amélioré. SQPOLL est crucial pour la latence. faut le configurer au niveau de l'instance d'io_uring ou par le code de postgres si c'est géré
donc en gros faut que postgres ouvre son io_uring avec cette flag. mais comment je vérifie que c'est bien le cas ? et y a d'autres tunings ?
pas simple de vérifier à chaud sauf à regarder les traces syscalls genre strace -e io_uring_enter mais ça va ralentir encore. si t'as le code de postgres faut voir comment c'est appelé. sinon regarde le blockdev --report pour le device sous-jacent. quel type de nvme t'as ?
c'est du nvme pcie gen4. le blockdev est ok. j'ai pas vu d'options spécifiques pour io_uring dans postgres.conf
non y'en a pas direct dans postgres.conf. c'est plus bas niveau. regarde aussi ta queue depth pour l'io_uring. trop faible ça bride, trop haute ça ajoute de la latence. par défaut c'est 256 je crois
comment je modifie la queue depth pour postgres ? c'est pas par io_uring_setup ?
oui c par l'appel io_uring_setup. si postgres gère pas ça, t'es bloqué. mais une autre piste, est-ce que tu utilises direct_io ? ça peut interagir bizarrement avec io_uring sans un bon tuning
direct_io oui c'est actif. je suis en train de relire les docs kernel et postgres. il semble que postgres n'expose pas directement le tuning de io_uring comme SQPOLL
c'est ça le souci. la plupart des apps n'utilisent io_uring qu'en mode "basic" sans profiter des features type sqpoll ou ioring_feat_nodrop. et si direct_io est actif assure-toi d'avoir aligné tes buffers correctement.
ok donc mon souci c ptete que j'ai compilé postgres avec io_uring mais sans les features avancées qui font la diff. je suis en train de tester sans direct_io pour voir si ça change
sans direct_io tu peux avoir des problèmes de double-caching avec le page cache du kernel. ça va ptete améliorer des trucs mais en rajouter d'autres. le mieux c de recompiler postgres avec un patch qui expose SQPOLL ou d'utiliser un patch existant
j'ai trouvé un patch communautaire pour postgres qui expose SQPOLL et permet de tunner le ring size. je vais tenter de recompiler avec ça
c'est la meilleure approche. une fois recompilé, surveille bien les métriques i/o. iostat -x et pidstat -d devraient te donner des infos sur les iodelay et la latence
recompilé et déployé avec le patch. j'ai activé SQPOLL avec un ring size de 4096. les perfs sont revenues à la normale même mieux. le cpu est un peu plus sollicité pour les IO mais la latence est dingue
top ! c'est le gain de SQPOLL. moins de context switch entre user et kernel space. content que ça ait marché. merci du retour
ouais c'est clairement ça ! merci pour l'aide c'était super pointu comme problème sans toi j'aurais tourné en rond
Laisser une réponse
Vous devez être connecté pour poster un message !
Bon on vient de migrer une grosse base postgres sur un nouveau serveur avec un kernel 6.x pour profiter de io_uring. sauf que les perfs sont bof voire pires. les requêtes sont lentes les iops disque sont là mais le cpu est pas hyper chargé. j'ai l'impression que le postgres n'utilise pas bien io_uring ou qu'il y a un truc à tunner