Sujet :
linux perf disk i/o sature sur ec2 m5d des idées
RÉSOLU
Liste des sujets Répondre Créer un sujet
Membre depuis le 29/05/2024
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 ?
# iostat -x 1
avg-cpu: %user %nice %system %iowait %steal %idle
5.20 0.00 3.50 50.10 0.00 41.20
Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm svctm %util
nvme0n1 120.00 1000.00 5000.00 200000.00 0.00 0.00 0.00 0.00 8.00 100.00
Répondre
vous devez être connecté pour poster un message !
Rejoindre la communauté
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
joseph79
Membre depuis le 31/05/2024
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
margaret04
Membre depuis le 22/05/2024
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
gaillard-bernadette
Membre depuis le 28/05/2024
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
carpentier-aurore
Membre depuis le 29/05/2024
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