Профилирование приложения на проде без остановки

MAATRIX

Приложение тормозит на проде, метрики показывают рост p95, но непонятно, какая именно функция съедает время процессора — оптимизация вслепую по логам не работает, а включить профайлер страшно: вдруг сам замер положит и без того нагруженный сервис. Ниже — как профилировать живой продакшн с реальными пользователями так, чтобы наблюдение не искажало то, что вы наблюдаете.

Профилирование — это не трассировка

Термины постоянно путают, а решают они разные задачи. Трассировка в Jaeger отвечает на вопрос «между какими компонентами системы теряется время»: запрос прошёл через nginx, приложение, базу, внешний API — и трейс показывает, сколько миллисекунд ушло на каждый прыжок. Это взгляд снаружи процесса, на уровне сетевых вызовов между сервисами.

Профилирование — это взгляд *внутри* одного процесса. Когда трейс говорит «приложение обрабатывало запрос 800 мс», профайлер отвечает на следующий вопрос: а что конкретно происходило эти 800 мс внутри кода приложения? Какая функция, какой цикл, какая сериализация JSON, какой вызов ORM забрал большую часть времени. Трассировка показывает, *где между сервисами* теряется секунда; профилирование — *где внутри одного сервиса* теряется эта секунда, вплоть до конкретной строки кода.

На практике это два последовательных шага одного расследования. Сначала трассировка сужает проблему до одного компонента: «80% времени запроса уходит именно в сервисе оплаты, не в базе и не во внешнем API». Потом профилирование того же сервиса отвечает, что именно внутри него исполняется эти 80% времени — конкретная функция валидации, регулярное выражение, аллокация памяти. Без трассировки вы не знаете, какой сервис профилировать. Без профилирования вы знаете, какой сервис виноват, но не знаете, что чинить внутри него.

Фундаментальная проблема: наблюдение искажает наблюдаемое

Классическое, «исчерпывающее» профилирование (instrumenting/tracing profiler) перехватывает *каждый* вызов функции: вход, выход, время, стек вызовов. Это даёт исключительно точную картину — но сама точность стоит дорого. Перехват каждого вызова означает дополнительный код на каждой функции программы, и для приложений с высокой частотой вызовов (циклы, сериализация, ORM с сотнями маленьких запросов) оверхед может быть заметным — замедление в разы, а не в проценты, для по-настоящему «горячих» участков кода.

Это ставит вас перед классической дилеммой наблюдаемости: чтобы понять, где именно тормозит прод, нужно включить детальный профайлер — но включение детального профайлера само по себе меняет тайминги, которые вы пытаетесь измерить. Функция, которая в норме отрабатывает за микросекунды, под инструментированным профайлером может отработать на порядок дольше просто из-за накладных расходов на сбор данных. В результате вы либо видите не ту картину, которая была у реальных пользователей до включения профайлера, либо — что хуже — сам профайлер становится причиной деградации, которую замечают клиенты и алертинг.

Вывод простой и практичный: на проде, обслуживающем реальный трафик, вам почти никогда не нужен исчерпывающий профайлер, работающий постоянно. Нужен подход, который даёт статистически достоверную картину при накладных расходах, неотличимых от фонового шума. Дальше — три таких подхода, которые комбинируются между собой.

Подход 1: сэмплирующее профилирование вместо исчерпывающего

Вместо фиксации абсолютно каждого вызова функции, сэмплирующий (statistical/sampling) профайлер периодически — например, много раз в секунду — останавливает поток (или читает его состояние без остановки, в зависимости от механизма) и записывает текущий стек вызовов: какая функция исполняется прямо сейчас и кем она была вызвана. Никакого перехвата входа/выхода из функций, никакого дополнительного кода на каждый вызов — просто периодический снимок «что происходит в эту миллисекунду».

После сбора тысяч таких снимков за разумный промежуток времени (скажем, минуту-две) строится статистика: функция, которая присутствует в 40% снимков стека, статистически с высокой вероятностью и потребляет около 40% процессорного времени. Это не абсолютно точное измерение каждого вызова — редкие, но очень быстрые функции могут вообще не попасть ни в один снимок — но для задачи «где именно тратится основная масса времени» точности сэмплирования с большим запасом достаточно, а оверхед на снятие снимка стека на несколько порядков ниже, чем оверхед на инструментирование каждого вызова.

Практическая иллюстрация: файл perf (Linux) в режиме сэмплирования читает регистр инструкций и стек с частотой в несколько сотен–тысяч герц:

# профилировать процесс с pid 12345 в течение 30 секунд, 99 сэмплов/сек
sudo perf record -F 99 -p 12345 -g -- sleep 30
perf report

Частота 99 Гц (а не круглая 100) — не случайность, а распространённая практика: нечётная частота снижает риск систематического совпадения фазы сэмплирования с периодическими паттернами в самом приложении (например, с частотой обработки батчей или тиков event loop), что могло бы дать смещённую, а не репрезентативную картину.

Подход 2: короткое включение вместо постоянной работы

