hello t'as check si d'autres process que postgres n'utilisent pas le disque regarde avec iostat -xz 1 ou pidstat -d 1 pour voir qui bouffe les i/o
ouais j'ai fait ça et c'est bien postgres qui est en tête des i/o avec son process principal et ses workers. mais le volume total d'iops est pas si élevé comparé à ce qu'on devrait avoir sur du nvme
c'est peut-être pas un problème de volume d'iops mais de latence individuelle des i/o. t'as des outils pour mesurer la latence des i/o genre fio ou des métriques du kernel direct sur les disques sous-jacents pas juste sur le lvm
si c'est une vm assure-toi que le virtio-scsi est bien utilisé et que t'as pas de souci de file d'attente i/o au niveau de l'hyperviseur des fois le host est surchargé et ça impacte les invités même si les disques sont rapides
alors en fait en creusant côté hyperviseur et en regardant les métriques du SAN (on est sur du fibre channel derrière) il y avait bien un souci de qdepth trop faible sur les chemins d'accès au stockage. les disques étaient rapides mais la file d'attente était saturée très vite. le provider a ajusté la config
après l'ajustement c'est tombé à 5% d'i/o wait c'est le jour et la nuit. merci pour l'aide les gars la piste hyperviseur/san était la bonne
Vous devez être connecté pour poster un message !
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
alphonse20
Membre depuis le 01/01/2025actif
salut la commu
j'ai un serveur db (postgresql) qui tourne sur une vm linux et depuis quelques jours on a des pics d'i/o wait qui monte à 80-90%. la db est sur un LVM au-dessus d'un raid logiciel. les disques sous-jacents sont censés être des SSD NVMe performants mais la situation est intenable
j'ai vérifié les logs postgres pas d'énormes requêtes cheloues pas de gros vacuum qui tourne. le monitoring montre que le read/write iops est pas non plus délirant comparé à la capacité des disques. ça sent le mystère