Cómo verificar la utilización de E / S de disco por proceso

Tengo un problema con un sistema Linux estancado y he encontrado que sysstat / sar informa picos enormes en la utilización de E / S de disco, el tiempo de servicio promedio y el tiempo de espera promedio en el momento del bloqueo del sistema.

¿Cómo podría determinar qué proceso está causando estos picos la próxima vez que ocurra?
¿Es posible hacerlo con sar (es decir: ¿puedo encontrar esta información en los archivos sar grabados alreade?

Salida para "sar -d", el bloqueo del sistema ocurrió alrededor de las 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

Esta es una pregunta de seguimiento a un hilo que comencé ayer: picos repentinos en la carga y la espera del bloqueo del disco , espero que esté bien que haya creado un nuevo tema / pregunta sobre el asunto ya que aún no he podido resolver el problema.

Si tiene la suerte de alcanzar el próximo período de utilización máxima, puede estudiar las estadísticas de E / S por proceso de manera interactiva, utilizando iotop .

Puede usar pidstat para imprimir estadísticas acumulativas de io por proceso cada 20 segundos con este comando:

# pidstat -dl 20

Cada fila tendrá las siguientes columnas:

• PID - ID del proceso
• kB_rd / s: número de kilobytes que la tarea ha provocado que se lea desde el disco por segundo.
• kB_wr / s: número de kilobytes que la tarea ha causado, o hará que se escriba en el disco por segundo.
• kB_ccwr / s: número de kilobytes cuya escritura en el disco ha sido cancelada por la tarea. Esto puede ocurrir cuando la tarea trunca algún caché de página sucio. En este caso, algunas IO que otra tarea ha sido contabilizada no sucederán.
• Comando: el nombre del comando de la tarea.

La salida se ve así:

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]              

No hay nada mejor que la supervisión continua, simplemente no puede recuperar datos urgentes después del evento ...

Sin embargo, hay un par de cosas que puede verificar para implicar o eliminar: /proces su amigo.

sort -n -k 10 /proc/diskstats
sort -n -k 11 /proc/diskstats

Los campos 10, 11 son sectores escritos acumulados y tiempo acumulado (ms) de escritura. Esto mostrará sus particiones del sistema de archivos en caliente.

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

Esos campos son PID, comando y ticks acumulativos IO-wait. Esto mostrará sus procesos activos, aunque solo si todavía se están ejecutando . (Probablemente quiera ignorar su sistema de archivos con subprocesos diarios).

La utilidad de lo anterior depende del tiempo de actividad, la naturaleza de sus procesos de larga ejecución y cómo se utilizan sus sistemas de archivos.

Advertencias: no se aplica a núcleos anteriores a 2.6, consulte su documentación si no está seguro.

(Ahora ve y hazte un favor a ti mismo en el futuro, instala Munin / Nagios / Cacti / lo que sea ;-)

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

Escriba los datos en un archivo comprimido que atoppueda leer más tarde en un estilo interactivo. Tome una lectura (delta) cada 10 segundos. hazlo 1080 veces (3 horas; así que si lo olvidas, el archivo de salida no te dejará sin disco):

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

Después de que algo malo vuelva a suceder:

(incluso si todavía se está ejecutando en segundo plano, solo se agrega cada 10 segundos)

% atop -r historical_everything.atop

Como dijiste IO, presionaría 3 teclas: 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

Uso btrace. Es fácil de usar, por ejemplo btrace /dev/sda. Si el comando no está disponible, probablemente esté disponible en el paquete blktrace .

EDITAR : Dado que el debugfs no está habilitado en el núcleo, puede intentarlo date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtfo similar. Por supuesto, registrar las fallas de la página no es lo mismo que usar btrace, pero si tiene suerte, PUEDE darle alguna pista sobre los procesos con más disco duro. Acabo de probar uno de mis servidores más intensivos de E / S y la lista incluye los procesos que sé que consumen muchas E / S.