trace-cmd-record: en línea en la nube

PROGRAMA:

NOMBRE

trace-cmd-record: registra un rastreo del rastreador interno de Ftrace Linux

SINOPSIS

seguimiento-cmd grabar [OPCIONES] [comando]

DESCRIPCIÓN

La planta de seguimiento-cmd(1) el comando de registro configurará el rastreador del kernel de Ftrace Linux para registrar el
complementos especificados o eventos que suceden mientras el comando ejecuta. Si no hay comando
dado, luego grabará hasta que el usuario presione Ctrl-C.

El comando de registro de trace-cmd configurará el trazador Ftrace para comenzar a rastrear los distintos
eventos o complementos que se proporcionan en la línea de comando. A continuación, creará una serie de
procesos de seguimiento (uno por CPU) que comenzarán a grabar desde el búfer de anillo del kernel
directamente en archivos temporales. Cuando se completa el comando (o se presiona Ctrl-C) todos los
Los archivos se combinarán en un archivo trace.dat que luego se puede leer (ver
seguimiento-cmd-informe(1)).

OPCIONES

-p plugin
Especifique un complemento de seguimiento. Los complementos son rastreadores especiales de Ftrace que suelen hacer más que
solo rastrea un evento. Los complementos comunes son función, gráfico_función, preemptirqsoff,
irqsoff, anticiparsey despierta. Un complemento debe ser compatible con el kernel en ejecución. Para
ver una lista de complementos disponibles, ver rastrear-cmd-list(1).

-e evento
Especifique un evento para rastrear. Se han agregado varios puntos de seguimiento estáticos a Linux
núcleo. Están agrupados por subsistema donde puede habilitar todos los eventos de un determinado
subsistema o especificar eventos específicos que se habilitarán. los evento es del formato
"subsistema: nombre-evento". También puede especificar el subsistema sin el
:nombre del evento o el nombre del evento sin el "subsistema:". El uso de "-e sched_switch"
habilitar el evento "sched_switch" donde como, "-e sched" habilitará todos los eventos bajo el
subsistema "sched".

El 'evento' también puede contener expresiones globales. Es decir, "* stat *"
seleccionar todos los eventos (o subsistemas) que tienen los caracteres "stat" en su
Nombres

La palabra clave "todos" se puede utilizar para habilitar todos los eventos.

-a
Cada evento que se está grabando tiene su archivo de formato de salida guardado en el archivo de salida
para poder visualizarlo más tarde. Pero si otros eventos están habilitados en el seguimiento sin
el conocimiento de trace-cmd, los formatos de esos eventos no serán registrados y trace-cmd
informe no podrá mostrarlos. Si este es el caso, especifique el -a
Se guardará la opción y el formato para todos los eventos en el sistema.

-T
Habilite un seguimiento de pila en cada evento. Por ejemplo:

-0 [003] 58549.289091: sched_switch: kworker / 0: 1: 0 [120] R ==> trace-cmd: 2603 [120]
-0 [003] 58549.289092: kernel_stack:
=> horario (ffffffff814b260e)
=> cpu_idle (ffffffff8100a38c)
=> inicio_secundario (ffffffff814ab828)

--func-pila
Habilite un seguimiento de pila en todas las funciones. Tenga en cuenta que esto solo es aplicable para la "función"
plugin tracer, y solo tendrá efecto si se usa la opción -l y tiene éxito en
funciones limitantes. Si el rastreador de funciones no se filtra y el rastreo de la pila es
habilitado, puede bloquear la máquina en vivo.

-f filtrar
Especifique un filtro para el evento anterior. Esto debe venir después de un -e. Esto filtrará
qué eventos se registran según el contenido del evento. El filtrado se pasa al
kernel directamente, por lo que el filtrado permitido puede depender de la versión del kernel
tú tienes. Básicamente, le permitirá usar la notación C para verificar si un evento debe ser
procesado o no.

==,> =, <=,>, <, &, |, && y ||

