disque dur qui rame sur une vm linux lourde utilisation cpu mais pas tant de iops

valentine19 06/03/2026
RÉSOLU
valentine19
Auteur Actif
Avatar de valentine19
valentine19
Auteur Actif

salut la compagnie

on a une vm linux qui héberge une app critique et depuis hier elle rame de ouf. le souci c'est que les metrics iops montrent rien d'anormal genre 200-300 iops max. par contre le cpu est à 80-90% et l'application met un temps fou à répondre. j'ai l'impression que le disque est lent mais pourquoi le cpu est haut et les iops basses ? on est sur du ssd nvme sur le host


# exemple de commande que j'ai lancée
iostat -dx 1
06/03/2026 à 10:18

10 commentaires

perrier-thierry
Membre Actif
Avatar de perrier-thierry
perrier-thierry
Membre Actif

yo

c'est ptete pas les iops qui sont le souci mais la latence. regarde le %util dans iostat s'il est proche de 100% même avec peu d'iops ça veut dire que le disque est saturé en temps d'accès. et await ou svctm pour la latence par opération. aussi check le vmstat -w 1 pour voir le wa (wait i/o) du cpu

Modifié le 23/05/2026 à 16:20
valentine19
Auteur Actif
Avatar de valentine19
valentine19
Auteur Actif

le %util est bien à 100% et await à plus de 100ms. le wa est aussi super haut sur vmstat. donc ouais ça confirme le disque lent. mais pourquoi alors qu'on est sur nvme et que les iops sont faibles ?

Modifié le 23/05/2026 à 16:20
gilles-descamps
Membre Actif Secouriste
Avatar de gilles-descamps
gilles-descamps
Membre Actif Secouriste

t'es sur quelle techno de virtualisation ? esxi kvm ? des fois c'est la config du controller disque virtuel qui est pas opti. genre tu as combien de queues pour le vdisk ? et la taille des requêtes aussi ça joue. si ton app fait plein de petites écritures aléatoires ça peut saturer la queue du disque même si le volume global de data est faible

09/03/2026 à 02:43
paris-christophe
Membre Actif
Avatar de paris-christophe
paris-christophe
Membre Actif

et le cache de la vm ? t'es en write-through ou write-back ? write-back c'est plus performant mais si y'a un souci de flush ou de cache size ça peut bloquer. aussi le scheduler i/o dans la vm. t'es sur cfq, deadline ou noop ? noop est souvent meilleur pour les vms avec un bon hyperviseur

Modifié le 23/05/2026 à 16:20
valentine19
Auteur Actif
Avatar de valentine19
valentine19
Auteur Actif

on est sur kvm. j'ai regardé le scheduler c'était cfq. je vais essayer noop. pour le cache j'ai pas la main sur la config kvm faut que je vois avec l'infra

Modifié le 23/05/2026 à 16:20
perrier-thierry
Membre Actif
Avatar de perrier-thierry
perrier-thierry
Membre Actif

oui cfq c'est à bannir pour les vms. noop ou deadline c'est mieux. noop délègue la gestion de l'ordre à l'hyperviseur et au disque physique. deadline est pas mal pour équilibrer latence et throughput. test noop en premier

Modifié le 23/05/2026 à 16:20
gilles-descamps
Membre Actif Secouriste
Avatar de gilles-descamps
gilles-descamps
Membre Actif Secouriste

fais un cat /sys/block/sdX/queue/rotational pour t'assurer qu'il voit bien un ssd (retourne 0). et vérifie la taille des blocs logique et physique avec fdisk -l ou blockdev --getbsz /dev/sdX. si l'appli écrit avec des blocs beaucoup plus petits que le bloc physique du disque ça fait plein de petites iops qui créent de la latence

Modifié le 23/05/2026 à 16:20
valentine19
Auteur Actif
Avatar de valentine19
valentine19
Auteur Actif

j'ai mis le scheduler à noop et c'est déjà mieux. le wa a bien chuté. mais c'est pas encore parfait le await est toujours un peu haut

Modifié le 23/05/2026 à 16:20
paris-christophe
Membre Actif
Avatar de paris-christophe
paris-christophe
Membre Actif

reste la taille des requêtes et le cache. si l'appli fait des milliers de petites requêtes de 4kb et que ton bloc nvme est à 64kb ça va être inefficace. et si le cache kvm est en write-through ou limité en taille ça va pas aider à absorber les pics. faut voir avec l'infra pour optimiser ça côté hyperviseur

14/03/2026 à 09:26
valentine19
Auteur Actif
Avatar de valentine19
valentine19
Auteur Actif

ok le passage à noop a réglé une bonne partie du problème. pour le reste c'était bien le cache kvm qui était pas opti et la taille des blocs de l'appli qui était pas alignée avec le disque. on a ajusté côté hyperviseur et l'appli tourne comme un charme maintenant. merci à tous pour les pistes !

Modifié le 23/05/2026 à 16:20

Laisser une réponse

Vous devez être connecté pour poster un message !

Rejoindre la communauté

Recevoir les derniers articles gratuitement en créant un compte !

S'inscrire