Solución 1:
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 forma interactiva mediante iotop.
Solución 2:
Puede usar pidstat para 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 del disco por segundo.
- kB_wr/s:número de kilobytes que la tarea ha causado o hará 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 caché de página sucia. En este caso, algunas IO para las que se ha tenido en cuenta otra tarea no se llevarán a cabo.
- 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]
Solución 3:
No hay nada mejor que el monitoreo continuo, simplemente no puede recuperar datos sensibles al tiempo después del evento...
Hay un par de cosas que podría ser capaz de comprobar para implicar o eliminar sin embargo - /proc es 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 E/S acumulativos. Esto mostrará sus procesos activos, aunque solo si aún se están ejecutando . (Probablemente desee ignorar los subprocesos de diario de su sistema de archivos).
La utilidad de lo anterior depende del tiempo de actividad, la naturaleza de sus procesos de ejecución prolongada y cómo se utilizan sus sistemas de archivos.
Advertencias:no se aplica a los kernels anteriores a la 2.6, consulte la documentación si no está seguro.
(Ahora ve y hazte un favor a ti mismo del futuro, instala Munin/Nagios/Cacti/lo que sea;-)
Solución 4:
Usa atop . (http://www.atoptool.nl/)
Escriba los datos en un archivo comprimido que atop puede leer más tarde en un estilo interactivo. Tome una lectura (delta) cada 10 segundos. hágalo 1080 veces (3 horas; de modo que si lo olvida, el archivo de salida no se quedará 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
Ya que 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
Solución 5:
Usa 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 debugfs no está habilitado en el núcleo, puede probar date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtf o 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 más intensivos en E/S y la lista incluye los procesos que sé que consumen muchas E/S.