Iotop sous Linux : retrouver le processus qui fait travailler le disque

Le disque travaille en continu, les commandes répondent par à-coups et la LED de stockage ne s’éteint plus. iostat peut confirmer que le périphérique est chargé, mais il ne donne pas directement le nom du processus responsable. C’est là que iotop devient utile.

Je l’utilise pour relier une activité de lecture ou d’écriture à un PID, un utilisateur et une commande. Il faut toutefois observer plusieurs échantillons : une sauvegarde, une rotation de logs ou un démarrage de base de données peut produire un pic normal. Une charge continue demande une vérification plus poussée avant d’arrêter quoi que ce soit.

Installer iotop et vérifier les prérequis du noyau

Commencez par vérifier si l’outil est déjà installé et quelle implémentation votre distribution fournit :

command -v iotop
iotop --version
iotop --help

Sur Debian et Ubuntu récents, le paquet iotop-c fournit une version maintenue en C. Certains dépôts proposent encore un paquet nommé iotop. Sur Fedora et Arch Linux, utilisez le gestionnaire de paquets habituel :

sudo apt update
sudo apt install iotop-c

sudo dnf install iotop

sudo pacman -S iotop

Les options peuvent varier légèrement entre iotop-c et l’ancienne version Python. Vérifiez donc iotop --help avant d’intégrer la commande dans un script.

Lancez ensuite l’interface avec les droits administrateur :

sudo iotop

iotop lit des informations d’entrées-sorties exposées par le noyau. Évitez de lui attribuer durablement la capacité NET_ADMIN uniquement pour supprimer sudo : cela rend des données sur les processus accessibles à d’autres utilisateurs.

Si l’outil avertit que task_delayacct est désactivé, contrôlez sa valeur :

sysctl kernel.task_delayacct

Sur les noyaux récents, ce compteur peut être désactivé par défaut. Activez-le temporairement seulement si vous avez besoin des temps d’attente IO et SWAPIN, puis remettez-le à zéro après le diagnostic :

sudo sysctl kernel.task_delayacct=1
sudo iotop
sudo sysctl kernel.task_delayacct=0

La page de manuel de iotop précise que ce compteur a un coût. Ne le rendez pas persistant sans raison.

Afficher uniquement les processus qui font des entrées-sorties

L’affichage complet bouge beaucoup. Pour masquer les tâches inactives et regrouper les threads par processus, lancez :

sudo iotop -oP

• -o n’affiche que les tâches qui réalisent réellement des entrées-sorties ;
• -P regroupe l’affichage au niveau des processus plutôt que de détailler tous les threads ;
• DISK READ et DISK WRITE montrent le débit observé pendant l’échantillon ;
• IO représente le temps passé à attendre les entrées-sorties, si le noyau fournit ce compteur.

Dans l’interface, appuyez sur o pour afficher ou masquer les processus inactifs, sur p pour basculer entre processus et threads, puis utilisez les flèches gauche et droite pour choisir la colonne de tri. La touche a affiche les volumes cumulés depuis le démarrage de l’outil. Quittez avec q.

Ne confondez pas un débit instantané et un volume cumulé. Une base de données peut écrire fort pendant deux secondes à l’occasion d’un checkpoint, puis revenir au calme. À l’inverse, un processus qui écrit moins vite mais reste en tête pendant plusieurs minutes peut expliquer une latence durable.

Les valeurs totales côté processus ne correspondent pas toujours exactement à l’activité physique du disque. Le cache et la réorganisation des écritures par le noyau créent un décalage. iotop désigne une tâche à examiner, pas une preuve suffisante pour l’arrêter.

Enregistrer trente secondes d’activité sans rester devant le terminal

Le mode batch permet de conserver un relevé dans un fichier. Cette commande prend un échantillon toutes les deux secondes, quinze fois, et ajoute l’horodatage :

sudo iotop -b -o -P -t -d 2 -n 15 | tee /tmp/iotop-30s.log

Reproduisez le ralentissement pendant la capture, puis relisez les PID, les commandes et les débits qui reviennent dans plusieurs échantillons :

less /tmp/iotop-30s.log

Pour surveiller un processus précis, relevez d’abord son PID, puis utilisez -p. Vous pouvez aussi filtrer par utilisateur avec -u :

pgrep -af postgres
sudo iotop -oP -p 1234
sudo iotop -oP -u postgres

Remplacez 1234 par le PID trouvé sur votre machine. Si le processus redémarre, son PID change : refaites la recherche au lieu de conserver un ancien numéro dans une procédure.

Confirmer le PID, le service et les fichiers concernés

Une fois le processus repéré, identifiez son exécutable, sa commande complète et ses compteurs d’entrées-sorties :

ps -fp 1234
readlink -f /proc/1234/exe
sudo cat /proc/1234/io
sudo lsof -p 1234

Dans /proc/1234/io, read_bytes et write_bytes sont plus proches des octets réellement envoyés au stockage que rchar et wchar, qui comptent les octets passés par les appels de lecture et d’écriture. Prenez deux relevés espacés de quelques secondes pour voir si les compteurs progressent.

lsof aide à retrouver les fichiers ouverts, mais la sortie peut être longue. Le guide sur lsof sous Linux montre comment cibler un PID ou un fichier sans balayer tout le serveur.

Si le PID appartient à un service systemd, contrôlez son état et ses derniers journaux avant un redémarrage :

systemctl status mon-service --no-pager
journalctl -u mon-service -n 100 --no-pager

Remplacez mon-service par la vraie unité. Pour une base de données, une sauvegarde, un agent antivirus ou un conteneur, une activité disque soutenue peut être attendue. Vérifiez l’horaire, les logs et les travaux en cours avant d’envoyer un signal au processus.

Croiser iotop avec iostat avant d’accuser l’application

iotop répond à la question « quel processus fait des entrées-sorties ? ». Il ne dit pas à lui seul quel disque physique sature, ni si le stockage répond lentement. Utilisez iostat en parallèle :

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL
iostat -xz 2 10

L’article sur iostat sous Linux détaille await, la file d’attente et %util. Si iotop montre une tâche active mais que les périphériques restent peu chargés et répondent vite, le ralentissement peut venir du CPU, de la mémoire, d’un verrou applicatif ou du réseau.

À l’inverse, un même processus visible pendant toute la capture, associé à une latence et une file d’attente élevées dans iostat, constitue une piste solide. À ce stade, corrigez la cause : requête de base de données mal indexée, logs sans rotation, sauvegarde au mauvais horaire, cache insuffisant ou stockage dégradé. Tuer le PID masque parfois le symptôme et peut ajouter une récupération longue au prochain démarrage.

sudo apt update && sudo apt upgrade