Flame graph: читаем картинку, которая показывает, куда ушло время

Trace говорит «1.2 секунды в inventory». Есть логи, метрики, дашборды — но ни один из них не скажет, какая именно функция внутри inventory съела время. Profiling отвечает за 60 секунд, без отладчика и без угадывания.

Что делает profiler

Profiler прерывает программу 100 раз в секунду и захватывает текущий call stack — цепочку функций от main до того, что выполняется прямо сейчас. За 30 секунд набирается 3000 снимков. Функция, чаще всего встречающаяся в снимках, — та, что больше всего ест CPU.

Flame graph визуализирует это: стеки отсортированы alphabetically по x-оси, ширина пропорциональна числу сэмплов, y-ось — глубина от точки входа внизу до leaf-функции наверху. Самый широкий frame на любом уровне — самый горячий путь.

Метафора со стадионом

Представь стадион со 100 000 людьми, занятых разным. Вертолёт пролетает сверху 100 раз в секунду и фотографирует, кто что делает. За минуту — 6000 фото. Посчитай, какая активность встречается чаще всего — туда уходит «CPU-время» толпы.

Flame graph — столбчатая диаграмма этих счётчиков, с вызывающими под вызываемыми. Широкие бары = популярные активности. Вертолёт — profiler; фото — стек-сэмплы; диаграмма — flame graph.

Чтение flame graph на практике

Bea on-call. Inventory-сервис, p99 = 1.5 с. Она открывает continuous-profile dashboard, фильтрует по trace-id, видит flame graph с одним массивным 1.1-секундным блоком: json.Marshal внутри serializeResponse. Фикс очевиден: кешировать маршаленный ответ или пре-кодировать при записи. Без profiling команда гадала бы — БД? Кеш? Сеть? С flame graph гадать не нужно.

Как захватить CPU-профиль с помощью pprof

Node API — внезапный скачок p99. Tracing находит медленный span. Continuous-profile dashboard, отфильтрованный по trace-id, показывает flame graph с доминирующим regex compile в handler’е. Library upgrade ввёл O(n²) regex; фикс — precompile вне handler’а. Детекция — 60 секунд.

Для Go-сервисов pprof встроен:

// 1. Подключи pprof-handler'ы (регистрирует маршруты /debug/pprof/*)
import _ "net/http/pprof"

// Запусти debug-сервер
go func() {
  http.ListenAndServe("localhost:6060", nil)
}()

// 2. Захвати 30-секундный CPU-профиль под нагрузкой:
//    go tool pprof -http=:9090 \
//      http://localhost:6060/debug/pprof/profile?seconds=30
//
// 3. Flame graph view откроется на :9090.
//    Самый широкий leaf-frame наверху = горячий путь.

Профилировать нужно под репрезентативной нагрузкой — на простаивающей системе в сэмплах будет почти только idle loop рантайма, бесполезный для поиска горячих путей.