16 commentaires
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
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
Laisser une réponse
Vous devez être connecté pour poster un message !
salut la gang on a upgradé notre kernel de 5.10 à 5.15 sur nos serveurs de base de données PostgreSQL et depuis on a des requêtes hyper lentes sur les gros selects qui tapent beaucoup sur le disque. on utilise des NVMe et on s'attendait à des perfs de ouf avec io_uring mais c'est l'inverse