Soluzione 1:
Se sei abbastanza fortunato da cogliere il prossimo periodo di picco di utilizzo, puoi studiare in modo interattivo le statistiche di I/O per processo, utilizzando iotop.
Soluzione 2:
Puoi usare pidstat per stampare statistiche io cumulative per processo ogni 20 secondi con questo comando:
# pidstat -dl 20
Ogni riga avrà le seguenti colonne:
- PID - ID processo
- kB_rd/s - Numero di kilobyte che l'attività ha fatto leggere dal disco al secondo.
- kB_wr/s - Numero di kilobyte che l'attività ha causato o causerà la scrittura su disco al secondo.
- kB_ccwr/s - Numero di kilobyte la cui scrittura su disco è stata annullata dall'attività. Ciò può verificarsi quando l'attività tronca alcune pagecache sporche. In questo caso, alcuni IO per i quali è stata contabilizzata un'altra attività non si verificheranno.
- Comando - Il nome del comando dell'attività.
L'output è simile a questo:
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]
Soluzione 3:
Niente batte il monitoraggio continuo, semplicemente non puoi recuperare i dati sensibili al tempo dopo l'evento...
Ci sono un paio di cose che potresti essere in grado di controllare per implicare o eliminare comunque — /proc è tuo amico.
sort -n -k 10 /proc/diskstats
sort -n -k 11 /proc/diskstats
I campi 10, 11 sono i settori scritti accumulati e il tempo accumulato (ms) di scrittura. Questo mostrerà le partizioni calde del tuo file system.
cut -d" " -f 1,2,42 /proc/[0-9]*/stat | sort -n -k +3
Questi campi sono PID, comando e tick cumulativi di attesa IO. Questo mostrerà i tuoi processi caldi, anche se solo se sono ancora in esecuzione . (Probabilmente vorrai ignorare i thread di journaling del tuo filesystem.)
L'utilità di quanto sopra dipende dal tempo di attività, dalla natura dei tuoi processi di lunga durata e da come vengono utilizzati i tuoi file system.
Avvertenze:non si applica ai kernel precedenti alla 2.6, controlla la tua documentazione se non sei sicuro.
(Ora vai e fai un favore a te stesso del futuro, installa Munin/Nagios/Cacti/qualsiasi cosa;-)
Soluzione 4:
Usa atop . (http://www.atoptool.nl/)
Scrivi i dati in un file compresso che atop può leggere più tardi in uno stile interattivo. Effettua una lettura (delta) ogni 10 secondi. fallo 1080 volte (3 ore; quindi se te ne dimentichi il file di output non ti esaurirà il disco):
$ atop -a -w historical_everything.atop 10 1080 &
Dopo che le cose brutte si ripetono:
(anche se è ancora in esecuzione in background, si aggiunge solo ogni 10 secondi)
% atop -r historical_everything.atop
Dato che hai detto IO, premerei 3 tasti: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
Soluzione 5:
Usa btrace . È facile da usare, ad esempio btrace /dev/sda . Se il comando non è disponibile, è probabilmente disponibile nel pacchetto blktrace .
MODIFICA :Poiché il debugfs non è abilitato nel kernel, potresti provare date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtf o simili. La registrazione degli errori di pagina ovviamente non è affatto la stessa cosa dell'utilizzo di btrace, ma se sei fortunato, POTREBBE darti qualche suggerimento sui processi più affamati di disco. Ho appena provato uno dei miei server più intensivi di I/O e l'elenco includeva i processi che so consumano molto I/O.