Comment vérifier l'utilisation des E / S du disque par processus

J'ai un problème avec un système Linux bloqué et j’ai trouvé sysstat / sar capable de signaler des pics énormes d’utilisation des E / S de disque, du temps de service moyen ainsi que du temps d’attente moyen au moment du blocage du système.

Comment puis-je déterminer le processus qui cause ces pics la prochaine fois que cela se produit?
Est-il possible de faire avec sar (ie: puis-je trouver cette information à partir des fichiers sar déjà enregistrés?

Sortie pour "sar -d", le décrochage du système s'est produit vers 12h58-13h01.

12:40:01          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
12:40:01       dev8-0     11.57      0.11    710.08     61.36      0.01      0.97      0.37      0.43
12:45:01       dev8-0     13.36      0.00    972.93     72.82      0.01      1.00      0.32      0.43
12:50:01       dev8-0     13.55      0.03    616.56     45.49      0.01      0.70      0.35      0.47
12:55:01       dev8-0     13.99      0.08    917.00     65.55      0.01      0.86      0.37      0.52
13:01:02       dev8-0      6.28      0.00    400.53     63.81      0.89    141.87    141.12     88.59
13:05:01       dev8-0     22.75      0.03    932.13     40.97      0.01      0.65      0.27      0.62
13:10:01       dev8-0     13.11      0.00    634.55     48.42      0.01      0.71      0.38      0.50

C’est une question qui fait suite à un fil que j’avais commencé hier: des pics soudains de charge et de bloc disque attendent , j’espère que c’est bien que j’ai créé un nouveau sujet / question sur le sujet car je n’ai pas encore pu résoudre le problème.

Si vous avez la chance de connaître la prochaine période d'utilisation maximale, vous pouvez étudier les statistiques d'E / S par processus de manière interactive, à l'aide d' iotop .

Vous pouvez utiliser pidstat pour imprimer les statistiques cumulatives io par processus toutes les 20 secondes avec cette commande:

# pidstat -dl 20

Chaque ligne aura des colonnes suivantes:

• PID - ID de processus
• kB_rd / s - Nombre de kilo-octets de lecture par seconde de la tâche.
• kB_wr / s - Nombre de kilooctets que la tâche a causés ou doit entraîner pour être écrit sur le disque par seconde.
• kB_ccwr / s - Nombre de kilooctets dont l'écriture sur le disque a été annulée par la tâche. Cela peut se produire lorsque la tâche tronque du pagecache sale. Dans ce cas, certaines opérations d'information dont une autre tâche a été prise en compte ne se produiront pas.
• Commande - Nom de la commande de la tâche.

La sortie ressemble à ceci:

05:57:12 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:57:32 PM       202      0.00      2.40      0.00  jbd2/sda1-8
05:57:32 PM      3000      0.00      0.20      0.00  kdeinit4: plasma-desktop [kdeinit]              

05:57:32 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:57:52 PM       202      0.00      0.80      0.00  jbd2/sda1-8
05:57:52 PM       411      0.00      1.20      0.00  jbd2/sda3-8
05:57:52 PM      2791      0.00     37.80      1.00  kdeinit4: kdeinit4 Running...                   
05:57:52 PM      5156      0.00      0.80      0.00  /usr/lib64/chromium/chromium --password-store=kwallet --enable-threaded-compositing 
05:57:52 PM      8651     98.20      0.00      0.00  bash 

05:57:52 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:58:12 PM       202      0.00      0.20      0.00  jbd2/sda1-8
05:58:12 PM      3000      0.00      0.80      0.00  kdeinit4: plasma-desktop [kdeinit]              

Rien ne vaut la surveillance en cours, vous ne pouvez tout simplement pas récupérer des données urgentes après l'événement ...

Il y a plusieurs choses que vous pourriez être en mesure de vérifier pour impliquer ou éliminer - /procest votre ami.

sort -n -k 10 /proc/diskstats
sort -n -k 11 /proc/diskstats

Les champs 10 et 11 sont les secteurs écrits accumulés et l'écriture de temps accumulé (ms). Cela montrera vos partitions de système de fichiers à chaud.

cut -d" " -f 1,2,42 /proc/*/stat | sort -n -k +3

Ces champs sont les PID, les commandes et les ticks IO-wait cumulés. Cela montrera vos processus chauds, mais seulement s'ils sont toujours en cours d'exécution . (Vous voudrez probablement ignorer les threads de journalisation du système de fichiers.)

L'utilité de ce qui précède dépend du temps de disponibilité, de la nature de vos processus longs et de la façon dont vos systèmes de fichiers sont utilisés.

Mises en garde: ne s'applique pas aux noyaux antérieurs à la version 2.6, vérifiez votre documentation en cas de doute.

(Allez maintenant faire plaisir à votre avenir, installez Munin / Nagios / Cacti / que ce soit ;-)

Utilisez atop. ( http://www.atoptool.nl/ )

Écrivez les données dans un fichier compressé atoppouvant être lu ultérieurement dans un style interactif. Prenez une lecture (delta) toutes les 10 secondes. faites-le 1080 fois (3 heures; si vous l'oubliez, le fichier de sortie ne vous manquera pas de disque):

$ atop -a -w historical_everything.atop 10 1080 &

Après que de mauvaises choses se reproduisent:

(même s'il fonctionne toujours en arrière-plan, il ajoute juste toutes les 10 secondes)

% atop -r historical_everything.atop

Depuis que vous avez dit IO, je taperais 3 touches: tdD

t - move forward to the next data gathering (10 seconds)
d - show the disk io oriented information per process
D - sort the processes based on disk activity
T - go backwards 1 data point (10 seconds probably)
h - bring up help
b - jump to a time (nearest prior datapoint) - e.g. b12:00 - only jumps forward
1 - display per second instead of delta since last datapiont in the upper half of the display

Utilisez btrace. C'est facile à utiliser, par exemple btrace /dev/sda. Si la commande n'est pas disponible, elle est probablement disponible dans le package blktrace .

EDIT : Puisque le fichier debugfs n’est pas activé dans le noyau, vous pouvez essayer date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtfou similaire. La journalisation des erreurs de page n’est bien sûr pas la même chose que d’utiliser btrace, mais si vous êtes chanceux, elle PEUT vous donner un indice sur les processus les plus gourmands en disque. Je viens d’essayer celui-ci sur l’un de mes serveurs les plus intensifs en E / S et la liste inclut les processus qui, je le sais, consomment beaucoup d’E / S.