Perf écriture PostgreSQL catastrophique avec io_uring sur nvme

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

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

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

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

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

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

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

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

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

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

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

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

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%

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

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

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`

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