Los anteriores suelen ser seguros para comparar campos.

-R detonante
Especifique un desencadenante para el evento anterior. Esto debe venir después de un -e. Esto agregará un
disparador dado al evento dado. Para habilitar solo el disparador y no el evento en sí,
luego coloque el evento después del -v .

Consulte Documentation / trace / events.txt en la fuente del kernel de Linux para obtener más información.
información sobre los factores desencadenantes.

-v
Esto hará que no se rastreen todos los eventos especificados después de él en la línea de comando.
Esto es útil para seleccionar un subsistema a rastrear, pero para omitir varios eventos.
Por ejemplo: "-e sched -v -e" * stat \ * "" habilitará todos los eventos en el subsistema sched
excepto aquellos que tienen "stat" en sus nombres.

Nota: la opción * -v * se tomó de la forma grep(1) invierte lo siguiente
partidos.

-F
Esto filtrará solo el ejecutable que se proporciona en la línea de comando. Si no hay comando
se da, luego se filtrará a sí mismo (bastante inútil). Utilizando -F te dejará rastrear
solo eventos que son causados ​​por el comando dado.

-P pid
Similar a -F pero le permite especificar un ID de proceso para rastrear.

-c
Usado con cualquiera -F para rastrear a los hijos del proceso también.

-C reloj
Configure el reloj de seguimiento en "reloj".

Utilizar la seguimiento-cmd(1) lista -C para ver qué relojes están disponibles.

-o archivo de salida
De forma predeterminada, el informe trace-cmd creará un rastrear.dat expediente. Puede especificar una
archivo para escribir con el -o .

-l nombre de la función
Esto limitará el función y gráfico_función trazadores para rastrear solo lo dado
nombre de la función. Más de uno -l puede especificarse en la línea de comando para rastrear más
de una función. También se permite el uso limitado de expresiones glob. Estos son
fósforo* para filtrar solo las funciones que comienzan con partido. *fósforo solo filtrar
funciones que terminan con partido. *fósforo\* para filtrar solo en funciones que contienen
partido.

-g nombre de la función
Esta opción es para el complemento function_graph. Graficará la función dada. Ese
es decir, solo rastreará la función y todas las funciones que llame. Puedes tener mas
de una -g en la línea de comando.

-n nombre de la función
Esto tiene el efecto contrario de -l. La función dada con el -n la opción no será
rastreado. Esto tiene prioridad, es decir, si incluye la misma función para ambos -n
y -l, no se rastreará.

-d
Algunos complementos de seguimiento habilitan la función de seguimiento de forma predeterminada. Como los trazadores de latencia.
Esta opción evita que se habilite la función trazador al inicio.

-D
La opción -d intentará usar la opción de rastreo de función para deshabilitar el rastreo de función
(si está disponible), de lo contrario, se establece de forma predeterminada en el archivo proc:
/ proc / sys / kernel / ftrace_enabled, pero no lo tocará si la opción de rastreo de función es
disponible. los -D La opción deshabilitará tanto el archivo proc ftrace_enabled como el
opción de seguimiento de función si existe.

Tenga en cuenta que esta función deshabilita el seguimiento para todos los usuarios, que incluye a los usuarios
fuera de los trazadores ftrace (stack_tracer, perf, etc.).

-O opción
Ftrace tiene varias opciones que se pueden habilitar o deshabilitar. Esto le permite configurar
ellos. Anexando el texto no a una opción la desactiva. Por ejemplo: "-O nograph-time"
desactivará la opción Ftrace "graph-time".

-s intervalo
Los procesos que trace-cmd crea para grabar desde el búfer de anillo deben activarse para
hacer la grabación. Establecer el intervalo a cero hará que los procesos se despierten
cada vez que se escriben nuevos datos en el búfer. Pero dado que Ftrace está grabando el kernel
actividad, el hecho de que estos procesos vuelvan a dormir puede causar nuevos eventos en el
búfer de anillo que reactivará el proceso. Esto agregará datos adicionales innecesariamente
en el búfer de anillo.

