Performance I/O catastrophique sur VM Linux en prod

RSS
alix90 13/05/2025
RÉSOLU
Retour Répondre
Avatar de alix90
alix90
Auteur Actif
Avatar de alix90
alix90
Auteur Actif

salut les pros

j'ai une vm linux (ubuntu 20.04) sur laquelle tourne une app critique. depuis hier on a des lags monstres des fois pendant 30s l'app est injoignable ou prend des plombes pour répondre. j'ai l'impression que c'est lié aux I/O disque parce que les logs montrent des 

io_wait
de ouf et le 
iostat -x 1
monte à 100% utilisation sur le disque système.

le truc c'est que la charge cpu est faible la mémoire est ok. on n'a pas de gros batch I/O qui tourne. j'ai check les métriques de notre hyperviseur (vmware) les iops sont stables pas de pic flagrant. 

atop
ou 
iotop
montrent rien de particulier aucune application ne semble monopoliser le disque. des pistes pour ce mystère ?

13/05/2025 à 18:59

8 commentaires

Avatar de lmarty
lmarty
Membre Actif
Avatar de lmarty
lmarty
Membre Actif

salut

tu as regardé du côté du scheduler i/o ? le default pour la plupart des distros est 

mq-deadline
mais des fois si tu as des workloads très spécifiques genre bdd avec plein de petites requetes random ça peut être mieux de passer sur 
noop
ou 
bfq
. teste avec 
cat /sys/block/sdX/queue/scheduler

14/05/2025 à 14:35
Avatar de thierry-brun
thierry-brun
Membre
Avatar de thierry-brun
thierry-brun
Membre

et les 

vm.dirty_ratio
vm.dirty_background_ratio
tu les as ajustés ? si ton app écrit beaucoup et que ces buffers sont trop petits le kernel va devoir flusher agressivement et ça peut bloquer. surtout avec une petite vmware disk cache

15/05/2025 à 09:33
Avatar de alix90
alix90
Auteur Actif
Avatar de alix90
alix90
Auteur Actif

le scheduler est bien 

mq-deadline
. j'ai pas touché aux dirty_ratio c'est les valeurs par defaut. l'app fait pas tant d'écriture que ça c'est surtout des lectures et qques petites écritures de logs. c'est la lecture qui me parait lente

16/05/2025 à 06:41
Avatar de rmartineau
rmartineau
Membre
Avatar de rmartineau
rmartineau
Membre

t'as vérifié si le disque est pas en train de se remplir dangereusement ? genre 90%+ plein. des fois ça peut impacter les perfs de ouf. aussi regarde 

dmesg | grep -i error
pour voir si le kernel ne rapporte pas des erreurs disque

17/05/2025 à 04:31
Avatar de lmarty
lmarty
Membre Actif
Avatar de lmarty
lmarty
Membre Actif

des trucs côté hyperviseur ? parfois les SAN ou le stockage partagé derrière ont des soucis de contention que tu ne vois pas au niveau de la VM. Ou un autre VM sur le même datastore qui fait n'importe quoi en I/O et qui impacte tout le monde

18/05/2025 à 01:20
Avatar de alix90
alix90
Auteur Actif
Avatar de alix90
alix90
Auteur Actif

disque à 60% plein c'est ok. dmesg clean. côté hyperviseur non les métriques de latency et iops sur le datastore sont niquels. et on a mis la vm sur un datastore peu chargé. par contre j'ai vu des 

jbd2/dm-0-8
qui consomment pas mal d'iops quand ça merde, c'est le journal ext4

18/05/2025 à 22:10
Avatar de thierry-brun
thierry-brun
Membre
Avatar de thierry-brun
thierry-brun
Membre

jbd2 qui tourne à fond ça sent la corruption ou un fsck qui se passe mal au boot. t'as tenté un 

fsck -f /dev/sdX
après un unmount ou en mode rescue ? ça peut purger des problèmes. ou un 
tune2fs -l /dev/sdx | grep 'maximum mount count'
pour voir si t'es pas trop près du max et qu'il force le check

19/05/2025 à 16:38
Avatar de alix90
alix90
Auteur Actif
Avatar de alix90
alix90
Auteur Actif

bingo c'était ça ! le mount count était très haut et un fsck forcé en mode rescue a trouvé et réparé des petites inconsistances. depuis ça tourne nickel. thx la team c'était bien relou ce truc !

20/05/2025 à 16:17

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