iowait de ouf sur nvme sous linux en prod pourquoi

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.

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.

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.

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.

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.

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.

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.

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 !