Solution 1 :
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.
Solution 2 :
Vous pouvez utiliser pidstat pour imprimer les statistiques cumulées d'E/S par processus toutes les 20 secondes avec cette commande :
# pidstat -dl 20
Chaque ligne aura les colonnes suivantes :
- PID - ID de processus
- kB_rd/s - Nombre de kilo-octets que la tâche a provoqué la lecture à partir du disque par seconde.
- kB_wr/s - Nombre de kilo-octets que la tâche a causé ou fera é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 OI pour lesquels une autre tâche a été comptabilisée ne se produiront pas.
- Command :le 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]
Solution 3 :
Rien ne vaut une surveillance continue, 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 pouvoir 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 accumulés et une écriture de temps accumulé (ms). Cela affichera vos partitions de système de fichiers chauds.
cut -d" " -f 1,2,42 /proc/[0-9]*/stat | sort -n -k +3
Ces champs sont le PID, la commande et les ticks cumulatifs 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 les threads de journalisation de votre système de fichiers.)
L'utilité de ce qui précède dépend de la disponibilité, de la nature de vos longs processus et de la manière dont vos systèmes de fichiers sont utilisés.
Mises en garde :ne s'applique pas aux noyaux antérieurs à la version 2.6, consultez votre documentation en cas de doute.
(Maintenant allez rendre service à votre futur moi, installez Munin/Nagios/Cacti/peu importe;-)
Solution 4 :
Utilisez atop . (http://www.atoptool.nl/)
Écrivez les données dans un fichier compressé qui atop peut 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 manquera pas de disque) :
$ atop -a -w historical_everything.atop 10 1080 &
Après qu'une mauvaise chose se reproduise :
(même s'il fonctionne toujours en arrière-plan, il s'ajoute toutes les 10 secondes)
% atop -r historical_everything.atop
Puisque vous avez dit IO, j'appuierais sur 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
Solution 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 .
MODIFIER :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 défauts de page n'est bien sûr pas du tout la même chose que l'utilisation de btrace, mais si vous avez de la chance, cela 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 comprenait les processus qui, je le sais, consomment beaucoup d'E/S.