iotop au quotidien dans l'hébergement : identifier de manière ciblée la charge des disques durs sous Linux

Avec iotop hosting, je repère en quelques secondes le processus qui ralentit mes disques durs et retarde les temps de chargement, les requêtes de base de données ou les sauvegardes. J'utilise cet outil de manière ciblée lorsque la puissance du processeur est disponible, mais que les sites web réagissent lentement et que la Temps d'attente d'E/S augmente.

Points centraux

• Temps réel: Afficher immédiatement les accès lecture/écriture actifs par processus
• responsable: Identifier le service qui remplit la file d'attente d'E/S
• Contexte: Conseils sur Cron, les sauvegardes et la gestion des journaux
• Combinaison: Assurer la sécurité du système avec iostat et vmstat
• Cabinet médical: Transférer les résultats des fenêtres de maintenance et les limites

Pourquoi je lance d'abord iotop lorsque le serveur semble lent

Un serveur peu sollicité dont le processeur est sous-utilisé mérite qu'on jette un œil à la charge du disque dur. C'est précisément là qu'iotop fait toute la différence, car je peux voir, pour chaque processus, qui est en train de lire ou d'écrire. Un simple fichier journal, une importation ou une indexation peut ralentir les temps de réponse, même en l'absence de panne matérielle. Je détecte ces schémas en temps réel et, en cas de doute, je mets fin à la tâche en cause avant que les utilisateurs n’abandonnent. Cette approche ciblée et rapide me fait gagner du temps lors de la Premier diagnostic et évite les vols à l'aveugle.

Installation et démarrage : la version en 30 secondes

La configuration s'effectue en quelques étapes et ne nécessite pas de droits root ni les éléments nécessaires Capabilités. Sous Debian/Ubuntu, j'installe iotop avec apt install iotop, sous RHEL/Alma avec yum install iotop respectivement dnf install iotop. Pour suivre l'événement en direct, je vous invite à iotop sur, filtrer avec -o uniquement les processus actifs, et définis avec -d 1 un intervalle bien défini. Exemple : iotop -o -d 1 me montre qui est en train de freiner. Une sortie par lots « sèche » avec -b m'aide à prendre des notes dans Logs.

Commandes d'accès rapide que je retiens

Je choisis le mode qui me convient en fonction de la situation, tout en restant pragmatique et rapide. iotop -o n'affiche que les processus réellement actifs ; cela permet de réduire le bruit. iotop -a Cumule les E/S depuis le démarrage et facilite l'exécution des tâches de longue durée. iotop -P regroupe les threads au niveau du processus, ce qui facilite la visualisation de Services affûte. iotop -b -qq -d 2 -n 30 je les enregistre dans un fichier lorsque je souhaite enregistrer les pics sur un court laps de temps. Ces petits boutons me permettent d'obtenir la Contrôle, sans passer par des configurations complexes.

Comprendre les résultats : les colonnes et leur signification

Pour prendre une bonne décision, j'ai besoin de critères clairs permettant de distinguer les valeurs critiques de celles qui relèvent de la normale. Sur iotop, je consulte surtout les colonnes consacrées à la lecture, à l'écriture et aux proportions d'E/S. La colonne IO% m'indique la proportion de temps qu'un processus passe dans le noyau à attendre une opération d'E/S. La valeur SWAPIN% devrait presque toujours rester nulle ; si elle augmente, cela signifie que le système est saturé par Externalisation. Grâce à COMMAND, je peux rapidement voir quel script ou quel service est à l'origine du problème et si je dois intervenir.

Colonne	Ce qu'elle montre	Ce à quoi je fais attention
PID / UTILISATEUR	ID du processus et utilisateur	Qui en profite et avec quels moyens ? Droite?
LECTURE / ÉCRITURE SUR DISQUE	Débit actuel par processus	Des débits en Mo/s constants sur plusieurs secondes sont suspect.
SWAPIN%	Part du temps consacrée au swapping	Les valeurs comprises entre 0 et 11 TP3T indiquent une pression dans le Mémoire vers.
IO%	Pourcentage de temps passé dans des états d'attente d'E/S	IO% élevé avec un faible débit en Mo/s = petit, synchrone Écrits.
PRIO	Priorité/Valeur de Nice	Tâches en arrière-plan, le cas échéant avec ionice cuire à la vapeur.
COMMAND	Appel, chemin d'accès compris	Vérifier rapidement s'il s'agit d'une rotation des journaux, d'une sauvegarde ou d'un Importation est.

