☰

¿Cómo comprobar la utilización de E/S del disco por proceso?

tag-icon • tag-icon linux storage io
¿Cómo comprobar la utilización de E/S del disco por proceso?

Tengo un problema con un sistema Linux y he encontrado sysstaty sarreportado picos enormes de E/S de disco, tiempo de servicio promedio y tiempo de espera promedio.

¿Cómo podría determinar qué proceso está causando estos picos la próxima vez que suceda?

¿Es posible hacerlo con sar? ¿Puedo encontrar esta información en los sararchivos ya grabados?

La salida del sar -dsistema se bloqueó alrededor de las 12.58-13.01 p.m.

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

También tengo esta pregunta de seguimiento de otro hilo que comencé ayer:

Respuesta1

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

Respuesta2

Puedes usarpidstatpara imprimir estadísticas de io acumuladas por proceso cada 20 segundos con este comando:

# pidstat -dl 20

Cada fila tendrá las siguientes columnas:

  • PID - ID de proceso
  • kB_rd/s: número de kilobytes que la tarea ha provocado que se lean desde el disco por segundo.
  • kB_wr/s: número de kilobytes que la tarea ha provocado o provocará que se escriban 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 alguna página caché sucia. En este caso, no se producirá alguna IO para la que se haya contabilizado otra tarea.
  • 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]

Respuesta3

No hay nada mejor que el monitoreo continuo, simplemente no es posible recuperar datos urgentes después del evento...

Hay un par de cosas quepodríaSin embargo, poder verificar para implicar o eliminar /proces tu 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á las particiones activas de su sistema de archivos.

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

Esos campos son PID, comando y ticks de espera de IO acumulativos. Esto mostrará sus procesos activos, aunque solosi todavía están corriendo. (Probablemente desee ignorar los subprocesos de registro en diario de su sistema de archivos).

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 los kernels anteriores a 2.6; consulte la documentación si no está seguro.

(Ahora ve y hazle un favor a tu futuro: instala Munin/Nagios/Cacti/lo que sea ;-)

Respuesta4

Usar btrace. Es fácil de usar, por ejemplo btrace /dev/sda. Si el comando no está disponible, probablemente esté disponible en el paqueterastro negro.

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

información relacionada