Latence d'E/S disque avec iostat -x : r_await, w_await, aqu-sz, et pourquoi %util induit en erreur sur SSD et RAID

Ce que c'est

iostat -x (sysstat) ajoute des colonnes étendues par périphérique à la vue simple du débit en lecture/écriture. Son manuel définit les champs les plus utiles pour analyser la latence : r_await et w_await sont le temps moyen, en millisecondes, nécessaire pour traiter les requêtes de lecture et d'écriture, temps d'attente en file et temps de service inclus ; aqu-sz est la longueur moyenne de la file des requêtes émises vers le périphérique ; %util est le pourcentage du temps écoulé pendant lequel des requêtes d'E/S ont été émises vers le périphérique.

Les noms de colonnes dépendent de la version de sysstat. Les anciennes versions (par exemple sysstat 10.x sur RHEL 7) affichent avgqu-sz, avgrq-sz (en secteurs) et svctm, un champ auquel leur propre manuel déconseillait déjà de se fier ; les versions actuelles les nomment aqu-sz et areq-sz/rareq-sz/wareq-sz (en kilo-octets) et ne documentent plus svctm. La présence d'une colonne await combinée à côté de r_await/w_await dans la sortie de -x varie elle aussi selon la version ; les scripts doivent donc repérer les champs par le nom de l'en-tête, et non par la position de la colonne.

Pourquoi c'est important

Séparer await en lecture et en écriture est important, car les deux peuvent différer énormément sur un même périphérique — par exemple des écritures séquentielles mais des lectures aléatoires sur un disque mécanique — et une moyenne unique les masque. aqu-sz compte les requêtes en attente au niveau du périphérique, y compris celles en cours de traitement. Sur un périphérique qui ne traite qu'une requête à la fois, une valeur durablement supérieure à environ un signifie que des requêtes s'accumulent en file ; les SSD, le NVMe et les ensembles RAID traitent de nombreuses requêtes en parallèle, de sorte qu'un aqu-sz plus élevé y est normal et ne compte que s'il augmente en même temps que await. %util était un indicateur fiable de saturation sur un périphérique ne pouvant traiter qu'une requête à la fois ; le manuel indique clairement que la saturation survient lorsque cette valeur approche 100 % pour les périphériques qui traitent les requêtes en série, mais que, pour les périphériques qui les traitent en parallèle — les matrices RAID et les SSD modernes sont ses propres exemples —, ce chiffre ne reflète pas leurs limites de performance, car un tel périphérique peut rester à 100 % (jamais inactif) tout en étant très loin de son plafond réel de débit ou de latence.

Comment l'appliquer

• Lire d'abord r_await/w_await pour la latence perçue par les utilisateurs, en la jugeant par rapport à la plage attendue du stockage concerné plutôt qu'avec un seul seuil fixe pour des périphériques dissemblables.
• Observer la tendance de aqu-sz à la hausse sur des échantillons consécutifs, en parallèle d'un await qui augmente, en la comparant à ce qui est normal pour ce périphérique.
• Traiter %util comme un indicateur d'activité, et non comme un pourcentage de saturation, sur SSD, NVMe et RAID ; un périphérique rapide bloqué à 100 % avec un await faible n'est pas le goulot d'étranglement.
• Échantillonner plusieurs fois (iostat -xz 1 10) plutôt qu'une seule ; le premier rapport couvre la période écoulée depuis le démarrage, et non l'intervalle d'échantillonnage (-y l'omet).
• Se concentrer sur un seul périphérique (iostat -x <device> 1) dès qu'un candidat se dégage de la liste complète.

Pièges

• Déclencher des alertes sur %util seul avec du stockage moderne, et passer à côté d'une vraie mise en file que aqu-sz aurait révélée.
• Comparer await entre des périphériques dissemblables (stockage réseau, NVMe local, RAID en cours de reconstruction) comme si un même seuil s'appliquait à tous.
• Oublier que la première ligne affichée après le lancement d'iostat est une moyenne depuis le démarrage, et non l'état actuel.