PostgreSQL rame après kernel upgrade avec io_uring

hmm intéressant t'as quelle version de PG et comment tu utilises io_uring avec PG c'est via des settings spécifiques ou juste le kernel sous-jacent

pg 14.5. on a pas de settings pg spécifiques pour io_uring. on pensait que le kernel allait gérer ça tout seul. la seule chose qu'on a fait c'est s'assurer que io_uring est compilé dans le kernel. on a des params `shared_buffers` à 16gb et `wal_buffers` à 16mb

c'est le piège io_uring c'est pas magique faut que les applis l'utilisent explicitement ou que le système de fichiers supporte l'interface aio. t'es sur quel fs ext4 xfs

on est sur XFS. les `EXPLAIN ANALYZE` montrent que c'est le `Seq Scan` qui prend un temps fou le `Shared Hit Ratio` est bon mais le `Disk Read` s'envole

ok xfs c'est bon. pour les nvme t'as quoi comme scheduler i/o par défaut `none` `mq-deadline` t'as essayé de changer ça après l'upgrade kernel

c sur `none` par défaut vu que c NVMe j'ai pas touché. j'ai juste mis `deadline` sur d'autres disques SATA mais pas les NVMe

`none` c'est le bon pour NVMe. le souci c'est ptete pas io_uring direct mais plutôt comment PG interagit avec le VFS et le scheduler CPU. t'as vérifié les `vm.dirty_ratio` et `vm.dirty_background_ratio` ça a pu changer de comportement entre tes kernels

j'ai les valeurs par défaut genre 20 et 10%. c beaucoup pour de la DB je sais mais ça fonctionnait avant. on utilise aussi `fsync = on`

`fsync=on` c'est critique oui. essaie de descendre tes `dirty_ratio` à 5 et 2% pour voir si ça réduit la latence sur les gros `checkpoint` qui sont des I/O sync. aussi check le `vm.swappiness` s'il est pas à 60 ou plus réduis-le à 1 ou 10

j'ai baissé les `dirty_ratio` et `swappiness` à 1 mais pas de changement significatif. les `Seq Scan` sont toujours aussi lents

t'as regardé les métriques I/O du disque avec `iostat -x 1` pendant que ça rame ? regarde `await` et `%util` si `await` est haut mais `%util` est bas t'as un souci de profondeur de queue ou de contention logicielle

`await` est à 50-60ms pour les nvme mais le `%util` est à 30%. c'est bizarre ça veut dire que le disque est pas saturé mais l'os met du temps à servir les requêtes

exactement. c'est là que le scheduler CPU entre en jeu. avec un kernel plus récent y'a des changements dans le CFS. t'as ptete des cgroups qui limitent sans le savoir ou un `isolcpus` mal réglé. ou même le `numa` si t'es sur un gros serveur

pas de cgroups ni `isolcpus`. le serveur est numa. on a pas touché au bind des procs/mémoire. j'ai lu que `io_uring` peut être sensible aux numéros de cpu et numa. faudrait ptete forcer les procs PG à rester sur le même node numa que le disque NVMe

c'est une excellente piste essaie `numactl --membind=N --cpunodebind=N` pour démarrer ton PG sur un seul node numa le plus proche des NVMe. et aussi regarde si t'as le patch `IORING_FEAT_NODROP` bien activé dans ton kernel 5.15 il aide pour les perfs io_uring intensives

bingo ! j'ai forcé le bind numa sur le PG et les NVMe sur le même node et les `Seq Scan` sont revenus à la normale. le `await` est redescendu à 5ms. c'était bien un souci d'alignement numa avec la gestion I/O du nouveau kernel. un grand merci pour l'aide