Pinterest уходит от зоопарка профайлеров к открытому gProfiler от Intel

Когда у вас пять сервисов на одном языке, профилирование решается одной командой. Когда у вас сотни тысяч инстансов и пять языков, профилирование превращается в отдельную инженерную задачу. Именно с ней столкнулся Pinterest, и решение получилось любопытным: вместо закрытой внутренней системы компания взяла открытый gProfiler от Intel и начала его дорабатывать.

Проблема: много языков, много инструментов

Цифры масштаба такие: 640 млн активных пользователей в месяц, сотни тысяч вычислительных инстансов. Сервисы написаны на Java, Python, C++, Go и Node.js. Для каждого языка у инженеров был свой привычный инструмент: perf для нативного кода, async-profiler для JVM, py-spy для Python.

По отдельности каждый из них хорош. Вместе они дают кашу. Форматы данных разные, способы запуска разные, а склеить картину по цепочке «Node.js-шлюз, Java-бэкенд, C++-библиотека» приходится вручную. Сравнить профиль одного сервиса на разных машинах или в разные дни тоже непросто, если снимки сделаны разными инструментами.

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

Что сделали с gProfiler

gProfiler — открытый профайлер непрерывного действия. Он запускается агентом на машине и собирает профили сразу по разным языкам, а результат показывает в виде flame-графов. Pinterest вместе с Intel расширила его возможности и отдала правки обратно в open-source проект. Среди доработок:

• Динамическое профилирование. Профилирование можно включать и настраивать по ходу работы, а не держать постоянно на всех машинах.
• Сбор телеметрии на аппаратном уровне. Профайлер видит не только то, где код проводит время, но и данные со счётчиков процессора.
• Wall-time профилирование. Показывает, где поток физически ждёт, а не только где он грузит процессор.
• Flame-графы на основе счётчиков производительности. Вместо привычной оси «время CPU» можно строить графы по аппаратным событиям.

Разницу между CPU-time и wall-time проще всего понять на примере. Допустим, эндпоинт отвечает за 300 мс, но CPU-профиль показывает, что процессор работает всего 40 мс. Куда делись остальные 260? Скорее всего, поток ждёт ответа от базы, сети или блокировки. CPU-профиль эту часть не покажет вообще, а wall-time покажет сразу.

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

Что здесь важно и чего мы не знаем

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

Тем не менее сам выбор показателен. Компания такого размера могла бы собрать собственную платформу, но предпочла открытый проект и вернула в него свои доработки. Для остальных это плюс: улучшения динамического и wall-time профилирования окажутся доступны всем, кто использует gProfiler.

Что делать на практике

1. Посчитайте свой зоопарк. Если у вас больше двух языков в проде и больше двух разных профайлеров, у вас та же проблема, просто поменьше.
2. Попробуйте gProfiler на тестовом окружении. Это открытый проект, и он нужен как раз для непрерывного профилирования без правок в коде сервисов.
3. Добавьте wall-time в привычку. Если сервис «тормозит, но CPU свободен», вам нужен именно он.
4. Следите за апстримом. Доработки Pinterest и Intel должны попасть в основной репозиторий, и стоит проверить, что из них уже доступно в релизах.

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