Чтение флейм-графов: формы, профайлеры по языкам и 60-секундный скан

Сеньор открывает флейм-граф и говорит: «паттерн вулкана — фикс не в широком листе, а в слое диспетчеризации двумя уровнями выше». Он ещё не прочитал ни одного имени функции. Умение читать формы сокращает путь от профиля до гипотезы с минут до секунд.

Чтение флейм-графа за 60 секунд

Формат флейм-графов Брендана Грэгга — каноническое представление.

• Ось Y: глубина стека вызовов. Точка входа (main, HTTP-хэндлер) внизу; листовая функция на CPU вверху.
• Ось X: алфавитный порядок дочерних стеков. Позиция «левее/правее» ничего не говорит о порядке вызовов.
• Ширина: пропорциональна количеству сэмплов = доле CPU-времени.

Рабочий процесс чтения:

1. Сканируй верх графа на самые широкие листовые фреймы — это функции, находившиеся на CPU в момент сэмплирования.
2. Спускайся вниз от широкого листа, чтобы увидеть, кто его вызвал, и один ли путь ведёт к нему в большинстве сэмплов или он раздроблен по многим вызывателям.
3. Если большинство сэмплов сходятся к листу через один путь: это горячий путь; чини его.
4. Если лист вызывается из многих родителей, каждый вносит тонкий вклад: чини сам лист, а не его вызывателей.

Самая частая ошибка новичка: читать горизонтальное положение как порядок времени. Это не так. Два соседних фрейма ничего не говорят о том, который выполнился раньше.

Пять форм флейм-графов и что они означают

Опытный глаз читает флейм-граф по форме за секунды, до того как увеличивает масштаб на имена.

1. Высокая узкая колонна, уходящая вверх по одному пути — рекурсия или глубокая цепочка middleware. Один фикс на листе или рядом с ним.

2. Широкое плато на одном уровне с десятками тонких листьев — диспетчер, раздающий работу многим хэндлерам. Фикс обычно в самом диспетчере или общем пути над ним, а не в каком-то одном хэндлере.

3. Две соседних широких колонны без общего родителя — два независимых горячих пути, требующих отдельных фиксов. Закон Амдала применяется к каждому независимо.

4. «Вулкан», расширяющийся от листа к корню — большой cum-time в одной точке входа с работой, распределённой ниже. Фикс зависит от того, на каком уровне реальная работа превращается в диспетчеризацию; иди по форме.

5. Тонкие шипы, рассыпанные по всей ширине — нет реального hotspot. Проблема задержки в другом месте (off-CPU, координация, сеть). CPU-профиль один не покажет её; попробуй off-CPU или allocation-профиль.

Это словарный запас, которым сеньоры описывают вид профиля до называния функций.

Выбор профайлера по языку

У каждого современного языка есть рекомендованный сэмплирующий профайлер. Правильный выбор избавляет от артефактов debug-сборки и ошибок обхода стека JVM.

• Go: встроенный pprof через runtime/pprof и net/http/pprof — отраслевой стандарт. Читается go tool pprof, экспортирует pprof.proto.
• Java: JFR (Java Flight Recorder, по умолчанию с JDK 11) и async-profiler — production-стандарт, так как правильно обходит Java-стеки через AsyncGetCallTrace, избегая safepoint bias.
• Python: py-spy (внешний сэмплер, не требует изменений в приложении) и scalene. cProfile — инструментирующий, только для разработки, не для продакшена.
• Node.js: встроенный --prof + clinic.js для флейм-графов; 0x для продакшена.
• Rust: pprof-rs; perf с addr2line для разрешения символов.
• Ruby: stackprof и rbspy.
• PHP: tideways, Excimer.
• C/C++: perf + perf-tools; Intel VTune для микроархитектурного анализа.

Бэкенды непрерывного профилирования (Pyroscope, Parca, Polar Signals, Datadog Continuous Profiler) принимают pprof или JFR от любого из них. eBPF-агенты захватывают стеки на стороне ядра и работают без учёта языка через DWARF-анврапинг для скомпилированных бинарей или JIT-эмитированных perf-мап для V8 и JVM.

Выбор сеньора: один основной профайлер на язык, один универсальный eBPF-baseline на всю инфраструктуру. Полиглот-команда должна нормализовать все профили в один бэкенд и читать их в одном инструменте.