4 commentaires
yo le mq-deadline c'est bien mais pour le nvme des fois none ou noop est mieux. essaie de le changer avec echo none > /sys/block/nvme0n1/queue/scheduler et vois si ça change quelque chose. et la taille des blocs de ton filesystem ? si tu as de petits fichiers et un gros block size ça peut être inefficace
t'as regardé la queue depth de ton postgres ou de ton app ? si elle est trop faible tu n'envoies pas assez de requêtes i/o en parallèle au disque pour le saturer de manière efficace. et aussi check le swappiness. si tu swap ça flingue les perfs i/o même avec du nvme
un truc à ne pas négliger c'est le monitoring des métriques nvme direct via nvme-cli. ça te donnera des infos plus fines sur le disque que iostat. des fois les drivers linux ou le firmware nvme ont des soucis. et les m5d sont partagées entre plusieurs instances sur un même host physique aws attention aux voisins bruyants
ok merci pour les tips. après pas mal de tests j'ai switché le scheduler à none c'était un peu mieux. mais le vrai game changer a été d'augmenter la queue depth de postgres et d'ajuster le commit_delay. et le swappiness était bien réglé. maintenant l'iostat est plus cohérent avec les specs de l'instance. merci la team
Laisser une réponse
Vous devez être connecté pour poster un message !
salut les pros du kernel. j'ai un problème de perf i/o sur des instances ec2 m5d (nvme local storage) sur lesquelles on a des bases de données postgres. l'iostat montre que le disque est à 100% busy la plupart du temps mais le débit est pas énorme genre 200MB/s alors que les m5d sont censées taper beaucoup plus. on a monté les volumes avec noatime et des options de performance. le scheduler i/o est en mq-deadline. des pistes pour optimiser ?