Procédure de diagnostic : lancer d'abord iotop, puis vérifier avec iostat/vmstat

Je lance iotop pour identifier la source du problème et je valide la situation à l'aide des statistiques système. Un niveau élevé d'IO% pour un processus signifie pour moi que c'est précisément ce service qui sollicite le disque. Ensuite, je vérifie avec iostat -x 1, si le disque présente une charge élevée et si la latence augmente. Un coup d'œil dans vmstat 1 me permet de savoir si c'est la mise en mémoire tampon ou la file d'attente d'exécution qui fausse le résultat. Ceux qui souhaitent approfondir le sujet trouveront ici une introduction concise à Analyser l'attente d'E/S, ce qui m'a permis, lors de la comparaison des Métriques aide.

Les causes courantes dans le quotidien de l'hébergement web et comment je les maîtrise

Un fichier journal qui ne cesse de grossir est un cas classique : il remplit la file d'attente d'E/S avec de nombreuses petites écritures de synchronisation et ralentit les temps de réponse. Les charges de travail des bases de données dotées d'index inadaptés génèrent des schémas irréguliers et ralentissent le système en raison d'opérations aléatoires Accès. Les sauvegardes effectuées aux heures de pointe génèrent des pics de trafic qui affectent sensiblement les autres services. Une indexation de recherche ou une tâche cron exécutée au mauvais moment suffit à ralentir les requêtes. J'étale ces tâches dans le temps, je définis des niveaux de journalisation adaptés et je limite les écritures en mode « hard » dans Fenêtre de maintenance courir.

Organiser clairement les plannings, les tâches cron et la journalisation

Je répartis les tâches lourdes aux heures creuses et je les régule à l'aide des valeurs Nice et Ionice. Pour les sauvegardes, j'utilise ionice -c2 -n7, afin de donner la priorité aux processus interactifs. J'ajuste le niveau de journalisation lorsque les fichiers grossissent trop rapidement et surchargent le système de fichiers. Le matin, je jette un coup d'œil rapide aux tâches lancées pendant la nuit à l'aide d'iotop et je me fie aux enregistrements effectués en mode batch. Si vous souhaitez observer les tendances de latence au fil du temps, vous pouvez consulter Mesurer la latence du disque s'orienter et la Bases serrer.

SSD, NVMe et profondeur de file d'attente : pourquoi le débit seul ne suffit pas

Un disque NVMe fait grimper les IOPS, mais de nombreuses petites écritures de synchronisation entraînent tout de même des baisses de performance dans les temps de réponse. C'est pourquoi je ne me base pas uniquement sur les Mo/s, mais aussi sur l'IO% et la taille typique des requêtes. Lorsque la profondeur de la file d'attente est saturée, les requêtes s'accumulent et la latence augmente sensiblement. Cela se remarque souvent avec iotop, même si le débit brut semble correct. Si vous souhaitez approfondir le sujet, consultez la Profondeur de file d'attente NVMe et classe les Files d'attente propre.

Optimisation pratique : de petits ajustements pour un effet rapide

Je commence par l'évidence : vérifier le taux de réussite du cache de la base de données, compléter les index, configurer correctement le journal d'écriture anticipée (Write-Ahead-Log). Pour les fichiers, je définis des options de montage pertinentes et je veille à activer « noatime » lorsque le profil de charge de travail s'y prête. J'évalue les options de journalisation en fonction du risque, sans pour autant négliger la sécurité des données. Pour les outils de sauvegarde, je choisis des options qui privilégient les écritures séquentielles volumineuses. Chacune de ces modifications réduit le Frottement et résout les goulots d'étranglement avant qu'ils n'affectent les utilisateurs.

