iowait de ouf sur nvme sous linux en prod pourquoi

denis-hamon 06/06/2024
RÉSOLU
denis-hamon
Auteur
Avatar de denis-hamon
denis-hamon
Auteur

salut la gang. on a des instances vmware avec des nvme pas des disques virtuels mais des nvme passthrough direct. et on a une charge de iowait ultra élevée genre 50-60% sur des applis qui font pourtant pas des millions d'iops. on est sous ubuntu 22.04 avec un kernel 5.15. la commande iostat -x 1 montre des %util à 100% mais les r/s et w/s sont pas si dingues. c'est quoi le délire ?

# extrait de iostat -x 1 (synthétisé)
Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm aqu-sz await  %util
nvme0n1         100.0   200.0    1024.0    2048.0      0.0      0.0    0.0    0.0  25.0  250.0  100.0
06/06/2024 à 08:47

8 commentaires

christelle39
Membre Actif Secouriste
Avatar de christelle39
christelle39
Membre Actif Secouriste

yo. le aqu-sz élevé et l'await qui suit avec %util à 100% alors que r/s w/s sont pas oufs ça sent la petite écriture synchrone qui bloque tout ou des requêtes avec une taille d'i/o super petites. regarde vmstat -w 1 pour les wait stats et strace sur tes process pour voir les calls read/write et leurs flags.

07/06/2024 à 04:54
wperret
Membre Actif
Avatar de wperret
wperret
Membre Actif

ouaip et check la block size de ton filesystem. si t'es en 4k et que tes applis écrivent en 512 bytes par exemple ça peut créer bcp d'overhead pour rien. aussi le scheduler i/o. t'es en mq-deadline ou none ? pour le nvme none est souvent mieux.

08/06/2024 à 01:31
delaunay-elodie
Membre Actif Secouriste
Avatar de delaunay-elodie
delaunay-elodie
Membre Actif Secouriste

t'as des snapshots vmware sur ces vm là ? ou des backups en cours ? ça peut générer du iowait fantôme si le disque est figé ou si les i/o sont redirigées temporairement vers des delta disks.

09/06/2024 à 00:53
denis-hamon
Auteur
Avatar de denis-hamon
denis-hamon
Auteur

non pas de snapshots ni backups en cours. pour le block size du fs c'est du 4k comme l'appli envoie. le scheduler est mq-deadline par défaut. j'ai pas pensé à none. je vais voir les strace.

09/06/2024 à 23:36
christelle39
Membre Actif Secouriste
Avatar de christelle39
christelle39
Membre Actif Secouriste

pour le scheduler teste 'none' oui. echo 'none' > /sys/block/nvme0n1/queue/scheduler. ça désactive la réordonnancement des i/o pour les nvme qui ont déjà leur propre queue management. souvent ça drop l'iowait pour les workloads à forte concurrence.

10/06/2024 à 22:11
wperret
Membre Actif
Avatar de wperret
wperret
Membre Actif

aussi check la queue depth de l'nvme lui-même. si l'appli est trop agressive avec des requêtes trop profondes ça peut saturer le contrôleur. et si c'est du vmware passthrough assure-toi que les vmxnet3 sont à jour et que le driver nvme est le bon sur le guest.

11/06/2024 à 20:45
delaunay-elodie
Membre Actif Secouriste
Avatar de delaunay-elodie
delaunay-elodie
Membre Actif Secouriste

un dernier truc chiant si t'as plusieurs nvme en raid logiciel (mdadm) assure-toi d'avoir une bonne taille de stripe. si la stripe est trop petite ça peut bottleneck même avec des nvme rapides.

12/06/2024 à 19:28
denis-hamon
Auteur
Avatar de denis-hamon
denis-hamon
Auteur

merci les gars ! le switch à 'none' pour le scheduler a fait une différence monstreuse, on est tombé à 5-10% iowait. et on avait effectivement des petites écritures fréquentes, on a consolidé ça côté appli. propre !

13/06/2024 à 19:04

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