Профилировщики для Python, Java, Go и других языков

Профилировщик нужен не для того, чтобы увидеть «медленный код», а чтобы найти конкретную цену операции: процессорное время, ожидание блокировки, память или сетевую задержку. Для Python чаще достаточно cProfile, в Java удобнее начать с JFR, в Go — с pprof, а в Node.js и .NET есть собственные средства записи профиля. Ошибка обычно не в выборе «самого мощного» инструмента, а в том, что CPU-профиль пытаются использовать для поиска проблемы с базой данных.

Сначала определите, что именно тормозит

Профилировщики делятся не столько по языкам, сколько по типу наблюдения. Перед запуском выберите один вопрос: процессор занят вычислениями, программа ждёт ввод-вывод, растёт память или потоки блокируют друг друга.

• CPU-профиль показывает, какие функции чаще всего находятся на стеке вызовов. Он полезен для вычислительных узких мест.
• Профиль памяти помогает найти большое число аллокаций и объекты, которые живут дольше ожидаемого.
• Трассировка записывает события с временной шкалой: сборку мусора, системные вызовы, блокировки и обращения к файлам.
• Профилирование запросов связывает серверную обработку с HTTP-методом, SQL-запросом или задачей очереди.

CPU-профиль не объяснит медленный SQL сам по себе: в нём вы увидите время ожидания в драйвере или потоке, но не обязательно текст запроса. Для базы данных нужны её собственные журналы и планы выполнения.

Хороший профиль отвечает на один проверяемый вопрос. Если включить все сборщики сразу, вы получите большой файл и не получите диагноза.

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

Сравнение профилировщиков по языкам

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

Python: cProfile для функции, py-spy для процесса

В Python 3.12 и 3.13 встроенный cProfile — разумная первая проверка, если вы можете воспроизвести проблему в тесте или отдельной команде. Он показывает, какие Python-функции вызваны чаще всего и сколько времени накоплено внутри вызова вместе с вложенными функциями. Это хороший вариант для отчёта, который должен повторяться от запуска к запуску.

Если проблема возникает только в уже работающем процессе, нужен внешний сэмплирующий инструмент, например py-spy. Он позволяет наблюдать процесс без изменения исходного кода, но права ОС, контейнер и способ запуска могут помешать подключению. Версию py-spy стоит сверить с документацией перед установкой, особенно в образах с ограниченными capabilities.

Не путайте время функции с временем ответа пользователя. Для веб-приложения отдельно измеряйте SQL, внешние HTTP-вызовы, очереди и сериализацию ответа.

Java: JFR как базовый инструмент для сервиса

В Java 21 и 22 Java Flight Recorder уже встроен в JDK и собирает события JVM: паузы сборщика мусора, блокировки, загрузку классов, состояние потоков и примеры стека. Это делает JFR практичнее для работающего сервиса, чем профилировщик, который требует изменения приложения или специальной сборки.

JFR особенно полезен, когда симптом выглядит неоднозначно: запросы стали медленнее, но загрузка CPU не выросла. В записи может оказаться ожидание монитора, частая сборка мусора или конкуренция за пул потоков. JDK Mission Control используют для разбора файла, но сам файл не заменяет метрики: сначала зафиксируйте окно времени, количество запросов и изменение задержки.

Для очень точного анализа CPU можно добавить async-profiler. Его нужно подбирать под конкретную версию JDK, ОС и способ запуска контейнера: доступ к системным событиям может быть ограничен.

Go: pprof и разные типы нагрузки

В Go 1.22–1.23 один CPU-профиль не покрывает все проблемы. Профиль heap показывает распределение памяти, goroutine — состояния горутин, mutex — конкуренцию за мьютексы, а block — ожидание блокирующих операций. Если сервис отвечает медленно при невысоком CPU, начинать стоит не с оптимизации циклов, а с goroutine, block и трассировки.

pprof обычно подключают к диагностическому HTTP endpoint. Этот endpoint должен быть доступен только через защищённую сеть или локальный туннель. Публиковать диагностические профили в интернет нельзя: они раскрывают структуру приложения, имена функций и рабочие характеристики сервиса.

Для сравнения релизов сохраняйте одинаковые условия: тот же объём входных данных, число параллельных запросов, лимиты контейнера и длительность замера. Иначе различия в профиле нельзя уверенно связать с изменением кода.

Node.js и .NET: ищите не только CPU

Node.js 22.x

В Node.js профилировщик CPU помогает найти синхронный участок, который блокирует event loop. Это критический сценарий: один тяжёлый парсинг, регулярное выражение или сериализация может задержать сразу множество запросов. В профиле смотрите не только на функцию, но и на размер входа и частоту её вызова.

Память V8 исследуйте отдельно через средства Inspector. Рост heap не доказывает утечку: причиной может быть нормальная работа сборщика мусора, кэш или слишком большой размер очереди. Сравнивайте несколько снимков, сделанных после одинакового сценария и завершения прогрева.

.NET 8

В .NET 8 связка dotnet-trace и dotnet-counters помогает отделить высокую загрузку CPU от давления на GC, блокировок и очередей ThreadPool. Счётчики дают быстрый сигнал, а трасса — последовательность событий. Нельзя делать вывод о причине только по одному счётчику: например, частая сборка мусора может быть следствием лишних аллокаций, а может — следствием резко выросшего трафика.

Когда какой подход выбирать

• Есть воспроизводимый тест на Python — начните с cProfile, сохраните результат и сравните его с базовой версией.
• Java-сервис уже работает под нагрузкой — запишите JFR в ограниченном временном окне, затем сопоставьте события с задержкой и нагрузкой.
• Go отвечает медленно при нормальном CPU — сравните goroutine, block и mutex-профили, а не только CPU.
• Node.js теряет latency на пиках — проверьте синхронный JavaScript и event loop, затем отдельно исследуйте heap.
• .NET расходует память или часто запускает GC — начните со счётчиков, после чего запишите трассу для подтверждения причины.
• PHP-проблема воспроизводится на тестовом стенде — используйте Xdebug, но не оставляйте тяжёлую трассировку включённой для всех боевых запросов.

Критерий выбора простой: берите самый дешёвый инструмент, который способен ответить на текущий вопрос. Если вы ищете блокировку, CPU-профиль — неправильный первый шаг. Если ищете утечку памяти, снимок стека вызовов без истории объектов тоже не даст достаточного доказательства.

Что ломается при профилировании

Профиль меняет проблему

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

Сэмплы принимают за точные значения

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

Профилируют не тот процесс

Воркеры, контейнеры и фоновые очереди могут жить отдельно от HTTP-процесса. Перед запуском проверьте PID, экземпляр приложения, время старта и версию сборки. Для Java, Node.js и .NET особенно важно не потерять дочерний процесс или отдельный worker.

Диагностический endpoint оставляют открытым

Профили содержат внутренние имена модулей, маршрутов и операций. Ограничьте доступ сетевыми правилами, а файл профиля храните как технический артефакт с теми же требованиями, что и логи.

Что делать дальше

Выберите один медленный сценарий и запишите базовые значения: p50 и p95 задержки, количество запросов, CPU, память, ошибки и объём входных данных. Затем снимите профиль только на этом окне, сформулируйте одну гипотезу и повторите тот же замер после изменения. Если цифры не изменились, не объявляйте оптимизацию успешной — проверьте, тот ли процесс и тот ли тип ожидания вы измеряли.

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

¹ Сэмпл — отдельное наблюдение состояния программы в момент измерения. По множеству таких наблюдений строится статистическая картина загрузки.