Типы профилей: CPU, память, off-CPU, mutex — какой когда брать

Span занимает 500 мс. Открываешь CPU-профиль — сервис использовал 20 мс CPU. Куда ушли остальные 480 мс? CPU profiling слеп к ожиданию. Если остановиться здесь — ответ не найти никогда.

CPU профили: что видят и что упускают

CPU profiling сэмплирует call stack, пока поток на CPU — выполняет инструкции. Запрос, проведший 20 мс в вычислениях и 480 мс ожидая DB-запроса, покажет 20 мс в CPU-профиле, а 480 мс останутся невидимыми.

Это важнейшее ограничение profiling: CPU-профили видят только функции, потребляющие процессор. Всё, чего ждёт программа — I/O, сеть, локи, планировщик — находится off-CPU и невидимо для CPU-profiler’а.

Memory и allocation профили

Heap profiler’ы сэмплируют аллокации, а не CPU. Heap profile в Go сэмплирует одну аллокацию на ~512 КиБ (Poisson) и записывает стек при каждом сэмпле. Результат — flame graph, где ширина это выделенные байты, а не CPU-время. Это находит memory-горячки: функция, выделяющая 100 МБ/с, выглядит широкой.

Обнаружение memory leak с heap profile:

1. Взять heap профиль.
2. Подождать 30-60 минут.
3. Взять ещё один heap профиль.
4. Сравнить (go tool pprof -base baseline.heap current.heap).
5. Функции, чья аллокация выросла, — источник утечки.

Allocation профили захватывают короткоживущие аллокации, которые GC возвращает; heap профили — снимки живой памяти. JVM-эквиваленты: async-profiler с -e alloc, JFR allocation events. Python: tracemalloc, memray.

Off-CPU профили

Работа Brendan Gregg по off-CPU analysis (2013) определила пробел: CPU-профили пропускают всё, чего ждёт процесс. eBPF-реализации цепляются за события переключения контекста kernel-планировщика. Когда планировщик снимает поток с CPU (блокировка на I/O, sleep, ожидание лока), kernel захватывает стек потока. Этот стек — место, где началось ожидание. Когда поток возвращается, прошедшее время атрибутируется этому стеку.

Off-CPU flame graph показывает время ожидания точно так же, как CPU flame graph показывает время выполнения. Для I/O-bound сервиса off-CPU профиль — единственный, который хоть что-то объясняет: CPU-профиль просто говорит «сервис простаивал».

Block и mutex профили

Block profile (Go: runtime.SetBlockProfileRate): время ожидания на sync-примитивах — каналах, condition variable’ах, WaitGroup’ах. Более фокусированный, чем off-CPU, так как нацелен на language-level синхронизацию.

Mutex profile (runtime.SetMutexProfileFraction): конкуренция за локи конкретно. Сообщает, какой код держал лок, пока другие его ждали, — атрибутировано в момент unlock’а.

Выбор профиля по соотношению CPU/wall-time

Диагностический shortcut: смотри CPU-время vs wall-clock-время медленного запроса.

• CPU/wall ≈ 100%: вычислительное узкое место — CPU профиль.
• CPU/wall < 30%: узкое место off-CPU — off-CPU/block профиль или trace span’ы.
• Память растёт стабильно: heap/allocation профиль.
• Потоки конкурируют за лок: mutex профиль.

Java-сервис с GC-thrashing — классический allocation-профиль случай. Симптом: высокая скорость аллокации при частых old-gen GC. Allocation flame graph покажет самый широкий frame как функцию, аллоцирующую с наибольшей скоростью — часто string concatenation в logging-коде без параметризованного форматирования.