В прошлой статье я рассказал, как можно сделать профилировщик памяти, ориентированный на многопоточные приложения, который в 16 раз быстрее heaptrack.
Сегодня рассмотрим, как получилось совместить быстрый профайлинг с удобством визуализации в Grafana в реальном времени.
Ключевые фишки:
-
Flamegraph аллокаций и деаллокаций за интервал времени
-
График потребления памяти с детализацией до функции/строчки в коде (настраиваемо)
-
Flamegraph в момент пика памяти
-
Flamegraph суммарного числа аллокаций
-
Flamegraph суммарного объема аллокаций
Весь стек поднимается одной командой docker compose up -d — если хотите сразу попробовать, переходите к разделу “Как воспользоваться?”.
Оглавление
Зачем нам это?
Ключевой функционал любого профайлера — возможность создать flamegraph. Большинство профилировщиков памяти позволяют создать flamegraph только в момент пика потребления памяти и направлены на поиск утечек. Однако можно сделать лучше.
Что еще можно визуализировать?
-
Потребление памяти во времени для функции Сколько всего активных объектов было выделено к данному моменту времени в функции? Сколько памяти суммарно они занимают?
-
Изменение памяти за интервал времени За счет чего изменилась память процесса? Где происходили аллокации, а где деаллокации?
-
Flamegraph суммарного выделения памяти В каких местах часто выделяется память? А в каких местах ее было выделено больше всего суммарно?
Ответы на эти вопросы дают возможность оптимизировать приложение не на основе спекуляций, а на основе данных на реальной нагрузке.
Есть ли аналоги?
Да, есть. Наиболее близкий аналог — bytehound. Однако, как и heaptrack, он использует глобальный мьютекс на каждую аллокацию и каждая аллокация также пишется в дамп файл, что серьезно замедляет приложение. Фактически его использование оправдано, только если вам необходима детализация до каждой отдельной аллокации.
MemHawk предлагает более грубую, посекундную детализацию (настраиваемо) до стектрейса аллокации при учете каждой отдельной аллокации, считая агрегаты вместо записи сырых данных. Это позволяет уменьшить общий оверхед от профилирования и кардинально сократить объем записываемых данных. Более подробно механизм описан в первой статье.
Что получаем?
В качестве PoC реализована связка ClickHouse + Grafana + Postgres с преднастроенным дашбордом с графиками и отдельным процессом символизации стектрейсов, написанным на Rust.
Также это демонстрирует возможность встраивания профилирования памяти непосредственно в стек мониторинга приложения.
Настроенные наборы графиков
Рассмотрим на примере жизненного цикла filelight утилиты со сканированием сначала домашней директории, а потом корневой.
Flamegraph — memory peak
Стандартный flamegraph в момент пика потребления памяти.
Total consumption timeseries
Графики потребления памяти и числа активных аллокаций.
Flamegraph изменения потребления памяти за интервал
Динамически вычисляемые flamegraph’ы. По каждому стектрейсу вычисляется изменение потребления памяти за интервал. В зависимости от знака изменения он попадает в один из двух flamegraph’ов. Сумма по всем стектрейсам даёт изменение общего потребления.
-
Addition (in time) — какие стектрейсы добавили память за выбранный интервал
-
Remove (in time) — какие стектрейсы освободили память
Потребление памяти по функциям
Графики потребления памяти с детализацией до функции/до строчки в коде. Уровень детализации настраивается при символизации. Дефолт — до функции.
Flamegraph изменения активных аллокаций за интервал
Аналогично секции с Flamegraph изменения потребления памяти за интервал, только вместо объема аллокаций считаем их уникальное количество.
Активные аллокации по функциям
Аналогично секции Потребление памяти по функциям, только вместо объема аллокаций считаем их уникальное количество.
Flamegraph суммарного потребления памяти/аллокаций
Как воспользоваться?
Профилирование запускается без перекомпиляции вашего приложения. Нужны только Docker и бинарники MemHawk.
1. Собрать проект/скачать последний релиз На github выложен релиз, скомпилированный под ubuntu:20.04 с glibc 2.31. Соответственно, запустится на любой OS с более новой версией glibc.
https://github.com/IlRomanenko/MemHawk/releases/latest
2. Поднять инфраструктуру
docker compose -f memhawk/monitoring/docker-compose.yaml up -d
Поднимает ClickHouse, PostgreSQL и Grafana с предустановленным дашбордом.
3. Запустить приложение под профилировщиком
LD_PRELOAD=./memhawk/lib/libmemhawk.so ./your_application
MemHawk создаст файл memhawk_<name>_<pid>_protobuf.binpb в текущей директории.
4. Запустить символизатор
./memhawk/bin/symbolizer processor -f memhawk_<name>_<pid>_protobuf.binpb --watch
Флаг --watch переводит символизатор в режим непрерывной обработки: он следит за файлом и стримит данные в ClickHouse по мере их появления.
5. Открыть Grafana
http://localhost:3000 (login: admin / password: admin)
Выбрать процесс, нажать «Set actual process time» — данные уже на экране.
6. По завершении
docker compose -f memhawk/monitoring/docker-compose.yaml down -v
Как это работает под капотом?
Чтобы не перегружать статью, здесь будут кратко описаны только основные моменты. Более подробно можно рассказать в отдельной статье, если вам будет интересно.
Пайплайн данных: LD_PRELOAD + application -> .binpb -> symbolizer -> ClickHouse -> Grafana
В .binpb пишем агрегаты по стектрейсам, где были аллокации/деаллокации. Сериализуем в Protobuf сообщение, сжимаем zstd для экономии места. Описание формата файла.
Символизация выделена в отдельный процесс, так как это позволяет упростить библиотеку профилирования, выделить сложный этап парсинга DWARF из профилируемого приложения, поддержать отделенные debug символы за счет параметра sysroot. Также именно на этом этапе вычисляется итоговое дерево вызовов.
В ClickHouse ключевой функционал — зарегистрированный в качестве udf (ссылка на документацию) бинарник, который позволяет интегрировать построение flamegraph’а в выполнение sql запроса. Благодаря этому возможно создание динамических flamegraph’ов по пользовательскому запросу на лету без хранения их непосредственно в базе.
В Grafana используется панель визуализации flamegraph’ов, позволяющая отобразить в качестве flamegraph’а любые данные, которые соответствуют формату.
Итог
MemHawk показывает, что возможно встроить профилирование памяти непосредственно в стек мониторинга. Динамические графики потребления памяти и интервальные flamegraph’ы позволяют анализировать не только пик потребления памяти, но и то, как приложение использует ее на протяжении своего времени работы.
Ссылка на проект: https://github.com/IlRomanenko/MemHawk
ссылка на оригинал статьи https://habr.com/ru/articles/1029320/