Dépannage de la latence d'E/S disque élevée : un guide pas à pas sous Linux

La latence des opérations d'entrée/sortie (E/S) disque est un goulot d'étranglement courant dans les systèmes Linux, entraînant souvent des performances d'application lentes, des temps de démarrage prolongés et une instabilité globale du système. Lorsque les processus passent un temps excessif à attendre la fin des opérations disque, le système signale une latence élevée, même si l'utilisation du processeur semble faible. Comprendre comment diagnostiquer et atténuer ces goulots d'étranglement d'E/S est une compétence cruciale pour tout administrateur système Linux.

Ce guide complet vous accompagnera à travers les outils et méthodologies essentiels pour identifier la source d'une latence d'E/S disque élevée sur une machine Linux. Nous nous concentrerons sur des étapes pratiques, utilisant des utilitaires puissants tels que iostat, iotop et d'autres, pour passer de l'observation des symptômes à la résolution de la cause première.

Comprendre les métriques d'E/S disque

Avant de plonger dans le dépannage, il est vital 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 soutien pour confirmer la gravité et la source du problème.

Indicateurs clés de contention d'E/S

• Latence élevée (await/svctm) : Temps nécessaire pour que les requêtes d'E/S soient traitées. Des valeurs élevées (> 20 ms pour les charges de travail générales, beaucoup plus élevées pour les systèmes de bases de données) indiquent un goulot d'étranglement.
• Utilisation élevée (%util) : Lorsque cette métrique approche 100 %, le périphérique est saturé et ne peut plus gérer les requêtes supplémentaires efficacement.
• Mise en file d'attente élevée (avgqu-sz) : Une grande taille moyenne de la file d'attente 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 courant des performances d'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 de périphérique (option x) :

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

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

Astuce : Utilisez l'option -x pour les statistiques étendues et -m pour l'affichage en mégaoctets, ce qui est souvent plus clair que les kilooctets (-k).

Étape 2 : Identification du 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 consiste à 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é d'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 des privilèges root, en vous concentrant uniquement sur les processus qui effectuent un échange actif :

sudo iotop -oP

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

Examinez la sortie, en prêtant attention aux colonnes IO_READ et IO_WRITE. Les processus listés en haut sont ceux qui 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 des journaux, ou les systèmes qui écrivent de manière agressive dans l'espace d'échange.

Interprétation de la sortie 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 s'exécutant à 50 Mo/s alors que la latence monte en flèche), vous avez trouvé la cause immédiate.

Étape 3 : Analyse approfondie avec pidstat

Alors que iotop montre l'utilisation agrégée des E/S 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 intermittents ou de longue durée.

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 comprennent :

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

Si kB_ccwr/s est constamment élevé, le système subit un thrashing (saturation de la mémoire) : il échange la mémoire sur disque en raison d'une RAM insuffisante, ce qui entraîne directement une latence élevée.

Étape 4 : Diagnostic de la saturation mémoire (utilisation de l'échange)

Une activité d'échange élevée se manifeste souvent par une latence d'E/S disque élevée car le système est forcé d'utiliser le disque physique lent comme mémoire 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 used augmente rapidement, le système manque de mémoire, et la latence d'E/S est un symptôme secondaire de l'échange.

Résolution pour le thrashing :
1. Identifier les processus gourmands en mémoire à l'aide de top ou htop.
2. Augmenter la RAM du système si possible.
3. Ajuster les applications pour qu'elles utilisent moins de mémoire.

Causes courantes et stratégies de remédiation

Une fois la source identifiée, appliquez la correction appropriée :

1. Sauvegardes ou maintenance non planifiées

Symptôme : Utilisation élevée des E/S coïncidant avec des travaux planifiés (par exemple, des tâches cron).
Remédiation : Reportez les travaux d'E/S volumineux (comme les vidages de bases de données ou les transferts de fichiers volumineux) aux heures creuses ou limitez leur vitesse si l'utilitaire le prend en charge.

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

Symptôme : Les processus de base de données (par exemple, mysqld) sont les principaux consommateurs dans iotop.
Remédiation : Optimisez les requêtes mal indexées qui forcent des analyses complètes de tables, 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.
Remédiation : Examinez les niveaux de journalisation des applications. Envisagez de mettre en mémoire tampon les journaux ou d'utiliser une solution de journalisation distante (comme Syslog ou la pile ELK) pour réduire les écritures sur disque local.

4. Défaillance ou mauvaise configuration du disque

Symptôme : Temps await extrêmement élevés qui ne correspondent pas à un débit élevé, ou schémas de lecture/écriture étranges. Cela peut indiquer un matériel défaillant ou une configuration RAID incorrecte.
Remédiation : Vérifiez les données SMART (smartctl) pour l'état de santé du disque. Si vous utilisez RAID, vérifiez l'état du tableau.

Bonnes pratiques pour une surveillance proactive

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

• Définir des alertes : Configurez des outils de surveillance (comme Prometheus/Grafana, Nagios) pour alerter lorsque le temps d'attente moyen du disque (await) dépasse un seuil critique (par exemple, 50 ms) ou lorsque %util reste supérieur à 90 % pendant plusieurs minutes.
• Établir une référence de performance : Sachez à quoi ressemble une latence d'E/S « normale » pour votre charge de travail spécifique. Cela permet de repérer plus facilement les anomalies.
• Comprendre le type de charge de travail : Les modèles d'E/S aléatoires (courants dans les bases de données) provoquent une latence beaucoup plus élevée que les E/S séquentielles (courantes dans le streaming multimédia ou la lecture de fichiers volumineux).

En utilisant systématiquement des outils tels que iostat pour mesurer les performances globales du système et iotop/pidstat pour identifier les contrevenants spécifiques, les administrateurs système peuvent rapidement restaurer les performances maximales du disque et éliminer les problèmes de latence liés aux E/S.