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

45

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.

Avada Kedavra
la source
Il semble que le problème puisse être moins un processus particulier que un disque sporadiquement insensible. Les disques font ce genre de choses qui, au niveau du système, semblent être des falaises frappées par un système. Si vous ne trouvez aucun coupable, il est temps d'étudier le sous-système de disque.
Slashdot
Utilisation de htop serverfault.com/a/25034/373867
qwr

Réponses:

47

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 .

halpe
la source
Hey, merci! Encore un autre jouet geek à stocker dans ma boîte à outils. :-)
Janne Pikkarainen
Exécuter iotop en mode batch pourrait être un très bon complément / remplacement pour la solution "ps -eo" ci-dessus. Merci!
Avada Kedavra
2
Génial, "iotop -n 1 -b -o" fournit exactement le résultat dont j'ai besoin. Merci!
Avada Kedavra
ressemble à cela nécessite un accès root au système pour fonctionner
user5359531
30

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]              
utilisateur920391
la source
10

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 ;-)

mr.spuratic
la source
10

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
Wayne Walker
la source
5

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.

Janne Pikkarainen
la source
Bonjour Janne, le noyau n’est malheureusement pas compilé avec le système de fichiers de débogage, c’est un système actif, je ne peux donc pas recompiler le noyau. Existe-t-il un autre moyen de le faire sans recompiler?
Avada Kedavra
OK, j'ai édité un peu ma réponse :)
Janne Pikkarainen
Génial, maintenant nous allons quelque part! Je songe à mettre cela dans un travail cron et à l'exécuter en même temps que le travail sar cron. Ensuite, la prochaine fois que le serveur sera bloqué, je devrais être en mesure de comparer le taux de défauts de page pour voir quel processus / processus a un taux accru de défauts de page. Je suppose que je pourrais avoir de la malchance et voir une augmentation de disque io pour tous les processus pendant le décrochage, mais ça vaut vraiment le coup d'essayer. Merci Janne! (Je voterais sur votre réponse si je le pouvais: S)
Avada Kedavra Le
Je vous en prie. Laissez-moi savoir comment cela s'est passé, ce n'était qu'une tentative créative de résolution de problème de ma part. :-)
Janne Pikkarainen
La sortie iotop est plus facile à sous-interpréter, donc je n’accepte pas cette solution. Je serai de retour pour voter sur votre réponse dès que j'aurai gagné assez de reps pour le faire. Merci pour votre aide!
Avada Kedavra