Automatisation et documentation : iotop en mode batch

Pour les pics récurrents, j'enregistre les sorties d'iotop dans un fichier, puis je les analyse. La commande iotop -b -o -qq -d 2 -n 120 > /var/log/iotop.log j'enregistre quatre minutes sans le cadre TUI. Je combine cela avec un préfixe d'horodatage ou j'active la rotation des journaux pour que les fichiers restent gérables. Plus tard, je filtre les résultats en fonction d'un nom de processus qui attire l'attention et je vérifie la plage horaire. C'est ainsi que je repère les événements récurrents Pointes et en déduis des actions concrètes à mener.

Droits, options du noyau et conteneurs : ce que je précise au préalable

iotop affiche toutes les informations nécessaires uniquement avec les droits root ou CAP_SYS_ADMIN, que j'utilise délibérément pour des vérifications rapides. Le noyau doit fournir les fonctions Taskstats et Accounting, que les distributions courantes activent par défaut. Dans les conteneurs, je ne vois souvent que les processus au sein de l'espace de noms, ce qui limite la visibilité. Pour les Cgroups, j'utilise en complément des outils qui analysent le groupe dans son ensemble. Cela me permet de bien comprendre ce que fournit iotop et où je dois effectuer des vérifications supplémentaires. Aperçus besoin.

Une approche fine plutôt qu'une solution radicale : IO-Scheduler, ionice et les limites

Avec ionice Je réduis la priorité des tâches en arrière-plan et donne la priorité aux services interactifs. Au niveau du système, je vérifie si le planificateur d'E/S est adapté au type de charge de travail, par exemple BFQ pour les modèles interactifs ou des variantes MQ pour NVMe. Les limites de débit dans les outils de sauvegarde protègent le reste du système contre les effets indésirables. Pour les plugins nécessitant beaucoup d’écritures, je mets en place des stratégies de mise en cache et je soulage la base de données. Ces étapes ne prennent que peu de temps, mais apportent des améliorations notables Silence pendant les périodes chargées.

Aller plus loin : les limites inhérentes à iotop

J'interprète toujours les données d'iotop en tenant compte du contexte. Une valeur élevée d'IO% ne signifie pas nécessairement que “ le disque est plein ”. Les écritures mises en mémoire tampon (Buffered Writes) atterrissent d’abord dans le cache de pages et sont transférées de manière asynchrone par des threads du noyau (par exemple, le « Write-Back Worker »). Je constate alors éventuellement dans iotop des valeurs en Mo/s inoffensives pour le processus à l’origine du phénomène, tandis qu’un kworker ou le thread de journalisation qui traite la charge réelle. Les piles chiffrées (dm-crypt/LUKS), les systèmes de fichiers basés sur FUSE ou les systèmes de fichiers superposés dans des conteneurs brouillent également les correspondances. Ainsi, lorsque seuls des threads du noyau apparaissent en haut de la liste, je détermine, en examinant la commande et l’horodatage, quelle tâche utilisateur a écrit peu avant et où les données sont transmises.

Avec les systèmes NFS ou les systèmes de fichiers distribués, une analyse locale ne suffit souvent pas. iotop m'indique certes des situations d'attente, mais la cause peut se situer du côté du réseau ou du serveur. Dans de tels cas, je recoupe les points de mesure locaux avec les latences au niveau du stockage ou avec les métriques système avant de redémarrer précipitamment des services ou de fixer des limites.

Systèmes de fichiers et options de journalisation au quotidien

Je tiens compte des particularités du système de fichiers, car elles influencent les images iotop. Sous ext4, le mode journal et l'intervalle de validation déterminent à quel point les écritures apparaissent “ en pics ” : data=ordonné c'est une bonne norme, writeback augmente le débit au détriment des garanties de cohérence et journal rend les écritures cohérentes, mais plus coûteuses. XFS s'adapte parfaitement à un grand nombre de threads en parallèle et convient aux fichiers volumineux et à une forte concurrence. Btrfs intègre la technologie « copy-on-write », des sommes de contrôle et, le cas échéant, la compression – ce qui facilite la gestion des charges de lecture, mais peut ralentir le système en cas de nombreuses petites écritures de synchronisation.

