Come verificare l'utilizzo dell'I / O del disco per processo

Sto avendo un problema con un sistema Linux in stallo e ho trovato sysstat / sar per riportare enormi picchi nell'utilizzo dell'I / O del disco, tempo medio di servizio e tempo medio di attesa al momento dello stallo del sistema.

Come potrei fare per determinare quale processo sta causando questi picchi la prossima volta che accadrà?
È possibile avere a che fare con sar (es .: posso trovare queste informazioni dai file sar registrati in alreade?

Uscita per "sar -d", lo stallo del sistema è avvenuto intorno alle 12.58-13.01pm.

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

Questa è una domanda di follow-up a un thread che ho iniziato ieri: picchi improvvisi in caricamento e blocco del disco in attesa , spero sia ok che ho creato un nuovo argomento / domanda sull'argomento poiché non sono stato ancora in grado di risolvere il problema.

Se sei abbastanza fortunato da raggiungere il prossimo periodo di picco di utilizzo, puoi studiare le statistiche I / O per processo in modo interattivo, usando iotop .

Puoi usare pidstat per stampare statistiche io cumulative per processo ogni 20 secondi con questo comando:

# pidstat -dl 20

Ogni riga avrà colonne seguenti:

• PID - ID processo
• kB_rd / s - Numero di kilobyte che l'attività ha causato la lettura dal disco al secondo.
• kB_wr / s - Numero di kilobyte causati dall'attività o che devono essere scritti sul 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 una pagecache sporca. In questo caso, alcuni IO che sono stati contabilizzati per un'altra attività non avverranno.
• Comando: il nome del comando dell'attività.

L'output è simile al seguente:

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]              

Nulla batte il monitoraggio in corso, semplicemente non è possibile recuperare i dati sensibili al tempo dopo l'evento ...

Ci sono un paio di cose che potresti essere in grado di verificare 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 settori scritti accumulati e scrittura del tempo accumulato (ms). Questo mostrerà le tue partizioni di file system attive.

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

Tali campi sono segni di spunta PID, comando e IO-wait cumulativi. Questo mostrerà i tuoi processi caldi, anche se solo se sono ancora in esecuzione . (Probabilmente vuoi ignorare i tuoi thread di journaling del filesystem.)

L'utilità di quanto sopra dipende dal tempo di attività, dalla natura dei processi di lunga durata e da come vengono utilizzati i file system.

Avvertenze: non si applica ai kernel precedenti alla 2.6, controllare la documentazione se non si è sicuri.

(Adesso vai a fare un favore al tuo futuro-sé, installa Munin / Nagios / Cacti / qualunque cosa ;-)

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

Scrivi i dati in un file compresso che atoppuò essere letto in seguito in uno stile interattivo. Prendi una lettura (delta) ogni 10 secondi. fatelo 1080 volte (3 ore; quindi se lo dimenticate, il file di output non vi farà uscire dal disco):

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

Dopo che succede qualcosa di brutto:

(anche se è ancora in esecuzione in background, si aggiunge solo ogni 10 secondi)

% atop -r historical_everything.atop

Da quando hai detto IO, avrei premuto 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

Usa btrace. È facile da usare, per esempio btrace /dev/sda. Se il comando non è disponibile, è probabilmente disponibile nel pacchetto blktrace .

EDIT : Poiché il debugfs non è abilitato nel kernel, potresti provare date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtfo simile. La registrazione degli errori della pagina non è ovviamente la stessa dell'uso di btrace, ma se sei fortunato, PUOI darti qualche suggerimento sui processi più affamati di disco. Ho appena provato che uno dei miei server più intensivi di I / O e l'elenco includeva i processi che conosco stanno consumando molti I / O.