io_uring pour perf postgres vs libaio
Commentaires
ouais "io_uring" c'est le futur clair. "libaio" est un peu legacy. le gain dépend bcp de ton workload. si tu fais bcp de petits random reads/writes le gain est énorme. pour du séquentiel c'est moins flagrant.
attention postgres ne supporte pas "io_uring" nativement pour l'instant sauf via des patches non officiels ou des versions très spécifiques. tu vas dans une zone dangereuse pour de la prod. et "fdatasync" est déjà pas mal opti
oui je sais pour le patch c'est ça qui m'inquiète un peu. mais le bench fait rêver. on a un mix de petits writes concurrents et quelques gros reads séquentiels.
le vrai avantage de "io_uring" c le batching des opérations et le fait que ça évite le passage kernel/userspace pour chaque op. ça réduit les syscalls et le context switching.
t'as regardé du côté de l'optimisation du scheduler I/O ? genre passer de "mq-deadline" à "bfq" ou "none" si tu es sur NVMe ? ça a plus d'impact direct et c'est moins risqué qu'un patch postgres
on est sur nvme donc "none" est déjà configuré. c'est pour ça que je cherche des gains plus profonds. la latence disk est déjà super basse.
t'as des métriques iops/latence pour tes workloads ? avec un "fio" par ex tu peux simuler ton pattern et voir la différence entre "libaio" et "io_uring" sans toucher à postgres
bonne idée. j'ai des "pg_stat_statements" qui montrent pas mal de requêtes avec des "read_time" et "write_time" élevés. je vais essayer de reproduire le pattern avec "fio"
même avec "io_uring" t'auras pas de miracles si ton schéma est pas opti ou si tes requêtes sont mal écrites. les indexes sont bons ? pas de full table scans ?
oui les requêtes sont auditées et optimisées régulièrement. c'est vraiment un problème de débit I/O sous forte charge concurrentielle.
si tu vas sur "io_uring" via patch, faut s'assurer que tu peux le maintenir. c'est un engagement. et tester à mort. les risques de corruption de données sont pas nuls si le patch est pas stable.
un truc moins risqué et qui peut aider c'est d'utiliser des "hugepages" pour "shared_buffers". ça réduit la pression sur le TLB et ça peut donner un petit boost
j'utilise déjà les hugepages. pour l'instant je vais me concentrer sur le "fio" benchmark pour valider le gain potentiel. si c'est +20-30% on pourrait envisager le patch.
keep us updated ! c'est un sujet chaud "io_uring" avec pg.
après le bench "fio" avec un pattern mixte j'obtiens des latences 30% plus basses en moyenne avec "io_uring" vs "libaio" pour la même charge. le gain est clair. on va tenter le patch sur un env de staging et voir la stabilité. merci les gars pour les inputs c'est super utile
Laisser une réponse
Vous devez être connecté pour poster un message !
Rejoindre la communauté
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
xjacquot
Membre depuis le 10/06/2019
actif
salut les sysadmins. j'essaie d'optimiser les perf d'une db postgres 15 sur une grosse machine linux (ubuntu 22.04, kernel 6.2). on utilise "fsync=fdatasync" et "full_page_writes=on". je me demande si passer à "io_uring" pour le système d'io à la place de "libaio" (via "data_checksums=on" et un patch custom ou une future version de pg) pourrait donner un boost significatif. quelqu'un a déjà testé ça en prod sur des workloads intensifs ?