iostat et iotop : diagnostiquer les goulots d'étranglement du stockage sous Linux

Lorsqu'un serveur Linux semble lent, le stockage est l'un des premiers éléments à examiner. iostat vous indique si le disque est surchargé ; iotop vous montre quel processus est à l'origine de la charge. Utilisés conjointement, ils répondent aux deux questions essentielles : le disque est-il réellement le goulot d'étranglement, et si oui, qu'est-ce qui le sollicite à outrance ? Cet article traite de l'installation, de la lecture des résultats (y compris où se trouve la %util se trouve sur le matériel moderne), ainsi qu'un processus pour passer du symptôme à la solution.

Installation d'iostat et d'iotop

iostat est fourni avec le paquet sysstat ; iotop est distribué séparément. Installez les deux :

# Debian/Ubuntu
sudo apt install sysstat iotop
 
# RHEL, AlmaLinux, Rocky, CentOS Stream
sudo dnf install sysstat iotop
 
# Arch
sudo pacman -S sysstat iotop

Sous Ubuntu, sysstat est désactivé par défaut. Pour collecter des données en arrière-plan en vue d'une analyse ultérieure avec sar, modifiez /etc/default/sysstat, définissez ENABLED="true", puis redémarrez le service :

sudo systemctl restart sysstat

iotop doit s'exécuter en tant que root. Sous RHEL 9 et versions plus récentes, la comptabilisation des délais est désactivée par défaut, ce qui laisse le IO et SWAPIN vides. Activez-la avec :

echo 1 | sudo tee /proc/sys/kernel/task_delayacct

Ajoutez kernel.task_delayacct = 1 à /etc/sysctl.conf pour que la modification soit conservée après les redémarrages.

Lecture de la sortie d'iostat

Exécutez iostat avec les statistiques étendues et ignorez le premier échantillon, qui n'affiche que les moyennes depuis le démarrage :

iostat -xz 2

L'option -x ajoute des statistiques étendues, -z masque les périphériques inactifs, et la 2 actualise toutes les deux secondes. Les colonnes importantes :

• await: temps moyen en millisecondes nécessaire à l'exécution d'une requête d'E/S, temps d'attente compris. C'est le chiffre le plus important lorsque les utilisateurs se plaignent de lenteurs.
• r/s et w/s: IOPS en lecture et en écriture. Combiné avec rkB/s et wkB/s , ces chiffres vous indiquent si votre charge de travail est aléatoire (IOPS élevées, faible débit) ou séquentielle (IOPS faibles, débit élevé).
• aqu-sz: profondeur moyenne de la file d'attente. Pour les disques durs, toute valeur supérieure à 1 signifie que le disque ne parvient pas à suivre le rythme.
• %util: pourcentage de temps pendant lequel le périphérique a eu au moins une opération d'E/S en cours. Utile pour les disques durs, trompeur pour les disques NVMe (voir ci-dessous).

Référence rapide des seuils :

L'indicateur %util

%util est la métrique à laquelle la plupart des gens se réfèrent en premier lieu, et sur NVMe, elle est carrément trompeuse. Le noyau considère %util comme « toute E/S en cours à un moment donné », ce qui convient pour un disque rotatif qui traite une requête à la fois, mais n'a aucun sens pour les périphériques NVMe qui gèrent des milliers de requêtes en parallèle à travers des files d'attente matérielles. Un disque NVMe peut afficher 100 % %util tout en fonctionnant à 5 % de sa capacité réelle.

Sur NVMe, faites confiance r_await, w_awaitet aqu-sz à la place. Si r_await reste inférieure à 1 ms et que la profondeur de la file d'attente est largement inférieure à la profondeur de la file d'attente matérielle du périphérique (souvent 1024 ou plus), le disque n'est en réalité pas saturé, quoi qu' %util indique.

Pour une vue rapide du NVMe en Mo/s plutôt qu’en Ko/s :

iostat -xm 1

Pour une collecte à long terme, vous pouvez établir une corrélation avec les journaux d'application ultérieurement :

iostat -x -t 5 720 > /var/log/iostat.log

Cela effectue un échantillonnage toutes les 5 secondes pendant une heure. sar Le même paquet sysstat vous fournit des données équivalentes avec un stockage historique persistant et constitue le meilleur choix pour une surveillance continue.

Vérification avec CPU iowait

Si iostat indique une charge importante sur le stockage, vérifiez également la %iowait colonne du résumé CPU en haut de la même sortie. Une valeur %iowait supérieur à 15-20 % associé à un await confirme que le goulot d'étranglement se situe au niveau du stockage. Si %iowait est élevé mais await semble normal, exécutez vmstat 1 et vérifiez la si et so . Une activité d'échange non nulle signifie que vous êtes limité par la mémoire et que le trafic disque correspond à la pagination, et non à des E/S d'application.

Interprétation des résultats d'iotop

Une fois qu'iostat a confirmé un goulot d'étranglement au niveau du stockage, iotop vous indique quel processus en est responsable. Commencez par :

sudo iotop -o

Le -o masque les processus inactifs, ne laissant apparaître que ceux qui effectuent activement des E/S. Les colonnes à surveiller :

• DISK READ / DISK WRITE : débit en temps réel par processus. Permet d'identifier les processus les plus gourmands.
• IO : pourcentage de temps pendant lequel le processus est bloqué sur des opérations d'E/S. Un processus écrivant à seulement 50 ko/s peut afficher 99 % d'IO s'il effectue de minuscules appels synchrones fsync() . Cette colonne est plus importante que le débit brut.
• SWAPIN : pourcentage de temps passé à attendre des pages de swap. Une valeur non nulle ici signifie que le système utilise la pagination et que votre « problème de stockage » est en réalité un problème de mémoire.

