Perf écriture PostgreSQL catastrophique avec io_uring sur nvme

Question

Salut à tous. On a migré nos bases pgsql sur des NVMe en utilisant io_uring via un custom build de pg. on s'attendait à des perfs de malade mais au lieu de ça les writes sont ultra lents les fsync prennent des plombes. j'ai un doute sur la config kernel ou io_uring-- query qui rame
INSERT INTO huge_table (data) VALUES (...);
-- explication
-- ça fait des batchs de 10k inserts et ça prend 20s au lieu de 2s avantuname -a: Linux myhost 5.15.0-xx-generic #yy-Ubuntu SMP ... x86_64 x86_64 x86_64 GNU/Linux

noemi38 · Answer

io_uring c'est super complexe déjà quel type de submition tu utilises IORING_SETUP_SQPOLL ou le mode plus simple

gallet-laurence · Answer

on est en IORING_SETUP_SQPOLL c'est censé être le plus perf j'ai vérifié le code de pg le pooler kernel thread est actif

noemi38 · Answer

ok et quel scheduler i/o est actif sur tes nvme cat /sys/block/nvme0n1/queue/scheduler normalement c'est none pour nvme si t'es sur un kernel récent

gallet-laurence · Answer

c'est bien none déjà vérifié mais j'ai un doute sur le nr_requests combien de requêtes tu laisses en vol pour les async i/o

fherve · Answer

pour pgsql des fois c'est pas juste l'io_uring mais ta config pgsql le wal_sync_method par exemple si tu forces fsync ou fdatasync et full_page_writes est à on

gallet-laurence · Answer

oui wal_sync_method = fdatasync et full_page_writes = on c le setup classique pour la durabilité. on peut pas y toucher

noemi38 · Answer

c'est normal fdatasync et full_page_writes c'est pour la sécurité. par contre io_uring avec fdatasync peut être contre-productif si t'as pas une bonne queue depth. et les nvme sont pas tous égaux

gallet-laurence · Answer

on a des samsung pcie gen4. je suis à 128 pour nr_requests pour l'instant je vais essayer de monter ça

noemi38 · Answer

128 c'est déjà pas mal. t'as vérifié les io_uring_stats du kernel? cat /proc/sys/fs/io_uring/pids tu peux voir les stats globales et par process

gallet-laurence · Answer

non pas encore j'avoue je savais même pas pour ce fichier. je vais regarder ça

fherve · Answer

et n'oublie pas vm.dirty_background_ratio et vm.dirty_ratio si tu as trop de dirty pages en RAM et que le kernel doit les flush d'un coup ça peut bloquer ton i/o même si c'est du nvme

gallet-laurence · Answer

bonne piste pour les dirty pages. on a 256GB de RAM sur le serveur et les ratios sont à 10%/20% donc 25GB de dirty pages ça peut être énorme

noemi38 · Answer

exact pour les dirty pages. si tu as une charge d'écriture constante et que ton kernel flush tout d'un coup tu vas voir des spikes de latence. essaie de les baisser par exemple à 2% et 5%

gallet-laurence · Answer

ok j'ai mis vm.dirty_background_ratio = 2 et vm.dirty_ratio = 5. les écritures sont un peu mieux mais toujours pas le gain espéré avec io_uring

noemi38 · Answer

io_uring est pas toujours un gain pour des workloads avec beaucoup de fsync ou fdatasync si tu fais beaucoup de petites écritures aléatoires O_DIRECT peut être plus simple ou même l'approche classique mmap. et pour pgsql la taille des WAL segments ça joue aussi

fherve · Answer

totalement. et si io_uring est pas compilé avec les bonnes options ou si le kernel a un bug avec ta version de pg. faut aussi regarder les waits dans pg stat_activity wait_event_type: IO et wait_event: wal_sync

gallet-laurence · Answer

ok on va revoir la strat. je pense qu'on va revenir à un pgsql vanilla et voir les perf avec le fdatasync normal. le gain io_uring est peut être pas pour notre workload ou alors c'est trop de tweaking kernel. merci pour toutes les idées c'était super utile

Perf écriture PostgreSQL catastrophique avec io_uring sur nvme

17 commentaires

Laisser une réponse

Fonctionnement et manipulation du réseau dans Docker

Les différents objets et composants de Kubernetes

Comprendre et utiliser Filebeat dans la stack ELK

Policy-as-Code : La Révolution de la Gouvernance Holistique en DevOps

Bio-Inspired DevOps : Quand l'Infrastructure Respire et Évolue

Rejoindre la communauté