☰

Medir las latencias de E/S del disco de un proceso en ejecución

tag-icon • tag-icon linux strace perf-event dtrace
Medir las latencias de E/S del disco de un proceso en ejecución

Estoy intentando medir las latencias de E/S del disco de un proceso en ejecución para hacer un histograma.

Podría hacer esto con DTrace en sistemas operativos que lo proporcionen (por ejemplo, como eneste documento de Joyent), pero mi aplicación se ejecuta en Linux. Lo primero que pensé fue intentarlo perfy puedo obtener contadores pero no encuentro ninguna forma de obtener deltas de tiempo. Puedo obtener deltas de tiempo con strace(por ejemplo strace -e read -T), pero no estoy seguro de poder restringir el seguimiento al disco IO (este sistema también tiene una interfaz de red ocupada).

¿Hay alguna forma de hacer esto en Linux?

Respuesta1

Esto es realmente complicado. Pero hay pistas:

  • Obtenga más información sobre SystemTap, este es un análogo de Linux de DTrace. Creo que incluso pueden tener un script de ejemplo para una tarea similar.

  • Aprenderrastro negro. En teoría, es posible que puedas analizar su resultado. Esto será más latencia del dispositivo (tiempo de servicio) quetiempo de respuestaprograma sigue adelante read().

Sí, stracepuede que no sea apropiado, ya que rastreará todo (todas las llamadas al sistema, incluso cuando use -eel filtro) y cargará el servidor y el proceso considerablemente más lento. PerfEs una herramienta muy oscura, es posible que haya momentos en los que crea que comprende su resultado, pero en realidad no es así, y su conjunto de funciones depende en gran medida de la versión del kernel. Básicamente y actualmente perfes adecuado para medirtiempo de CPU(ciclos), y [todavía] inadecuado para medirtiempos de respuesta(que realmente necesitas). Escuché que querían implementar algo para facilitar eso, por lo que en núcleos de desarrollo muy recientes puede haber algo. (Busque también en perf-scripts ( perf script -l) si desea investigar más).

  • Quizás puedas conseguir algo deftrace. Lee este artículohttp://lwn.net/Articles/370423/(Y esto para elintroducción.) Como puedo ver, puedes limitar el rastreo mediante pidy la función, y luego rastrear con algo como sys_read. Probé esto como ejemplo para ti:

    # mount -t debugfs debugfs /sys/kernel/debug # if it's not already mounted
# cd /sys/kernel/debug/tracing
# echo $$ > set_ftrace_pid  # pid of process to trace
# echo sys_read sys_write > set_ftrace_filter
# echo function_graph > current_tracer
# head trace

# tracer: function_graph
#
# CPU  DURATION                  FUNCTION CALLS
# |     |   |                     |   |   |   |
 0)   8.235 us    |  sys_write();
 0)   3.393 us    |  sys_write();
 0) ! 459859.3 us |  sys_read();
 0)   6.289 us    |  sys_write();
 0)   8.773 us    |  sys_write();
 0) ! 1576469 us |  sys_read();

Respuesta2

Si solo te interesa el número de llamadas de "lectura" o "escritura" para bloquear dispositivoseste es el SOP de Red Hat para determinar que.

Utilizando la función de volcado de bloques y un poco de secuencias de comandos, se puede obtener una descripción general de alto nivel sobre las acciones de E/S que están produciendo los procesos. Para ello, complete lo siguiente:

Deshabilite el registro del sistema por un corto período de tiempo (para que no interfiera con la captura de datos):

# parada de syslog de servicio # echo 1 > /proc/sys/vm/block_dump

Espere a que ocurra el problema de iowait alto, una vez que haya pasado, vuelva a habilitar syslog (o rsyslog si lo usa) y deshabilite el volcado de bloques:

# servicio syslog inicio # echo 0 > /proc/sys/vm/block_dump

Utilizando el siguiente comando, analice la salida de dmesg para acciones de LECTURA/ESCRITURA/sucias emitidas por ciertos procesos:

#dmesg | awk '/(LEER|ESCRIBIR|sucio)/ {actividad[$1]++} FINAL {para (x en actividad) imprimir x, actividad[x]}'| ordenar -nr -k 2,2| cabeza -n 10

kjournald(1425): 5984 kjournald(3681): 1269 pdflush(27301): 725 iostat(2913): 134 crond(26919): 61 crond(28985): 60 crond(7026): 54 sshd(28175): 50 sshd( 15388): 50 nautilos(24498): 46

El resultado de ejemplo anterior muestra los 10 procesos principales que emitieron operaciones de LECTURA, ESCRITURA y operaciones sucias durante el tiempo que se ejecutó el volcado de bloques. Al utilizar estos datos, se puede recopilar una descripción general de alto nivel de la cantidad de procesos de operaciones que están emitiendo y puede ayudar a determinar si un solo proceso está contribuyendo en gran medida a iowait.

También hay varias herramientas de línea de comandos como atop e iotop que le brindan estadísticas de iowait por proceso y se pueden ejecutar como parte de un script (lo que significa que tienen modos por lotes que pueden realizar una sola iteración para PID particulares).

EDITAR: Investigando más parece que puedesobtener iowait por proceso desde /proc/$pid/stat(busque "Retrasos de E/S de bloques agregados")

información relacionada