Dépannage de la latence élevée des E/S disque : un guide Linux étape par étape

Une latence élevée des E/S disque a une sensation très spécifique. SSH se connecte toujours, le CPU n'est pas saturé, mais chaque commande qui touche aux fichiers bloque un instant. Une application web fait une pause lors de l'écriture des sessions. Une requête de base de données qui normalement revient rapidement commence à attendre le stockage. La machine semble vivante, mais on a l'impression de marcher dans la boue.

L'astuce est d'éviter de deviner. « Le disque est lent » peut signifier un périphérique de blocs saturé, du swap excessif, un disque défaillant, un travail de sauvegarde bruyant, un volume réseau surchargé ou une base de données effectuant des lectures aléatoires car un index manque. Le même symptôme peut provenir de causes très différentes.

Comprendre les métriques des E/S disque

Avant de plonger dans le dépannage, il est essentiel de comprendre les métriques clés qui indiquent un problème d'E/S. La latence élevée est le symptôme principal, mais nous avons besoin de points de données de support pour confirmer la gravité et la source du problème.

Indicateurs clés de contention des E/S

Latence élevée (await) : Le temps moyen, en millisecondes, pour que les requêtes d'E/S se terminent. Cela inclut le temps passé dans la file d'attente et le temps passé à être traité. Ce qui est considéré comme « élevé » dépend du stockage et de la charge de travail ; comparez-le avec la ligne de base normale du système lorsque vous le pouvez.
Utilisation élevée (%util) : Lorsque cette métrique approche 100 %, le périphérique est saturé et ne peut pas traiter efficacement d'autres requêtes.
File d'attente élevée (avgqu-sz) : Une taille moyenne de file d'attente importante signifie que de nombreux processus attendent que le disque se libère.

Étape 1 : Vérification initiale de l'état du système avec `iostat`

L'utilitaire iostat (faisant partie du paquet sysstat) est la pierre angulaire pour surveiller l'utilisation des périphériques et les statistiques de performance. Il fournit des données historiques et actuelles sur le CPU et les E/S des périphériques.

Pour obtenir un décompte en cours de la performance des E/S, exécutez iostat avec un intervalle (par exemple, toutes les 2 secondes) :

sudo iostat -dxm 2

Analyse de la sortie de `iostat -dxm`

Concentrez-vous spécifiquement sur les colonnes de statistiques des périphériques (drapeau x) :