La métrica del 'intervalo' es microsegundos. El valor predeterminado está establecido en 1000 (1 ms).
Este es el tiempo que duerme cada proceso de grabación antes de despertarse
registre cualquier dato nuevo que se haya escrito en el búfer de anillo.

-r lista de prioridades
La prioridad en la que se ejecutarán los subprocesos de captura. En un sistema ocupado, la captura de trazas
los hilos se pueden retener y los eventos se pueden perder. Esto aumenta la prioridad de aquellos
subprocesos a la prioridad de tiempo real (FIFO). Pero use esta opción con cuidado, también puede
cambiar el comportamiento del sistema que se está rastreando.

-b tamaño
Esto establece el tamaño del búfer de anillo en tamaño kilobytes. Debido a que el búfer de anillo Ftrace es
por CPU, este tamaño es el tamaño de cada búfer de anillo por CPU dentro del kernel. Utilizando
"-b 10000" en una máquina con 4 CPU hará que Ftrace tenga un tamaño de búfer total de 40
Megas.

-B nombre-búfer
Si el kernel admite varios búferes, esto agregará un búfer con el nombre dado.
Si el nombre del búfer ya existe, ese búfer simplemente se restablece y no se eliminará
al final de la ejecución del registro. Si se crea el búfer, se eliminará en el
final de la ejecución (a menos que el -k está configurado, o comienzo se utilizó el comando).

Después de que se indica un nombre de búfer, todos los eventos agregados después de eso serán
asociado con ese búfer. Si no se especifica un búfer o un evento
se especifica antes de un nombre de búfer, se asociará con el
búfer principal (nivel superior).

registro de seguimiento-cmd -e programado -B bloque -e bloque -B tiempo -e temporizador de suspensión 1

Lo anterior habilitará todos los eventos programados en el búfer principal. Va a
luego cree una instancia de búfer de 'bloque' y habilite todos los eventos de bloque dentro
ese búfer. Se crea una instancia de búfer de 'tiempo' y todos los eventos del temporizador
estará habilitado para ese evento.

-m tamaño
El tamaño máximo en kilobytes que debe tener un búfer por cpu. Nota, debido al redondeo a
tamaño de página, es posible que el número no sea totalmente correcto. Además, esto se realiza cambiando
entre dos búferes que tienen la mitad del tamaño dado, por lo que la salida puede no ser del
tamaño dado incluso si se escribió mucho más.

Utilice esto para evitar quedarse sin espacio en disco durante ejecuciones largas.

-M pumask
Configure la cpumask para rastrear. Solo afecta a la última instancia de búfer proporcionada. Si
suministrado antes de cualquier instancia de búfer, entonces afecta al búfer principal. El valor
suministrado debe ser un número hexadecimal.

Traza-cmd registro -p función -M c -B eventos13 -e todo -M 5

Si se omite -M, la máscara permanece igual. Para habilitar todo
CPU, pasan un valor de '-1'.

-k
De forma predeterminada, cuando trace-cmd termine de rastrear, restablecerá los búferes y desactivará
todo el rastreo que habilitó. Esta opción evita que trace-cmd deshabilite el trazador
y resetear el búfer. Esta opción es útil para depurar trace-cmd.

Nota: por lo general, trace-cmd volverá a establecer el archivo "tracing_on" en lo que
fue antes de que se llamara. Esta opción dejará ese archivo en cero.

-i
De forma predeterminada, si se incluye un evento que trace-cmd no encuentra, se cerrará con un
error. Esta opción simplemente ignorará los eventos que se enumeran en la línea de comando pero que son
no encontrado en el sistema.

-N Puerto host
Si otra máquina está ejecutando "trace-cmd listen", esta opción se usa para tener los datos
enviado a esa máquina con paquetes UDP. En lugar de escribir en un archivo de salida, los datos
se envía a una caja remota. Esto es ideal para máquinas integradas con poco almacenamiento,
o tener una sola máquina que mantendrá todos los datos en un solo repositorio.

