io_uring pour perf postgres vs libaio

Question

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 ?
# current postgres config relevant to IO
shared_buffers = 12GB
effective_cache_size = 36GB
wal_buffers = 16MB
min_wal_size = 4GB
max_wal_size = 16GB
checkpoint_timeout = 5min
max_worker_processes = 16
max_parallel_workers = 16
max_parallel_workers_per_gather = 4

emile66 · Answer

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.

margaud53 · Answer

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

xjacquot · Answer

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.

emile66 · Answer

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.

margaud53 · Answer

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

xjacquot · Answer

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.

emile66 · Answer

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

xjacquot · Answer

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"

margaud53 · Answer

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 ?

xjacquot · Answer

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.

emile66 · Answer

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.

margaud53 · Answer

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

xjacquot · Answer

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.

emile66 · Answer

keep us updated ! c'est un sujet chaud "io_uring" avec pg.

xjacquot · Answer

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

io_uring pour perf postgres vs libaio

15 commentaires

Laisser une réponse

Création d'une fenêtre et d'un rendu sur la SDL 2

Découverte et installation de Docker

Internal Developer Platforms (IDP) : Libérez le Potentiel de vos Développeurs

Blindez votre DevOps : Sécurité de la Chaîne Logicielle

eBPF : Le Superpouvoir DevOps pour l'Observabilité et la Sécurité

Rejoindre la communauté