Pour les applications multithread (MySQL, PostgreSQL, charges de travail Java), regroupez les threads en processus à l’aide de -P, et ajoutez -a pour accumuler les totaux depuis le démarrage d'iotop :

sudo iotop -oPa

Le -a drapeau est l'astuce pour détecter les charges de travail en rafales, comme les tâches de sauvegarde qui ne s'exécutent que quelques secondes à la fois et qui seraient autrement difficiles à repérer dans une vue en direct.

Pour une journalisation sans surveillance pendant les fenêtres nocturnes, lorsque personne ne surveille :

sudo iotop -botqq -d 10 > /var/log/iotop.log

Cela écrit un instantané non interactif toutes les 10 secondes. Associez-le aux horodatages de vos tâches de sauvegarde ou de cron pour identifier le coupable a posteriori.

Un processus de diagnostic

La plupart des analyses d'E/S disque suivent le même chemin :

1. iostat -xz 2 pour confirmer que le disque est bien le goulot d'étranglement. Consultez await, aqu-sz, et %iowait. Si ces valeurs sont normales, le problème ne vient pas du stockage et vous devriez chercher ailleurs.
2. iotop -oPa pour identifier le processus à l'origine de la charge. Observez davantage la colonne E/S que celle du débit. Les principaux responsables sont souvent les programmes effectuant de nombreuses petites écritures synchrones, et non ceux qui transfèrent le plus de données.
3. lsof -p <pid> pour voir quels fichiers ce processus utilise. Cela permet généralement d'identifier immédiatement le type de charge de travail : un journal d'écriture anticipée de base de données, un fichier journal d'application, un point de montage de sauvegarde, un fichier temporaire.

Deux schémas à connaître.

Si vous voyez des threads du noyau tels que jbd2/... (journal ext4) ou txg_sync (ZFS) en tête des rédacteurs d'iotop, ils répondent à des écritures provenant d'autres processus, ils ne les initient pas. Le processus de l'espace utilisateur à l'origine du trafic du journal est la cause réelle ; continuez à creuser.

Sur un VPS, un await avec faible %util est le signe classique d'un voisin bruyant. Un autre locataire monopolise le stockage partagé et vos E/S s'accumulent du côté de l'hyperviseur, et non sur votre disque virtuel. Vous pouvez le confirmer mais pas le résoudre depuis l'intérieur de l'invité ; la solution consiste soit à faire remonter le problème au fournisseur, soit à migrer vers un serveur doté d'un stockage isolé.

Résolution des goulots d'étranglement courants en matière d'E/S

Une fois que vous savez ce qui affecte le disque, les solutions sont généralement simples.

Déprioriser les E/S non critiques. ionice place un processus dans la classe de planification « idle », où il n'utilise la bande passante du disque que lorsque rien d'autre n'en a besoin :

ionice -c 3 -p <pid>
sudo ionice -c 3 rsync -a /data /backup

La première forme modifie un processus en cours d'exécution ; la seconde en lance un nouveau qui se trouve déjà dans la classe « idle ». Dans iotop, vous pouvez modifier la priorité d'un processus en cours d'exécution de manière interactive en appuyant sur i.

Déplacez les charges de travail intensives vers un stockage plus rapide. Si iostat indique qu'un disque SATA est surchargé par les écritures de la base de données et qu'un disque NVMe inactif se trouve dans le même boîtier, déplacez le répertoire de données de la base de données. La différence d'ordre de grandeur en termes d'IOPS fait de cette solution la plus efficace qui soit.

Configurez le bon planificateur d'E/S. Les noyaux modernes ont des paramètres par défaut raisonnables, mais cela vaut la peine de vérifier. Pour les NVMe et les SSD, réglez le planificateur sur none. Le périphérique gère mieux la mise en file d'attente au niveau matériel que ne le fait le noyau :

echo none > /sys/block/nvme0n1/queue/scheduler

Pour les disques durs gérant des charges de travail mixtes, mq-deadline est le choix habituel.

Montez avec noatime. Par défaut, chaque lecture met à jour l'horodatage du dernier accès au fichier, générant une écriture pour chaque lecture. Sur les systèmes de fichiers à forte intensité de lecture, cela représente des E/S inutiles. Ajoutez noatime aux options de montage dans /etc/fstab:

UUID=... /data ext4 defaults,noatime 0 2

Réglez le writeback pour les écritures en rafales. Sur les serveurs disposant de beaucoup de RAM, les seuils par défaut pour les pages sales laissent le cache de pages accumuler des gigaoctets de données non écrites, puis les vider en une seule fois. Abaissez les seuils dans /etc/sysctl.conf pour lisser ce processus :

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

Le disque lui-même n'est généralement pas le problème. Lorsque iostat affiche un nombre élevé d'IOPS et un faible débit, la charge de travail effectue des E/S aléatoires sur des données qui pourraient être séquentielles, ou exécute de nombreuses petites écritures qui pourraient être regroupées. Examinez l'application avant de blâmer le matériel.

Si vous exécutez des charges de travail gourmandes en stockage sur un serveur où le réseau peut dépasser la vitesse du disque, les serveurs dédiés NVMe de FDC vous offrent la marge nécessaire pour appliquer les réglages ci-dessus de manière productive.