6 commentaires
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
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
Laisser une réponse
Vous devez être connecté pour poster un message !
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