Comment vérifier l'utilisation des E / S disque par processus
Je rencontre un problème avec un système Linux en cours de blocage et j'ai trouvé que sysstat/sar signale d'énormes pics d'utilisation des E/S disque, le temps de service moyen ainsi que le temps d'attente moyen au moment du blocage du système.
Comment pourrais-je déterminer quel processus est à l'origine de ces pics la prochaine fois?
Est-il possible de faire avec sar (c'est-à-dire: puis-je trouver ces informations dans les fichiers sar enregistrés précédemment?
Sortie pour "sar -d", le blocage 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
Ceci est une question complémentaire à un fil que j'ai commencé hier: pics soudains de charge et bloc de disque attendre , j'espère que c'est ok que j'ai créé un nouveau sujet/question à ce sujet car je n'ai pas encore pu résoudre le problème.
Si vous avez la chance d'attraper la prochaine période d'utilisation maximale, vous pouvez étudier les statistiques d'E/S par processus de manière interactive, en utilisant iotop .
Vous pouvez utiliser pidstat pour imprimer des statistiques io cumulatives 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 que la tâche a provoqué pour être lu sur le disque par seconde.
- kB_wr/s - Nombre de kilo-octets que la tâche a causés ou doit faire écrire sur le disque par seconde.
- kB_ccwr/s - Nombre de kilo-octets dont l'écriture sur le disque a été annulée par la tâche. Cela peut se produire lorsque la tâche tronque un cache de page sale. Dans ce cas, certains IO dont une autre tâche a été prise en compte ne se produiront pas.
- Commande - Le nom de 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 continue, vous ne pouvez tout simplement pas récupérer les données sensibles au temps après l'événement ...
Il y a quelques choses que vous pourriez être en mesure de vérifier pour impliquer ou éliminer cependant - /proc est votre ami.
sort -n -k 10 /proc/diskstats
sort -n -k 11 /proc/diskstats
Les champs 10, 11 sont des secteurs écrits cumulés et une écriture de temps cumulé (ms). Cela montrera vos partitions de système de fichiers chaudes.
cut -d" " -f 1,2,42 /proc/*/stat | sort -n -k +3
Ces champs sont PID, commande et ticks cumulés d'attente d'E/S. Cela montrera vos processus chauds, mais seulement s'ils sont toujours en cours d'exécution. (Vous voulez probablement ignorer vos threads de journalisation du système de fichiers.)
L'utilité de ce qui précède dépend de la disponibilité, de la nature de vos processus longs et de la façon dont vos systèmes de fichiers sont utilisés.
Avertissements: ne s'applique pas aux noyaux antérieurs à 2.6, consultez votre documentation en cas de doute.
(Maintenant rendez-vous service, installez Munin/Nagios/Cacti/peu importe ;-)
Utilisez atop. ( http://www.atoptool.nl/ )
Écrivez les données dans un fichier compressé que atop pourra lire plus tard dans un style interactif. Prenez une lecture (delta) toutes les 10 secondes. faites-le 1080 fois (3 heures; donc si vous l'oubliez, le fichier de sortie ne vous fera pas manquer de disque):
$ atop -a -w historical_everything.atop 10 1080 &
Après que la mauvaise chose se reproduise:
(même s'il fonctionne toujours en arrière-plan, il s'ajoute juste toutes les 10 secondes)
% atop -r historical_everything.atop
Puisque vous avez dit IO, je frapperais 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. Il 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 debugfs n'est pas activé dans le noyau, vous pouvez essayer date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtf ou similaire. La journalisation des erreurs de page n'est bien sûr pas du tout la même chose que l'utilisation de btrace, mais si vous êtes chanceux, cela PEUT vous donner un indice sur les processus les plus gourmands en disques. Je viens d'essayer celui-ci sur l'un de mes serveurs les plus gourmands en E/S et la liste comprenait les processus dont je sais qu'ils consomment beaucoup d'E/S.