Flame graphs: el perfil de CPU de un vistazo

Un perf report con diez mil pilas de llamadas es un muro de texto que nadie lee entero. El ojo humano no está hecho para tablas de porcentajes anidados, pero sí para las formas. El flame graph, inventado por Brendan Gregg, hace la traducción: toma esas miles de pilas muestreadas y las pliega en una única imagen donde cada función es una caja, el ancho de la caja es la proporción de tiempo que la CPU pasó allí, y la altura es la profundidad de la pila. Lo que en texto exige minutos de rastreo, en la imagen salta a la vista en segundos: las mesetas anchas de la cima son exactamente donde arde el procesador.

Anatomía de un flame graph

La regla de lectura es contraintuitiva y hay que grabársela. El eje Y es profundidad de pila: la caja de abajo es la raíz —main o el hilo del kernel— y cada caja encima es una función llamada por la de debajo. El eje X no es tiempo: las cajas se ordenan alfabéticamente para fundir las pilas idénticas, de modo que el ancho de una caja es la fracción de muestras en que esa función aparecía en la pila, es decir, la proporción de tiempo de CPU que consumió ella y sus hijas. No hay flujo temporal de izquierda a derecha; hay población.

De ahí se sigue cómo se interpreta. Buscas las cajas anchas, no las altas: una torre estrecha y altísima es una pila profunda que casi no consume tiempo, mientras que una meseta ancha en la cima es una función hoja que está quemando la CPU ahora mismo, sin llamar a nadie más. Ese es el sospechoso. Una caja ancha en la base con muchas hijas estrechas reparte su coste; una caja ancha arriba lo concentra.

El flujo canónico

Un flame graph nace de tres transformaciones sobre un perfil de perf. Primero muestreas con pilas; luego despliegas cada muestra a una línea de texto; luego pliegas las pilas idénticas contándolas; y finalmente dibujas el SVG. Cada paso es una herramienta pequeña encadenada por tuberías, en la mejor tradición Unix.

# 1. muestrear a 99 Hz, toda la maquina, con pilas, durante 30 s
perf record -F 99 -a -g -- sleep 30

# 2. desplegar el perf.data binario a texto, una linea por marco
perf script > perfiles.txt

# 3. plegar cada pila a una sola linea con su cuenta al final
./stackcollapse-perf.pl perfiles.txt > perfiles.folded

# 4. dibujar el SVG interactivo
./flamegraph.pl perfiles.folded > flame.svg

El formato plegado intermedio es transparente y merece verse: cada línea es una pila única, con sus funciones separadas por punto y coma de la raíz a la hoja, y al final el número de muestras que la recorrieron.

mi_prog;main;parse_line;hash_bucket;crc32 482
mi_prog;main;parse_line;memmove 217
mi_prog;main;flush_output 95

Ese texto plano es lo que flamegraph.pl convierte en cajas: cada segmento entre puntos y comas es un nivel, y la cuenta final fija el ancho. Porque el formato es tan simple, cualquier fuente de pilas —no solo perf— puede alimentar el dibujante, y por eso los flame graphs se generalizaron a memoria, bloqueos y esperas.

flowchart LR
REC[perf record -F 99 -g] --> SCRIPT[perf script]
SCRIPT --> COLLAPSE[stackcollapse-perf.pl]
COLLAPSE --> FOLDED[pilas plegadas y contadas]
FOLDED --> FG[flamegraph.pl]
FG --> SVG[flame.svg interactivo]

En los núcleos y las herramientas de 2026 hay un atajo integrado: perf script report flamegraph genera directamente un flame graph interactivo en HTML con D3, sin scripts externos, y GUIs como Hotspot leen el perf.data y lo pintan al vuelo. Pero conocer la tubería clásica sigue importando, porque es la que se adapta a cualquier fuente de pilas.

Desenrollar la pila: marcos, DWARF o LBR

Todo depende de que perf sepa reconstruir la pila de llamadas en cada muestra, y hay tres métodos con compromisos distintos. Con marcos de pila (--call-graph fp) sigues el encadenamiento del registro de base; es baratísimo, pero exige que el código se compilara con -fno-omit-frame-pointer, algo que las distribuciones abandonaron durante años por rendimiento y han vuelto a activar. Con DWARF (--call-graph dwarf) perf copia un trozo de la pila en cada muestra y la desenrolla después con la información de depuración; funciona sin marcos, pero infla el perf.data y pesa más. Con LBR (--call-graph lbr) usas el registro hardware de últimos saltos del procesador; es preciso y ligero, pero de profundidad limitada.

# DWARF: pilas correctas aunque el binario no tenga frame pointers
perf record --call-graph dwarf -F 99 -g ./mi_programa

# LBR: desenrollado por hardware, sin necesidad de frame pointers
perf record --call-graph lbr -F 99 ./mi_programa

Si tu flame graph aparece truncado o lleno de [unknown], casi siempre es el desenrollado: faltan marcos de pila y no pediste DWARF. La elección del método es la decisión técnica que más determina la calidad del gráfico.

Variantes: diferencial, off-CPU e icicle

El flame graph básico mide tiempo en CPU. Sus parientes cubren otras preguntas. El diferencial superpone dos perfiles —antes y después de un cambio— y pinta en rojo lo que creció y en azul lo que menguó, ideal para ver qué empeoró tras un despliegue. El off-CPU invierte la pregunta: en vez de dónde arde la CPU, mide dónde el hilo estaba bloqueado esperando —E/S, un cerrojo, el planificador—, y se construye rastreando las conmutaciones de contexto con el planificador o con una herramienta BPF como offcputime. El icicle es simplemente el mismo gráfico invertido, con la raíz arriba, útil para agrupar por hoja común.

# tiempo fuera de CPU: donde los hilos se bloquean, via BPF
sudo offcputime-bpfcc -df 30 > offcpu.folded
./flamegraph.pl --title "Off-CPU" --colors=io offcpu.folded > offcpu.svg

Juntos, el flame graph on-CPU y el off-CPU cubren el tiempo entero de un hilo: lo que pasa trabajando y lo que pasa esperando. Un servicio lento cuyo flame graph on-CPU está casi vacío te está diciendo que el problema no es cómputo, sino espera, y que debes mirar el off-CPU.