Второй рычаг снижения оверхеда — временной, а не алгоритмический: детальный профайлер держат выключенным по умолчанию и включают на контролируемый короткий период именно тогда, когда есть конкретный повод — расследование инцидента, подозрение на регресс после деплоя, подготовка к пиковой нагрузке. Постоянно включённое профилирование 24/7 означает, что 100% времени работы сервиса вы платите оверхед ради данных, которые нужны вам в лучшем случае несколько раз в неделю.

Практика для большинства современных runtime — управляемое включение через сигнал, HTTP-эндпоинт или переменную окружения, без перезапуска процесса:

# Go: встроенный pprof поднимается на отдельном порту приложения,
# снятие профиля — по требованию, отдельным запросом
curl -s http://localhost:6060/debug/pprof/profile?seconds=30 -o cpu.prof
go tool pprof -top cpu.prof

# Python: py-spy подключается к уже работающему процессу снаружи,
# ничего не меняя в коде и не требуя перезапуска
py-spy record -o profile.svg --pid 12345 --duration 30

Оба примера объединяет один принцип: профилирование запрашивается на конкретные N секунд, а не включается флагом в конфиге навсегда. Это же диктует операционную дисциплину — заведите себе привычку: перед тем как снимать профиль на проде, запишите точное время начала и длительность (те же 30–60 секунд обычно достаточно для статистически значимой картины), чтобы потом можно было сопоставить окно профилирования с логами и метриками за тот же интервал.

Подход 3: профилирование одного инстанса из нескольких

Если сервис работает в нескольких экземплярах за балансировщиком нагрузки — а на проде это обычно так уже ради отказоустойчивости, — у вас есть третий, независимый способ снизить риск: включить детальное профилирование только на одном инстансе, оставив остальные необременёнными. Даже если детальный профайлер на этом одном экземпляре создаст ощутимый оверхед, для пользователей, чьи запросы балансировщик направит на другие N-1 инстансов, ничего не изменится.

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

Практические нюансы этого подхода:

• Через вес в конфигурации балансировщика оставьте на профилируемом инстансе заметную, но не основную долю трафика — иначе на нём не окажется репрезентативного потока запросов.
• Убедитесь, что версия кода на профилируемом инстансе идентична остальным — профилировать не ту сборку, что реально стоит на проде, бессмысленно.
• Если инстансы стейтфул (сессии, локальный кеш) — учтите, что деградация одного из них ощутимо скажется на «привязанных» к нему пользователях; для стейтлес-сервисов с round-robin риск минимален.
• После снятия профиля верните инстанс в штатный режим — не оставляйте детальный профайлер включённым «на всякий случай».

Инструменты по стекам: не изобретайте велосипед

У большинства современных языков и рантаймов уже есть встроенный или широко принятый сторонний инструмент, спроектированный именно под низкооверхедное профилирование живого продакшна — не общий отладчик, приспособленный для этой задачи, а инструмент с этим сценарием в основе архитектуры. Стоит проверить актуальные возможности конкретно для вашего стека, прежде чем тянуть что-то более тяжеловесное.

Общая черта всех перечисленных инструментов — они спроектированы подключаться к уже работающему процессу *снаружи*, без пересборки и без перезапуска приложения, и работают в сэмплирующем режиме по умолчанию. Если вы ловите себя на мысли «давайте добавим print времени в начало и конец каждой функции» или тянете инструментирующий профайлер, предназначенный для локальной отладки, а не для прода, — это тревожный сигнал: почти для любого популярного стека уже есть готовый инструмент под именно эту задачу, и написание собственного велосипеда почти никогда не оправдано.

Собираем всё в рабочий процесс

На практике три подхода выше не конкурируют, а складываются в один процесс расследования проблем с производительностью:

1. Трассировка (Jaeger или аналог) сужает проблему до конкретного сервиса и, желательно, конкретного эндпоинта.
2. На этом сервисе включается сэмплирующий профайлер вашего стека на короткое контролируемое окно (20–60 секунд) — по HTTP-эндпоинту, сигналу или внешнему подключению, без перезапуска.
3. Если сервис работает несколькими инстансами за балансировщиком — профилируется один инстанс, получающий часть трафика, а не все сразу.
4. Результат сэмплирования (флейм-график или таблица top-функций) указывает на конкретную функцию или паттерн вызовов — оптимизация делается точечно, а не «повышаем ресурсы сервера и надеемся».

Если после оптимизации подозрение падает не на CPU, а на память — тот же принцип «короткое окно + сэмплирование» применим и к поиску утечки памяти: снимок кучи (heap dump/heap profile) снимается на короткий интервал, а не держится включённым постоянно, по той же причине — детальный учёт каждой аллокации памяти стоит заметного оверхеда. А если проблема уже проявляется как рост нагрузки на процессор без ясной причины, до профилирования стоит пройти базовую диагностику — найти процесс-виновника обычным htop, прежде чем разбираться внутри его кода.

Отдельно стоит сказать честно про ограничения. Сэмплирующее профилирование хорошо показывает, где тратится *много* времени, но плохо ловит редкие, короткие, но дорогие вызовы — если функция исполняется раз в час и занимает 50 мс, она почти наверняка не попадёт ни в один снимок при частоте сэмплирования в сотни герц за минутное окно. Для таких случаев подходит профилирование одного инстанса с более детальным режимом на более длинном окне, и здесь важно трезво оценивать риск против пользы именно для вашего трафика.

Частые вопросы