strace y perf para la resolución de problemas en Linux

Cuando un servidor Linux va lento, se cuelga o consume demasiada CPU y los registros de la aplicación no explican el motivo, hay dos herramientas que cubren la mayor parte de las necesidades. strace te dice qué le está pidiendo un proceso al kernel. perf te dice en qué está invirtiendo su tiempo la CPU. Juntas responden a las preguntas «¿por qué se ha atascado?» y «¿qué está haciendo?», algo que ninguna otra herramienta resuelve de forma tan sencilla.

Esta entrada explica cuándo recurrir a cada herramienta, cómo instalarlas, los comandos que realmente ejecutarás y cómo mantener la sobrecarga bajo control en un servidor en producción.

Cuándo usar strace frente a perf

La diferencia es sencilla. Utiliza perf cuando la CPU esté ocupada y necesites saber qué función es la responsable. Usa strace cuando un proceso se cuelga, se bloquea, devuelve errores extraños o se comporta de una manera que los registros no explican.

perf muestra los contadores de hardware del kernel a una frecuencia configurable, por lo que la sobrecarga suele ser inferior al 1 % y es seguro ejecutarlo en producción. strace intercepta todas las llamadas al sistema a través de ptrace, lo que puede ralentizar el proceso de destino entre 10 y 100 veces. Úsalo con moderación en sistemas en producción y siempre con filtros.

Instalación de strace y perf

Ambas herramientas se encuentran en los repositorios estándar. strace se basa en la ptrace syscall, que forma parte de todos los kernels modernos desde hace años. perf utiliza la perf_events interfaz y necesita un paquete que se adapte al kernel que tengas en ejecución.

En Ubuntu o Debian:

sudo apt install strace linux-tools-common linux-tools-$(uname -r)

En RHEL, AlmaLinux o Fedora:

sudo dnf install strace perf

El $(uname -r) bit es importante. Un binario de perf compilado para una versión diferente del kernel produce resultados confusos y puede omitir eventos de forma silenciosa. Verifícalo con perf --version y strace -V después de la instalación.

Para que perf muestre nombres de funciones en lugar de direcciones hexadecimales, necesitas símbolos de depuración. Instala el -dbg o -debuginfo (por ejemplo, libc6-dbg en Debian) y compila tus propios binarios con -g en GCC.

Dentro de los contenedores, strace se necesita --cap-add=SYS_PTRACE y perf necesita --cap-add=SYS_ADMIN al iniciar con Docker. Sin estos límites, las herramientas fallan de formas que parecen errores.

Rastrear llamadas al sistema con strace

La ejecución de strace command rastrea un proceso desde su inicio. Para conectarse a un proceso en ejecución, utilice strace -p PID. Para cualquier proceso multihilo o que se bifurque, añade -f para seguir a los procesos hijos, o te perderás la mayor parte de la actividad.

Las líneas de salida terminan con un valor de retorno. -1 ENOENT significa que el archivo solicitado por el proceso no existe. -1 EACCES significa permisos. Esos dos errores por sí solos representan una proporción sorprendente de los errores de producción.

La bandera más útil es -e trace=GROUP, que limita la salida a una categoría de llamadas al sistema especificada y mantiene el ruido a un nivel manejable.

En un servidor con mucha actividad, empieza con strace -c -p PID durante diez o veinte segundos. La -c opción muestra un resumen del recuento de llamadas al sistema, el tiempo total y los errores al desconectarse. Esto le indica qué categoría merece un análisis más detallado sin saturar el terminal. A continuación, vuelva a conectarse con un filtro más específico.

Otras opciones que conviene conocer: -T registra el tiempo dedicado a cada llamada, -Z muestra solo las llamadas fallidas, y -o file escribe en un registro en lugar de en el terminal, lo cual es mucho más rápido en un proceso ruidoso.

Perfilado de la CPU con perf

perf tiene cuatro comandos que utilizarás la mayor parte del tiempo.

Empieza con perf stat -p PID para obtener una visión general rápida. Las cifras a tener en cuenta:

• IPC (instrucciones por ciclo) por debajo de 1,0: la CPU se está atascando, normalmente al acceder a la memoria.
• Altos índices de fallos de carga de la LLC: el conjunto de trabajo no cabe en la caché, por lo que la CPU está a la espera de la RAM.
• Número elevado de cambios de contexto: típico en cargas de trabajo limitadas por E/S, donde los subprocesos se bloquean continuamente en el disco o la red.

Si algo parece fuera de lugar, compruébalo con perf record -F 99 -g -p PID -- sleep 30. Las -F 99 muestra a 99 Hz, lo cual es suficiente para encontrar funciones críticas y evita la sincronización con el temporizador del kernel en valores redondos como 100 Hz. La -g captura gráficos de llamadas, por lo que perf report pueda mostrarte qué rutas de acceso a una función son las responsables.

En perf report, la columna «Overhead» es la proporción del total de muestras. Una sobrecarga elevada en _int_malloc o memcpy indica una asignación intensiva. Una sobrecarga elevada en una de tus propias funciones es el punto crítico que estabas buscando.

Si ves direcciones hexadecimales en lugar de nombres de funciones, el binario está desmontado o faltan los símbolos de depuración. Instala el -dbg o recompila el binario con -g.

Un flujo de trabajo práctico en un servidor en producción

En caso de un incidente real en un equipo muy activo, el procedimiento es el siguiente:

1. Confirma primero el síntoma con herramientas sencillas: top, vmstat, iostat. Si estás en una máquina virtual, comprueba la st columna (steal). Cualquier valor superior al 5 % significa que el hipervisor es el cuello de botella, no tu código.
2. Si la CPU está alta, ejecuta perf top durante unos segundos y, a continuación, perf record -F 99 -g -p PID -- sleep 30 para el proceso problemático. Una captura de 30 segundos a 99 Hz genera unos 1,7 MB de datos.
3. Si el proceso se ha colgado, va lento o devuelve errores, ejecuta strace -c -p PID durante diez segundos y lee el resumen. Si predomina una categoría de llamadas al sistema, acota la búsqueda con strace -e trace=GROUP -T -p PID.
4. Cuando hayas encontrado la llamada al sistema o la función sospechosa, desconéctate. No dejes ninguna de las herramientas ejecutándose en producción más tiempo del necesario.

Dos advertencias. strace La salida puede incluir variables de entorno, rutas de archivos y bytes leídos de sockets, así que depura los registros antes de compartirlos fuera de tu equipo. Y si vas a hacer esto con regularidad, echa un vistazo a bpftrace y el kit de herramientas eBPF más amplio como siguiente paso: el mismo tipo de visibilidad, una sobrecarga inferior al 1 %, diseñado para producción desde el principio.

Si ejecutas cargas de trabajo en las que el acceso a diagnósticos en profundidad es importante y la infraestructura compartida no es una opción, echa un vistazo a nuestros servidores dedicados.