Colonne	Description	Implication d'une valeur élevée
r/s, w/s	Lectures/Écritures par seconde (IOPS)	Des valeurs élevées indiquent une demande de débit élevée.
rkB/s, wkB/s	Kilooctets lus/écrits par seconde	Mesure le volume de débit.
await	Temps d'attente moyen (ms) pour les requêtes d'E/S (temps de service + temps de file d'attente)	Indicateur principal d'une latence élevée.
%util	Pourcentage de temps pendant lequel le périphérique était occupé à traiter des requêtes	Proche de 100 % indique une saturation.

Exemple de scénario : Si /dev/sda montre un temps await de 150 ms et %util à 98 %, vous avez confirmé un goulot d'étranglement sévère des E/S sur ce disque.

Astuce : Utilisez le drapeau -x pour les statistiques étendues et -m pour les rapports en mégaoctets, ce qui est souvent plus clair qu'en kilooctets (-k).

Étape 2 : Identifier le processus coupable avec `iotop`

Une fois que iostat confirme une latence élevée sur un périphérique spécifique (par exemple, /dev/sda), l'étape cruciale suivante est de déterminer quel processus génère cette charge. L'utilitaire iotop, qui reflète la fonctionnalité de la commande top mais se concentre sur l'activité des E/S, est essentiel ici.

Si iotop n'est pas installé, installez-le d'abord :

# Debian/Ubuntu
sudo apt update && sudo apt install iotop

# RHEL/CentOS/Fedora
sudo yum install iotop  # ou dnf install iotop

Exécutez iotop avec les privilèges root, en affichant uniquement les processus effectuant activement des E/S :

sudo iotop -oP

-o : Afficher uniquement les processus effectuant activement des E/S.
-P : Afficher les processus, pas les threads individuels.

Examinez la sortie, en prêtant attention aux colonnes IO_READ et IO_WRITE. Les processus listés en haut consomment le plus de bande passante disque. Les coupables courants incluent les serveurs de bases de données (MySQL, PostgreSQL), les utilitaires de sauvegarde, les scripts de rotation de journaux ou les systèmes qui écrivent agressivement dans l'espace de swap.

Interpréter la sortie de `iotop`

iotop affiche l'utilisation totale du disque pour chaque processus. Si vous voyez une seule application dominer l'utilisation du disque (par exemple, un script de sauvegarde fonctionnant à 50 Mo/s tandis que la latence augmente), vous avez trouvé la cause immédiate.

Étape 3 : Plongée en profondeur avec `pidstat`

Alors que iotop montre les E/S agrégées par processus, pidstat peut fournir un contexte historique détaillé sur les opérations d'E/S initiées par des PID spécifiques, ce qui est utile pour les problèmes de longue durée ou intermittents.

Pour surveiller les statistiques d'E/S (lecture et écriture de blocs) pour tous les processus toutes les 5 secondes pendant 5 itérations :

sudo pidstat -d 5 5

Les métriques clés dans la sortie -d incluent :

kB_rd/s : Quantité de données lues depuis le disque par seconde par la tâche.
kB_wr/s : Quantité de données écrites sur le disque par seconde par la tâche.
kB_ccwr/s : Quantité de données écrites dans l'espace de swap (c=écriture annulée/commise).

Si les lectures et les écritures augmentent pour le même processus chaque fois que les utilisateurs signalent des pauses, vous avez une piste utile. pidstat est particulièrement utile lorsque iotop montre un pic court puis s'efface avant que vous puissiez le lire.

Étape 4 : Diagnostiquer le thrashing mémoire (utilisation du swap)

Une activité de swap élevée se manifeste souvent par une latence élevée des E/S disque car le système est obligé d'utiliser le disque physique lent comme RAM virtuelle. Utilisez la commande free pour vérifier la pression mémoire :

free -h

Si la mémoire utilisée est proche de la mémoire totale, et que la valeur swap utilisé augmente rapidement, le système manque de mémoire et la latence des E/S est un symptôme secondaire du swap.

Résolution pour le thrashing :

Identifiez les processus gourmands en mémoire en utilisant top ou htop.
Augmentez la RAM du système si possible.
Ajustez les applications pour utiliser moins de mémoire.

Vérifiez également vmstat pendant que le problème se produit :

vmstat 1

Les colonnes si et so montrent l'activité d'échange (swap-in et swap-out). Des valeurs non nulles occasionnelles ne sont pas automatiquement une crise. Une activité soutenue pendant que le système est lent est un signal plus fort. La colonne CPU wa est également utile : un temps d'attente d'E/S élevé signifie que les tâches passent du temps bloquées sur le stockage plutôt que de s'exécuter sur le CPU.

Étape 5 : Faire correspondre le périphérique au système de fichiers

iostat rapporte les périphériques de blocs : sda, nvme0n1, dm-0, md0, etc. Les journaux de votre application mentionnent généralement des chemins : /var/lib/mysql, /var/log, /home, /data. Avant de blâmer le mauvais disque, faites correspondre le chemin au périphérique.

df -hT /var/lib/mysql
findmnt /var/lib/mysql
lsblk -f

Cela est important sur les hôtes avec LVM, RAID logiciel, volumes cloud ou points de montage séparés. Vous pouvez voir une latence élevée sur dm-0, mais le périphérique de support réel peut être un volume EBS, un tableau mdraid ou un périphérique de mappage chiffré. Si le système de fichiers occupé est sur un stockage réseau, les outils de disque locaux ne racontent qu'une partie de l'histoire. Vous devrez également vérifier NFS, iSCSI, les métriques de volume cloud ou l'appliance de stockage.

Étape 6 : Rechercher des indices du noyau et du matériel

Lorsque la latence est élevée mais que le débit ne l'est pas, vérifiez les erreurs de stockage. Un disque défaillant ou un contrôleur sujet aux réinitialisations peut faire ramper le système même avec des E/S modestes.

dmesg -T | egrep -i 'error|reset|timeout|nvme|scsi|blk_update|i/o error'
journalctl -k --since "il y a 30 minutes"

Pour les disques physiques, les données SMART peuvent être utiles :

sudo smartctl -a /dev/sda

Pour les périphériques NVMe :

sudo nvme smart-log /dev/nvme0

Ne lisez pas trop un champ SMART isolément. Différents fournisseurs exposent différents compteurs. Mais les secteurs réalloués, les erreurs de support, les dépassements de délai de commande répétés ou les erreurs d'E/S du noyau méritent une attention immédiate. Si le disque soutient une base de données de production, arrêtez de le traiter comme un exercice de réglage et passez à la redondance, au basculement ou au remplacement.

Étape 7 : Distinguer les problèmes de bande passante des problèmes de latence

Deux incidents peuvent tous deux montrer un « disque lent » tout en nécessitant des correctifs différents.

Une sauvegarde séquentielle peut pousser un wkB/s élevé et un %util élevé. C'est un problème de bande passante. Limiter la sauvegarde, la déplacer hors des heures de pointe, utiliser des sauvegardes incrémentielles ou écrire sur un volume différent peut aider.

Une base de données avec des index manquants peut montrer un débit modeste mais un await douloureux, de nombreuses petites lectures et des retards de requête visibles par l'utilisateur. C'est souvent un problème d'E/S aléatoires et de forme de requête. Ajouter plus de bande passante peut aider moins que d'ajouter le bon index ou de réduire l'ensemble de travail.

Utilisez cette lecture rapide :

rkB/s ou wkB/s élevé, %util élevé, travail volumineux évident : recherchez des lectures/écritures en bloc.
r/s ou w/s élevé, await élevé, débit plus faible : recherchez de nombreuses petites opérations aléatoires.
Activité de swap élevée, wa élevé, mémoire libre faible : traitez la pression mémoire comme la cause racine.
Latence élevée avec des erreurs du noyau : traitez la santé du stockage comme la cause racine.

Étape 8 : Vérifier le contexte au niveau de l'application

Les outils système vous disent qui touche au stockage. Ils ne vous disent pas toujours pourquoi.

Pour les bases de données, vérifiez les journaux de requêtes lentes et les métriques de tampon/cache. Un processus MySQL en haut de iotop peut être normal pendant une sauvegarde, mauvais pendant le trafic de pointe, ou attendu après un redémarrage pendant que le pool de tampons est froid. PostgreSQL peut faire de l'autovacuum, des écritures de point de contrôle ou une requête qui déborde sur le disque. MongoDB peut compacter, construire des index ou lire un ensemble de travail qui ne tient plus dans la RAM.

Pour les serveurs web et les workers d'application, recherchez les tempêtes de journaux. Un journal de débogage laissé activé peut créer des écritures synchrones régulières. Une dépendance défaillante peut également créer des journaux d'erreurs répétés, ce qui crée une pression sur le disque, ce qui aggrave l'incident initial.

Pour les conteneurs, rappelez-vous que le processus bruyant peut apparaître sous containerd, dockerd ou un système de fichiers overlay. Utilisez également des outils au niveau du conteneur :

docker stats
docker ps --format 'table {{.ID}}\t{{.Names}}\t{{.Status}}'

Sur les nœuds Kubernetes, comparez les E/S au niveau de l'hôte avec le placement des pods. Un seul pod écrivant lourdement sur un emptyDir, hostPath ou volume persistant local peut rendre les pods non liés sur le même nœud malsains.

Causes courantes et stratégies de correction

Une fois la source identifiée, appliquez le correctif approprié :

1. Sauvegardes ou travaux de maintenance

Symptôme : Utilisation élevée des E/S coïncidant avec des travaux planifiés (par exemple, des tâches cron). Correction : Replanifiez les travaux d'E/S volumineux, limitez-les si l'utilitaire le permet, ou déplacez la sortie temporaire vers un volume différent. Par exemple, rsync --bwlimit, ionice et les limites de sauvegarde natives de la base de données peuvent réduire le rayon d'explosion.

2. Requêtes de base de données inefficaces

Symptôme : Les processus de base de données (par exemple, mysqld) sont les plus gros consommateurs dans iotop. Correction : Optimisez les requêtes mal indexées qui forcent des analyses de table complètes, entraînant des lectures aléatoires massives.

3. Journalisation excessive

Symptôme : Les processus de journalisation d'application ou système écrivent d'énormes quantités de données. Correction : Révisez les niveaux de journalisation de l'application. Envisagez de mettre en mémoire tampon les journaux ou d'utiliser une solution de journalisation à distance (comme Syslog ou la pile ELK) pour réduire les écritures sur le disque local.

4. Défaillance ou mauvaise configuration du disque

Symptôme : Des temps await extrêmement élevés qui ne sont pas corrélés avec un débit élevé, ou des motifs de lecture/écriture étranges. Cela peut indiquer un matériel défaillant ou une configuration RAID incorrecte. Correction : Vérifiez les données SMART (smartctl) pour la santé du disque. Si vous utilisez RAID, vérifiez l'état du tableau.

5. Système de fichiers ou options de montage

Symptôme : La latence apparaît autour des charges de travail lourdes en métadonnées : création de nombreux petits fichiers, suppression de répertoires, rotation de journaux ou décompression d'archives.

Correction : Vérifiez le type de système de fichiers, les options de montage, l'utilisation des inodes et le comportement du journal. Un système de fichiers plein, des inodes épuisés ou un volume à provisionnement fin presque plein peuvent ressembler à un problème de latence des E/S du côté de l'application.

df -h
df -ih
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS

Si l'utilisation des inodes est à 100 %, supprimer un seul fichier géant n'aidera pas. Vous devez supprimer de nombreux petits fichiers ou déplacer cette charge de travail vers une disposition de système de fichiers conçue pour cela.

Meilleures pratiques pour une surveillance proactive

Prévenir les goulots d'étranglement des E/S est mieux que de les corriger de manière réactive. Mettez en œuvre une surveillance continue :

Définir des alertes : Configurez des outils de surveillance pour alerter sur les changements soutenus de la latence du disque, de la profondeur de la file d'attente, du temps d'attente des E/S, du remplissage du système de fichiers et des compteurs d'erreurs. Utilisez des seuils qui correspondent à votre classe de stockage et à votre charge de travail plutôt que de copier un nombre universel.
Établir une ligne de base de performance : Sachez à quoi ressemble une latence d'E/S « normale » pour votre charge de travail spécifique. Cela rend les anomalies plus faciles à repérer.
Comprendre le type de charge de travail : Les motifs d'E/S aléatoires (courants dans les bases de données) causent une latence beaucoup plus élevée que les E/S séquentielles (courantes dans le streaming multimédia ou les lectures de gros fichiers).

Les meilleures enquêtes sur la latence du disque continuent de réduire la question : quel périphérique, quel système de fichiers, quel processus, quelle charge de travail et quel changement récent ? Une fois que vous avez cette chaîne, le correctif est généralement plus clair. Vous arrêtez de régler aléatoirement les paramètres du noyau et commencez à modifier le planning de sauvegarde, à ajouter de la mémoire, à réparer le stockage, à corriger une requête ou à déplacer une charge de travail bruyante loin d'un disque partagé.