Je définis délibérément les options de montage : noatime ou relatime réduisent les écritures inutiles de métadonnées. barrière/nobarrier Je ne tiens compte que de la sécurité du cache d'écriture du matériel. commit=- Les intervalles déterminent la fréquence à laquelle les métadonnées sont validées : une valeur plus élevée atténue les pics, mais augmente la marge de pertes potentielles en cas de panne. J'évalue toujours ces paramètres en fonction du rapport risque/temps de réaction et je les teste pendant les fenêtres de maintenance.

Comprendre la pile de stockage : RAID, LVM et caches

Je ne me concentre pas uniquement sur le processus, mais aussi sur l'infrastructure sous-jacente. Un RAID 5/6 pénalise les petites écritures aléatoires de type « Read-Modify-Write », ce qui se traduit dans iotop par un IO% élevé avec un débit en Mo/s très faible. Les tailles de bande et l’alignement dans LVM déterminent si les accès s’effectuent de manière fluide ou s’ils sont fragmentés. Les caches « write-back » sur les contrôleurs accélèrent visiblement les opérations, mais leur utilisation n’est justifiable qu’avec une alimentation électrique sécurisée. Le NVMe avec une pile multi-files d’attente offre de faibles latences – à condition que les profondeurs de file d’attente, le planificateur et la répartition des IRQ soient adaptés. Je vérifie donc si la charge correspond à la géométrie du stockage avant de modifier le service lui-même.

Paramètres du noyau permettant de lisser la charge d'E/S

Lorsque les rafales d'E/S ont un impact perceptible sur les utilisateurs, j'ajuste de manière ciblée le mécanisme de réécriture différée :

• vm.dirty_bytes / vm.dirty_background_bytes: limites absolues à partir desquelles les processus (ou les « flushers ») commencent à écrire. Je préfère utiliser des octets plutôt que des pourcentages pour maîtriser les systèmes dotés d'une grande quantité de mémoire vive.
• vm.dirty_writeback_centisec et vm.dirty_expire_centisecs: permettent de contrôler la cadence et l“” âge » des pages à écrire – utile pour répartir les pics.
• vm.swappiness: je le maintiens à un niveau modéré afin d'éviter tout swap inutile en cas de charge élevée (SWAPIN% reste idéalement à 0).

Je teste ces ajustements progressivement. L'objectif est de stabiliser la latence pour les utilisateurs sans sacrifier les réserves de débit global.

Optimiser les bases de données de manière ciblée

Pour MySQL/MariaDB, je consulte innodb_buffer_pool_size (taux de réussite du cache), index adaptés et stratégies de vidage judicieuses : innodb_flush_log_at_trx_commit et sync_binlog je choisis en fonction du risque afin d'atténuer les chemins de commit. Une valeur trop faible innodb_log_file_size Cela génère des points de contrôle inutiles et des pics d'E/S. Je stocke les fichiers temporaires sur des volumes rapides lorsqu'ils sont réellement très sollicités.

Avec PostgreSQL, je lisse avec checkpoint_timeout, max_wal_size et une configuration judicieuse d'Autovacuum. Placer le WAL sur un volume rapide et cohérent, ne pas définir les points de contrôle de manière trop agressive et soulager les points chauds à l'aide d'index : cela réduit sensiblement l'IO%. Dans les deux cas, une seule règle s’applique : un seul index manquant génère souvent plus de chaos que n’importe quelle limite matérielle. Je mesure, je vérifie avec iotop la viabilité en écriture du processus de base de données, puis je décide si l’optimisation ou le travail sur les requêtes est prioritaire.

Bien comprendre les conteneurs et les cgroups

