Resumir el tiempo en llamadas al sistema con strace -c, su sobrecarga y perf trace como alternativa

Objetivo

Obtener un resumen ordenado de en qué llamadas al sistema pasa el tiempo un proceso, en lugar de una traza en vivo que se desplaza sin parar, y saber cuándo el propio trazado se convierte en el cuello de botella.

Requisitos previos

El paquete strace. Trazar un comando que uno mismo lanza (strace -c <command>) no requiere privilegios adicionales; adjuntarse a un proceso en ejecución con -p requiere root o CAP_SYS_PTRACE, salvo que la configuración Yama kernel.yama.ptrace_scope lo permita (con el valor habitual 1, un usuario sin privilegios solo puede adjuntarse a sus propios descendientes). perf, si se necesita la alternativa del paso 4.

Pasos

1. Adjúntese durante un tiempo acotado y después desadjúntese, por ejemplo con timeout 20 strace -c -f -p <pid>; sin -f, -p se adjunta solo al hilo cuyo ID es <pid> y pasa por alto los hilos de trabajo de un servidor multihilo. El manual de strace describe -c/--summary-only como la opción que cuenta tiempo, llamadas y errores de cada llamada al sistema y muestra un resumen al terminar, suprimiendo la salida habitual de cada llamada. Es la vista agregada que necesita la pregunta «qué syscall domina». El manual señala además que lo que se muestra es tiempo de sistema (tiempo de CPU del kernel), independiente del tiempo real transcurrido (wall-clock).
2. Lea primero el resumen ordenado por porcentaje de tiempo. Como la medida por defecto es el tiempo de CPU del kernel, las llamadas que sobre todo se bloquean (futex, epoll_wait, un read sobre un socket) parecen baratas con esa medida. Añada -w/--summary-wall-clock para ordenar las llamadas por tiempo real desde la entrada hasta la salida cuando la pregunta es dónde espera el proceso. Un tiempo elevado en futex o epoll_wait apunta entonces a contención o a espera ociosa, y en read/write a E/S.
3. Conozca el coste antes de fiarse de los números: el manual de strace afirma sin rodeos que un proceso trazado se ejecuta más despacio que uno no trazado, y que el impacto en el rendimiento puede mitigarse con la opción --seccomp-bpf. Esa opción solo surte efecto junto con -f, no es aplicable a procesos a los que uno se adjunta con -p y únicamente ahorra paradas cuando se traza un subconjunto de llamadas (-e trace=...), así que no ayuda en el caso anterior de adjuntarse y contar. En un proceso sensible a la latencia, esta sobrecarga puede alterar por sí misma el comportamiento que se quiere observar.
4. Cuando esa sobrecarga importe, use perf trace en su lugar. Su manual lo presenta como una herramienta inspirada en strace que informa del mismo tipo de actividad de llamadas al sistema y de eventos del sistema, en vivo o a partir de una sesión grabada antes con perf record, y que se apoya en la infraestructura de tracepoints y perf_events del kernel en lugar de ptrace. Pruebe perf trace -p <pid> para una vista en vivo, o perf trace -s -p <pid> para un resumen por hilo con tiempos mínimo, medio y máximo; normalmente requiere root.
5. No dé por supuesta una diferencia porcentual fija entre ambas herramientas sin medirla con la carga de trabajo real: ninguno de los dos manuales indica una cifra numérica de sobrecarga, y el coste relativo depende de cuántas llamadas al sistema realice la carga.

Resultado esperado

Una lista ordenada de las llamadas al sistema que más tiempo consumieron y de cuántas veces se invocaron, obtenida sin una traza completa línea por línea, y una elección fundamentada entre la simplicidad de strace -c y el perfil de sobrecarga distinto de perf trace.

Límites y base de verificación

Ambas herramientas solo ven la actividad posterior al momento de adjuntarse; un pico anterior pasa desapercibido. -f/--follow-forks es necesario para contar también las llamadas de los procesos hijo y, con -p, las de los demás hilos. Desadjúntese en cuanto tenga el resumen, ya que la sobrecarga se aplica durante todo el tiempo que se permanece adjunto, no solo mientras se lee la salida.