Sampling vs instrumentation profiling: почему 99 Гц побеждает в production

На staging-сервере profiling работает без проблем. Тот же profiler в production поднимает latency на 40%. Profiler не менялся — поменялась нагрузка. Понять почему — разница между инструментом, который можно держать включённым always, и тем, который используешь только в экстренных случаях.

Два способа профилировать

Instrumentation profiling оборачивает каждый вход и выход функции таймирующим кодом. Runtime измеряет точное число вызовов и точную длительность каждой функции. Стоимость пропорциональна частоте вызовов — при 10 миллионах вызовов в секунду платишь за 10 миллионов замеров в секунду. На dev-машине с лёгкой нагрузкой это нормально; под production-трафиком может добавить 20-100% overhead. Instrumentation хороша для маленьких изолированных benchmark’ов; для always-on production profiling не годится.

Sampling profiling работает иначе: внешний таймер срабатывает N раз в секунду и захватывает текущий call stack. Стоимость ровно N stack walk’ов в секунду — независимо от того, сколько вызовов функций происходит между ними. При 100 Гц — это 100 stack walk’ов в секунду, каждый стоит ~5-20 микросекунд, итого overhead ~0.5-2% на занятом CPU. Современные profiler’ы (Go pprof, Linux perf, Java async-profiler, py-spy, eBPF-профилеры) — все sampling-based. Стоимость ограничена.

Ключевое статистическое свойство

При sample rate R Гц функция, потребляющая X% CPU, будет появляться в X% сэмплов — независимо от числа вызовов. Статистика — «доля CPU-времени», не «счётчик вызовов». Это именно та метрика, нужная для поиска узких мест: хочешь знать, какая функция чаще всего на CPU, а не какую чаще всего вызывают.

Следствие: sampling при 100 Гц достаточен для обнаружения функций, потребляющих больше нескольких процентов CPU. Функция, использующая 10% CPU, будет попадать в ~10 сэмплов в секунду. За 30-секундный профиль — 300 сэмплов — вполне достаточно для надёжной оценки.

Выбор sample rate на практике

Linux perf по умолчанию 99 Гц — не 100 Гц. Это намеренно: 100 Гц может случайно синхронизироваться с периодическими kernel-таймерами и давать вводящие в заблуждение результаты. 99 Гц избегает резонанса. Go pprof по умолчанию 100 Гц. eBPF-based continuous profiler’ы обычно используют 19 или 49 Гц для минимизации влияния на очень занятые контейнеры.

Когда заявленный 2-5% overhead становится 12%

Continuous profiler заявляет 2% overhead; ты измеряешь 12% в production. Частые причины:

• Sample rate случайно выставлен в 10 раз выше дефолта.
• Stack walking дорог, потому что язык использует JIT и требует symbol resolution при каждом сэмпле (Python, JVM без native hooks).
• Agent делает тяжёлую компрессию или декомпрессию символов в application thread вместо async.
• Средняя глубина стека 120+ frames (глубокие middleware-цепочки) — каждый сэмпл пропорционально дороже.

Прежде чем обвинять инструмент — проверь конфигурацию.