Dans les environnements de conteneurs, je regroupe les processus à l'aide de -P ensemble, pour évaluer les services plutôt que les threads. iotop m'indique principalement ce qui est visible dans l'espace de noms ; côté hôte, j'agrège par Cgroup lorsque plusieurs pods/conteneurs partagent le même volume. J’utilise des limites de débit (par exemple via les Cgroups) pour contenir les charges de travail “ bruyantes ” sans les arrêter complètement. Les couches de superposition sont particulièrement importantes : si un conteneur écrit beaucoup dans sa couche de superposition, le mécanisme « copy-on-write » peut entraîner des écritures peu nombreuses mais coûteuses. Dans ce cas, je déplace les chemins d’écriture vers des volumes dédiés ou je réduis l’intensité d’écriture via ionice en bas.

Stockage en réseau (NFS/stockage en blocs) : quand le réseau ralentit

Lorsque des services accèdent à un stockage NFS ou à un stockage en bloc dans le cloud, j'évalue les latences à deux niveaux : en local et à distance. iotop m'indique qu'un processus est en attente, mais la cause peut résider dans le chemin réseau, dans les limites du stockage distant ou dans des options de montage inadaptées. Cas typiques : une charge importante de métadonnées sur les répertoires personnels NFS ou de très petites écritures de synchronisation sur des volumes en bloc soumis à une limite d’IOPS. Je procède alors à un ajustement des paramètres rsize/wsize (NFS), j’utilise des écritures séquentielles plus volumineuses ou je répartis les points de forte activité sur des SSD locaux servant de cache. Pour moi, il est important de ne pas considérer les Mo/s de manière isolée : un faible débit en Mo/s associé à un IO% élevé indique un temps d’attente, et non des limites de débit.

Exemple concret : mon workflow de 10 minutes

• Minutes 1 à 2 : iotop -o -d 1 Lancer, identifier les coupables, déterminer si la lecture ou l'écriture prédomine, vérifier IO% et SWAPIN%.
• Minutes 3 à 4 : iostat -x 1 en parallèle : vérifier la plausibilité des latences, du taux d'utilisation et de la profondeur de la file d'attente.
• Minute 5 : Si la faute revient clairement à un lot, avec ionice/sympa réduire ou interrompre temporairement.
• Minutes 6-7 : classer les modèles (Cron ? Sauvegarde ? Indexation ?) et noter le calendrier et la limite.
• Minutes 8 à 9 : Vérification du système de fichiers et du contexte de la base de données (journalisation/validation, index, vidage).
• 10e minute : lancer la trace par lots (iotop -b -o -qq -d 2 -n 120) et noter les tâches à faire.

Automatisation : regrouper les sorties par lots

Je résume les journaux de traitement par lots de manière pragmatique afin d'identifier les répétitions. Un bon point de départ consiste à totaliser les données par ligne de commande pour voir quelles commandes ont été les plus fréquemment utilisées et celles qui ont eu le plus d'impact. Exemple : un bref awk-Lauf permet d'additionner les valeurs WRITE/READ mesurées par nom de processus et de répertorier les principaux responsables. J'obtiens ainsi un classement en quelques secondes, sans avoir recours à des pipelines complexes. Pour les comparaisons à plus long terme, je configure une rotation des journaux serrée et je maintiens les formats de sortie stables, afin de pouvoir effectuer des comparaisons A/B plusieurs semaines plus tard.

En bref

J'utilise iotop pour identifier en temps réel le service qui engorge la file d'attente d'E/S, puis je vérifie, à l'aide des valeurs système, quel est le niveau réel de charge du disque. Les coupables typiques sont la croissance des fichiers journaux, des horaires de cron mal choisis, des écritures lourdes sur la base de données ou une indexation parallèle qui se déroule en même temps que le trafic. Grâce à des plannings bien organisés, une journalisation adaptée, ionice/Nice et quelques réglages de stockage, je réduis efficacement le temps d’attente. Il reste important de documenter les schémas et de traduire les conclusions en mesures concrètes. C’est ainsi que la rapidité Dépannage un gain de vitesse durable pour les configurations d'hébergement de toutes tailles.