Nota: esta opción no es compatible con los complementos de seguimiento de latencia:
wakeup, wakeup_rt, irqsoff, preemptoff y preemptirqsoff

-t
Esta opción se usa con -N, cuando es necesario enviar datos en vivo con TCP
paquetes en lugar de UDP. Aunque TCP no es tan rápido como enviar paquetes UDP,
pero puede ser necesario si la red no es tan confiable, la cantidad de datos no es
tan intensivo, y se necesita una garantía de que toda la información rastreada se transfiere
con éxito garantizado.

--fecha
Con el --fecha opción, "trace-cmd" escribirá marcas de tiempo en el búfer de seguimiento después
ha terminado de grabar. Luego, mapeará la marca de tiempo para obtener la hora del día, que
permitir la salida de tiempo de pared de las marcas de tiempo que leen el creado rastrear.dat .

--perfil
Con el --perfil opción, "trace-cmd" habilitará el rastreo que se puede usar con
seguimiento-cmd-informe(1) - opción de perfil. Si un trazador -p no está configurado, y el gráfico de función
profundidad es compatible con el kernel, entonces el trazador function_graph se habilitará con
una profundidad de uno (solo muestra dónde entra el espacio de usuario en el kernel). También permitirá
varios puntos de seguimiento con seguimiento de pila de modo que el informe pueda mostrar dónde se han realizado las tareas
estado bloqueado durante más tiempo.

See rastrear-cmd-perfil(1) para obtener más detalles y ejemplos.

-H eventos-ganchos
Agregue coincidencia de eventos personalizados para conectar dos eventos. Cuando no se usa con
--perfil, guardará el parámetro y este será utilizado por el informe trace-cmd
- perfil también. Es decir:

registro trace-cmd -H hrtimer_expire_entry, hrtimer / hrtimer_expire_exit, hrtimer, sp
informe trace-cmd --profile

Perfilará hrtimer_expire_entry y hrtimer_expire_ext veces.

See rastrear-cmd-perfil(1) para formato.

--stderr
Hacer que la salida vaya a stderr en lugar de stdout, pero la salida del comando se ejecutó
no se cambiará. Esto es útil si desea monitorear la salida del comando
se está ejecutando, pero no ve la salida de trace-cmd.

EJEMPLOS

La forma básica de rastrear todos los eventos:

# trace-cmd record -e all ls> / dev / null
# informe trace-cmd
trace-cmd-13541 [003] 106260.693809: filemap_fault: dirección = 0x128122 offset = 0xce
trace-cmd-13543 [001] 106260.693809: kmalloc: call_site = 81128dd4 ptr = 0xffff88003dd83800 bytes_req = 768 bytes_alloc = 1024 gfp_flags = GFP_KERNEL | GFP_ZERO
ls-13545 [002] 106260.693809: kfree: call_site = 810a7abb ptr = 0x0
ls-13545 [002] 106260.693818: sys_exit_write: 0x1

Para usar el rastreador de funciones con rastreo de conmutador programado:

# trace-cmd record -p función -e sched_switch ls> / dev / null
# informe trace-cmd
ls-13587 [002] 106467.860310: función: hrtick_start_fair <- pick_next_task_fair
ls-13587 [002] 106467.860313: sched_switch: prev_comm = trace-cmd prev_pid = 13587 prev_prio = 120 prev_state = R ==> next_comm = trace-cmd next_pid = 13583 next_prio = 120
trace-cmd-13585 [001] 106467.860314: función: native_set_pte_at <- __do_fault
trace-cmd-13586 [003] 106467.860314: función: up_read <- do_page_fault
ls-13587 [002] 106467.860317: función: __phys_addr <- horario
trace-cmd-13585 [001] 106467.860318: función: _raw_spin_unlock <- __do_fault
ls-13587 [002] 106467.860320: función: native_load_sp0 <- __switch_to
trace-cmd-13586 [003] 106467.860322: función: down_read_trylock <- do_page_fault

