Linux perf, внутренности eBPF, PGO и ограничения sampling''''а

Linux perf: ядерная основа

Подсистема Linux perf — это основа под большинством profiler’ов. Ядро предоставляет perf_event_open(2), позволяющий user space запрашивать сэмплирование по CPU циклам, hardware events, cache miss’ам или software events. Когда срабатывает настроенное количество событий, ядро захватывает текущий PID, указатель на стек user space и записывает их в ring buffer. User space читает буфер и реконструирует стеки.

Стоимость на стороне ядра: ~1-5 микросекунд на сэмпл, включая проход по стеку. Современный Linux (5.x+) поддерживает BPF-программы, прикреплённые к perf events, позволяя user space настраивать, что захватывается — фильтровать по PID, прикреплять метаданные, делать статистическую обработку в ядре. Это движок под Pyroscope eBPF, Parca, profile.bt BCC и любым eBPF-based continuous profiler’ом.

Импликация для безопасности: perf_event_open требует capabilities (CAP_PERFMON в новых ядрах, или root исторически). Production-деплойменты используют cgroup-разрешения на стороне ядра, чтобы ограничить, что каждый контейнер может наблюдать.

eBPF и нюансы обхода JIT-стеков

Ядро легко обходит user-space стеки для скомпилированных бинарников (Go, Rust, C++) — frame pointer’ы или DWARF unwind info в стеке. Для JIT-рантаймов (V8, JVM, .NET CLR) стек содержит адреса JIT-скомпилированного кода, не соответствующие стабильным символам.

Profiler’ы справляются с этим через perf map’ы: JIT’ы выводят файлы /tmp/perf-PID.map, отображающие диапазоны адресов в имена функций, которые profiler загружает. JVM async-profiler обходит это, подключаясь к AsyncGetCallTrace — JVM API, возвращающему Java-фреймы стека напрямую. V8 поддерживает флаги --perf-prof / --perf-basic-prof.

Проблемы:

• Map’ы могут отставать от рекомпиляций — горячие функции перекомпилируются JIT, и старая запись map’а устарела.
• Обход стека может дать сбой через определённые JIT-фреймы, оставляя пробелы.
• Production profiler’ы корректно обрабатывают 90-95% стеков; остальное отображается как [unknown].

Загадочные пробелы [unknown] в flame graph почти всегда указывают на проблему обхода JIT-фреймов, а не на баг в коде приложения.

Off-CPU profiling: хук планировщика

Работа Брендана Грегга 2013 года по off-CPU-анализу выявила пробел, который оставляют CPU-профили. eBPF сделал off-CPU profiling дешёвым, подключившись к switch events планировщика ядра (tracepoint sched_switch). Когда планировщик снимает поток с CPU (он блокируется на I/O, ждёт в sleep, ожидает блокировку), BPF-программа ядра захватывает стек потока и записывает метку времени. Когда поток возвращается на CPU, прошедшее время атрибутируется захваченному стеку.

Production-использование: off-CPU profiling необходим для I/O-bound сервисов (БД, сетевые шлюзы), где CPU-профили показывают ~5% времени, а реальная работа происходит в ожидании. Стоимость: сравнима с CPU-profiling’ом (~2-5%) при сэмплировании; несэмплированный вариант (каждый switch планировщика) может быть дорогим на рабочих нагрузках с частыми переключениями. Production-деплойменты ограничивают до ~99 Hz для off-CPU тоже.

Profile-guided optimisation (PGO)

Profiler’ы не только диагностируют — они возвращают данные в компилятор. PGO (Profile-Guided Optimisation — оптимизация под руководством профиля) позволяет компилятору принимать решения на основе реального production-трафика, а не только статического анализа кода. Рабочий процесс PGO:

1. Компилируешь бинарник с инструментацией (или используешь sampling-профили от CPU profiler’а).
2. Запускаешь бинарник под репрезентативной нагрузкой для сбора профиля.
3. Перекомпилируешь с профилем как входом для компилятора.

Эти три шага замыкают цикл от наблюдения к оптимизации: profiler сообщает компилятору, где реальные горячие пути, и компилятор инлайнит, перегруппировывает и аннотирует соответственно. Без шага 2 под репрезентативной нагрузкой профиль отражает не тот трафик, и перекомпиляция оптимизирует не те пути.

Компилятор теперь знает, какие ветви горячие, а какие холодные; какие функции инлайнить агрессивно; как размещать basic blocks для cache locality CPU. Реальные улучшения от PGO: Go 1.21+ PGO даёт 2-7% ускорения на типичных рабочих нагрузках (CPU pprof-профиль Go напрямую потребляется как PGO-вход). Chrome получил 10%+ от PGO + LTO. Бенчмарки PostgreSQL 5-15%.

Continuous profiling бэкенды всё активнее поддерживают экспорт профилей в PGO-совместимые форматы, позволяя автоматические пайплайны «profile → recompile → validate» в CI.

Смещения и слепые пятна sampling’а

У sampling’а есть ограничения, которые старший инженер обязан знать:

Короткие горячие пути: Когда видишь функцию, которая, как ты знаешь, вызывается миллионы раз, но во flame graph её нет — подозревай это слепое пятно: функции, всё время выполнения которых меньше интервала сэмпла (10 мс при 100 Hz), могут быть пропущены. Функция, вызванная 1 миллион раз по 5 микросекунд каждый раз (5 с суммарного CPU), может никогда не попасть в сэмпл — каждый вызов завершается до срабатывания таймера. Решение: более длинные окна профилирования, более высокие частоты сэмплирования или инструментация для конкретного пути.

NUMA / асимметрия multi-CPU: profiler’ы обычно сэмплируют равномерно по CPU. При неравномерном распределении нагрузки (типично для NUMA-систем или при неправильно настроенной привязке потоков) bottleneck горячего CPU доминирует, и профиль выглядит перекошенным. Используй per-CPU виды профиля, чтобы увидеть дисбаланс.

Статистическая точность при малом числе сэмплов: при 100 Hz за 10 секунд получается 1 000 сэмплов. Функция, использующая 1% CPU, появляется в ~10 сэмплах — достаточно, чтобы заметить, недостаточно для точных оценок. Стандартная ошибка ~30% для функций ниже 10% CPU. Для регрессий ниже 1% требуется более длинный захват (60-300 с) или дифференциальный профиль.

Дифференциальный flame graph — это то, как находят регрессию ниже 1%. Вместо чтения одного абсолютного профиля ты вычитаешь базовый профиль из регрессировавшего и раскрашиваешь каждый фрейм по изменению его self-time: фреймы, которые выросли, краснеют; те, что уменьшились, синеют; неизменные остаются нейтральными. Самый широкий красный фрейм и есть регрессия — даже если он сдвинулся на доли процента общего CPU, diff-раскраска заставляет его выделиться в стеке, который иначе выглядит идентично.