CPU et E/S par processus avec pidstat et /proc/<pid>/io : identifier la cause de l'attente d'E/S

Objectif

Identifier le processus précis responsable d'une consommation de CPU ou d'E/S disque qu'un outil global au système (top, iostat) ne peut présenter que de façon agrégée.

Prérequis

Le paquet sysstat pour pidstat. Il faut aussi un accès en lecture à /proc/<pid>/io pour le processus ciblé : le noyau le contrôle par une vérification d'accès en lecture de type ptrace (en pratique, l'utilisateur propriétaire du processus, ou root pour le processus d'un autre utilisateur). De même, pidstat -d ne rapporte les tâches des autres utilisateurs que s'il est exécuté en tant que root.

Étapes

1. Commencer par le CPU par processus : pidstat 1 5 liste le pourcentage de CPU de chaque tâche. Le manuel de sysstat décrit pidstat comme un outil qui rapporte des statistiques sur les tâches individuelles actuellement gérées par le noyau, ce qui évite de devoir filtrer un nom dans top.
2. Ajouter la mémoire et les changements de contexte dans la même passe : pidstat -r -w 1 5 (-r pour la mémoire, -w pour les changements de contexte). C'est utile lorsque le CPU seul n'explique pas la charge.
3. Passer aux E/S disque par processus : pidstat -d 1 5 indique, pour chaque tâche, les kilo-octets lus et écrits par seconde ainsi que le délai d'E/S (iodelay). iodelay dépend de la comptabilité des délais (delay accounting) du noyau, désactivée par défaut depuis Linux 5.14 (à activer avec sysctl kernel.task_delayacct=1 ou le paramètre de démarrage delayacct) ; sans elle, la colonne reste à zéro.
4. Pour un PID suspect précis, lire directement les compteurs bruts : cat /proc/<pid>/io. La page proc_pid_io(5) documente rchar/wchar comme les octets renvoyés par les appels read(2)/write(2) réussis et assimilés — ce qui inclut les accès satisfaits par le cache de pages, les tubes, les sockets et les terminaux — et read_bytes/write_bytes comme les octets réellement lus depuis la couche de stockage ou envoyés vers elle, plus proches de ce que iostat observe au niveau du périphérique. write_bytes est comptabilisé lorsque le processus modifie des pages du cache de pages ; l'écriture physique peut donc atteindre le périphérique plus tard, lors de la réécriture différée (writeback).
5. Échantillonner /proc/<pid>/io deux fois à intervalle connu, puis soustraire pour obtenir un débit, comme le fait pidstat -d pour calculer ses propres valeurs. Cela fonctionne aussi pour les processus lancés avant le début de l'observation.
6. Corréler : un processus dont les read_bytes/write_bytes augmentent précisément pendant la fenêtre où iostat -xz montrait un périphérique saturé est celui à examiner ensuite, par exemple via ses fichiers ouverts (ls -l /proc/<pid>/fd).

Résultat attendu

Un PID et une ligne de commande précis, responsables de la charge observée globalement sur le système, exprimés dans les mêmes unités (Ko/s) que celles déjà rapportées par les outils au niveau du périphérique.

Limites et base de vérification

rchar/wchar comptent les E/S logiques, y compris les accès satisfaits par le cache et les E/S qui ne concernent pas des fichiers ; ils peuvent donc être bien supérieurs au trafic physique vers le périphérique. Il faut utiliser read_bytes/write_bytes lorsque la question est de savoir combien le processus a fait travailler le disque. pidstat comme la lecture de /proc/<pid>/io sont de simples observations en lecture seule, sans rien à annuler ; un processus qui se termine entre deux échantillons disparaît simplement de la lecture suivante.