JEMALLOC: различия между версиями

Материал из Home Wiki
Перейти к навигации Перейти к поиску
(Новая страница: «https://access.redhat.com/solutions/61334 = Обнаружение утечек памяти с помощью JEMALLOC = ''Обновлено 18 марта 2022 в 13:31'' == Содержание == * Введение * Как это работает * Как настроить * Как профилировать * Сбор данных * Локальные отчёты == Введение == Обнаружение утечек памяти может б...»)
 
Строка 3: Строка 3:
= Обнаружение утечек памяти с помощью JEMALLOC =
= Обнаружение утечек памяти с помощью JEMALLOC =
''Обновлено 18 марта 2022 в 13:31''
''Обновлено 18 марта 2022 в 13:31''
== Содержание ==
* Введение
* Как это работает
* Как настроить
* Как профилировать
* Сбор данных
* Локальные отчёты


== Введение ==
== Введение ==

Версия 10:09, 16 сентября 2024

https://access.redhat.com/solutions/61334

Обнаружение утечек памяти с помощью JEMALLOC

Обновлено 18 марта 2022 в 13:31

Введение

Обнаружение утечек памяти может быть сложной задачей, если нет воспроизводимого тестового случая, и выявление их в производственной среде может вызвать проблемы с производительностью из-за большого накладного расхода при использовании традиционных инструментов для обнаружения утечек памяти, таких как Valgrind. Аллокатор JEMALLOC использует другой подход к профилированию памяти и обнаружению утечек, который можно применять в производственной среде без значительного ухудшения производительности. В этой статье объясняется, как использовать библиотеку пользовательского аллокатора памяти JEMALLOC для обнаружения утечек в контексте Red Hat Directory Server 11 и его процесса ns-slapd. Описанная техника может применяться к любому процессу, который либо скомпилирован с JEMALLOC, либо использует его как загружаемую библиотеку.

Как это работает

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

Как настроить

Red Hat Directory Server 11 поставляется с предустановленным и включённым JEMALLOC. Однако по умолчанию вся функциональность профилирования отключена. Чтобы включить профилирование памяти и обнаружение утечек, отредактируйте пользовательский конфигурационный файл systemd сервера Directory Server:

 /etc/systemd/system/dirsrv@.service.d/custom.conf

или, если установлено несколько экземпляров, используйте конфигурацию для конкретного экземпляра:

 /etc/systemd/system/dirsrv@<instance>.service.d/custom.conf

Добавьте следующие параметры MALLOC_CONF для JEMALLOC:

 
[Service]

TimeoutStartSec=0
TimeoutStopSec=600

Environment=MALLOC_CONF=prof:true,prof_leak:true,lg_prof_sample:19,prof_final:true,stats_print:true,prof_prefix=/run/dirsrv/jeprof
Environment=LD_PRELOAD=/usr/lib64/dirsrv/lib/libjemalloc.so.2

Эти параметры указывают JEMALLOC:

  • Включить профилирование и обнаружение утечек.
  • Использовать выборку профилирования каждые 2^19 байт.
  • Генерировать профилирование при завершении процесса.
  • Выводить внутреннюю статистику аллокатора.
  • Сохранять данные профилирования в директории /run/dirsrv.

Для применения изменений выполните:

 
# systemctl daemon-reload
# systemctl restart dirsrv@<instance>

Чтобы отключить профилирование, просто отмените изменения конфигурации, удалив или закомментировав строки с параметрами MALLOC_CONF, и выполните команды повторно.

Как профилировать

После перезапуска Directory Server профилирование и сбор данных будут активны, и всё, что нужно для получения данных — это воспроизвести сценарий утечки памяти.

Некоторые утечки могут остаться незамеченными при текущем интервале выборки. Для устранения этого можно заставить JEMALLOC проводить выборку чаще, но это повлияет на производительность. Поэтому интервал выборки — это всегда компромисс между точностью и производительностью.

Параметр lg_prof_sample:19 задаёт интервал выборки в 512 Кб, что подходит для большинства случаев, так как это хороший баланс между точностью и производительностью. Уменьшение этого значения приведёт к более частому профилированию, увеличение — к реже проводимым выборкам.

Сбор данных

Когда утечка памяти воспроизведена, процесс сервера нужно завершить, чтобы JEMALLOC завершил сбор данных и записал отчёт в указанное место:

 /run/dirsrv/jeprof.2613573.0.f.heap

Внутренняя статистика аллокатора и краткий отчёт об утечках будут записаны в syslog:

 /var/log/messages: 
___ Begin jemalloc statistics ___
[ ... ]
--- End jemalloc statistics ---

ns-slapd[2613573]: <jemalloc>: Leak approximation summary: ~2966192 bytes, ~22 objects, >= 5 contexts
ns-slapd[2613573]: <jemalloc>: Run jeprof on "/run/dirsrv/jeprof.2613573.0.f.heap" for leak detail

Данные профилирования и сообщения syslog можно отправить в Red Hat Support для дальнейшего анализа либо преобразовать в отчёт и проанализировать локально.

Локальные отчёты

Для создания отчёта на основе данных профилирования требуется инструмент jeprof. Он обычно входит в состав Directory Server 11 и находится по следующему пути:

 /usr/lib64/dirsrv/bin/jeprof

Его также можно получить с GitHub-страницы JEMALLOC при необходимости.

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

 debuginfo-install 389-ds-base

С установленными пакетами jeprof можно использовать для генерации отчётов:

 jeprof --show_bytes /usr/sbin/ns-slapd /run/dirsrv/jeprof.2613573.0.f.heap