Aquí hay una buena manera de encontrar qué interrupciones tienen la latencia más alta:

# trace-cmd record -p function_graph -e irq_handler_entry -l do_IRQ sleep 10
# informe trace-cmd
-0 [000] 157412.933969: entrada_funcgraph: | do_IRQ () {
-0 [000] 157412.933974: irq_handler_entry: irq = 48 nombre = eth0
-0 [000] 157412.934004: funcgraph_exit: + 36.358 us | }
-0 [000] 157413.895004: entrada_funcgraph: | do_IRQ () {
-0 [000] 157413.895011: irq_handler_entry: irq = 48 nombre = eth0
-0 [000] 157413.895026: funcgraph_exit: + 24.014 us | }
-0 [000] 157415.891762: entrada_funcgraph: | do_IRQ () {
-0 [000] 157415.891769: irq_handler_entry: irq = 48 nombre = eth0
-0 [000] 157415.891784: funcgraph_exit: + 22.928 us | }
-0 [000] 157415.934869: entrada_funcgraph: | do_IRQ () {
-0 [000] 157415.934874: irq_handler_entry: irq = 48 nombre = eth0
-0 [000] 157415.934906: funcgraph_exit: + 37.512 us | }
-0 [000] 157417.888373: entrada_funcgraph: | do_IRQ () {
-0 [000] 157417.888381: irq_handler_entry: irq = 48 nombre = eth0
-0 [000] 157417.888398: funcgraph_exit: + 25.943 us | }

Un ejemplo del perfil:

# trace-cmd registro --perfil dormir 1
# informe trace-cmd --profile --comm sleep
tarea: sueño-21611
Evento: sched_switch: R (1) Total: 99442 Promedio: 99442 Máx .: 99442 Mín: 99442
1 total: 99442 mínimo: 99442 máximo: 99442 promedio = 99442
=> ftrace_raw_event_sched_switch (0xffffffff8105f812)
=> __schedule (0xffffffff8150810a)
=> preempt_schedule (0xffffffff8150842e)
=> ___preempt_schedule (0xffffffff81273354)
=> cpu_stop_queue_work (0xffffffff810b03c5)
=> detener_una_cpu (0xffffffff810b063b)
=> sched_exec (0xffffffff8106136d)
=> do_execve_common.isra.27 (0xffffffff81148c89)
=> do_execve (0xffffffff811490b0)
=> SyS_execve (0xffffffff811492c4)
=> return_to_handler (0xffffffff8150e3c8)
=> stub_execve (0xffffffff8150c699)
Evento: sched_switch: S (1) Total: 1000506680 Promedio: 1000506680 Max: 1000506680 Min: 1000506680
1 total: 1000506680 mínimo: 1000506680 máximo: 1000506680 promedio = 1000506680
=> ftrace_raw_event_sched_switch (0xffffffff8105f812)
=> __schedule (0xffffffff8150810a)
=> horario (0xffffffff815084b8)
=> do_nanosleep (0xffffffff8150b22c)
=> hrtimer_nanosleep (0xffffffff8108d647)
=> SyS_nanosleep (0xffffffff8108d72c)
=> return_to_handler (0xffffffff8150e3c8)
=> tracesys_phase2 (0xffffffff8150c304)
Evento: sched_wakeup: 21611 (1) Total: 30326 Promedio: 30326 Max: 30326 Min: 30326
1 total: 30326 mínimo: 30326 máximo: 30326 promedio = 30326
=> ftrace_raw_event_sched_wakeup_template (0xffffffff8105f653)
=> ttwu_do_wakeup (0xffffffff810606eb)
=> ttwu_do_activate.constprop.124 (0xffffffff810607c8)
=> try_to_wake_up (0xffffffff8106340a)

Use trace-cmd-record en línea usando los servicios de onworks.net