Снятие дампов памяти

Снятие дампов памяти#

Для анализа ошибок в работе Global ERP разработчики могут запросить дамп кучи (heap) сервера приложений, шедулера, компонента gossiprouter или обходчика очередей. Снять его в gs-ctk можно при помощи встроенной утилиты ./make_dump.sh.

Автоматическое снятие дампов#

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

Автоматическое снятие дампа происходит в следующих случаях:

  1. Сборщик мусора (GC) в Java работает без перерыва более 30 секунд.

    Это может указывать на чрезмерную нагрузку на память или утечки, из-за которых JVM не может завершить сборку мусора. Такое состояние часто приводит к «застыванию» приложения.

  2. Работа GC занимает более 99% всего времени выполнения JVM.

    При такой ситуации приложение практически остановлено из-за постоянных сборок мусора, что серьёзно снижает производительность и отзывчивость сервиса. Постоянная работа GC может сопровождаться возникновением OutOfMemoryError в прикладном коде. Само исключение OutOfMemoryError не является триггером снятия дампа, дамп снимается при достижении пороговых значений работы GC.

  3. Сервер перестаёт корректно отвечать на запросы на сервис /app/sys/monitor/public/isAlive.

    Это сигнализирует о том, что приложение не отвечает на внешние проверки доступности, что может быть вызвано зависанием, нехваткой ресурсов, внутренней ошибкой или незапланированный переход в другой режим работы сервера.

Важно

Автоматическое снятие дампа не выполняется при завершении контейнера Kubernetes по причине превышения установленного лимита памяти (OOMKilled). В этом случае процесс завершается ядром операционной системы непосредственно при возникновении нехватки памяти. Предварительно выполнить команду снятия heap dump невозможно, поэтому состояние памяти JVM непосредственно перед завершением контейнера сохранить нельзя.

Событие OutOfMemoryError внутри JVM также само по себе не является триггером автоматического снятия дампа. Если нехватка памяти приводит к длительной или практически непрерывной работе GC, дамп может быть снят по одному из описанных выше GC-триггеров до завершения процесса.

При расследовании OOMKilled следует использовать логи приложения, события Kubernetes и метрики использования памяти за период перед перезапуском пода.

При срабатывании любого из условий происходит следующее:

  • снимается дамп кучи и сохраняется в системное NFS-хранилище (в ту директорию dumps/<группа_ресурсов>/...);

  • сервер приложений автоматически перезапускается, чтобы восстановить нормальную работу.

Это означает, что в проблемном состоянии дамп снимается только один раз; после перезапуска, если проблема возникнет снова, условия будут отслеживаться заново и может быть снят новый дамп.

Все параметры автоматического дампинга (интервалы, пороговые значения, триггеры) фиксированы и не подлежат настройке пользователем.

Что делать при появлении автоматических дампов#

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

  • Скачайте файл дампа с NFS-хранилища для дальнейшего анализа или передачи разработчикам.

  • Проверьте логи сервера приложений и метрики в Grafana (особенно, дашборд VM Memory) за период 5–15 минут до момента создания дампа, чтобы получить контекст произошедшего (нагрузка, количество запросов, использование памяти, время ответа и т.п.).

  • Сообщите о проблеме разработчикам Global ERP, приложив при необходимости полученный дамп и собранную информацию. Это поможет быстрее диагностировать и устранить причину сбоя.

Примечание

Все дампы (как автоматические, так и созданные вручную) автоматически удаляются из системного хранилища через три дня. Удаление выполняется компонентом nsctl, который регулярно проверяет время создания файлов и очищает устаревшие. Поэтому при обнаружении проблемы следует своевременно скачать необходимые файлы.

Использование в nscli#

Запустите утилиту, указав ваше пространство имен и, опционально, название пода:

./make_dump.sh --namespace gs-ctk --pod gs-cluster-1-global-server-share-12345678-9abc

Если вы не укажете название пода, вам будет предложено выбрать один из подов, в котором можно снять дамп. Выбрать под можно клавишами клавиатуры со стрелками.

Выберите под для снятия дампа:gs-cluster-1-global-server-share-12345678-9abc
Снятие дампа сервера приложения (планировщика, gossiprouter, обходчика очередей) с пода gs-cluster-1-global-server-share-12345678-9abc
Снятие дампа globalserver
Dumping heap to /root/globalserver/workspace/mnt/sys/dumps/gs-cluster-1/gs-cluster-1-global-server-share-12345678-9abc-qgld8_2026_04_01_10_00_00.hprof.tmp ...
Heap dump file created [28915853 bytes in 0.038 secs]
Снят дамп и сохранен на системное (NFS) хранилище по адресу: `dumps/gs-cluster-1/gs-cluster-1-global-server-share-12345678-9abc-qgld8_2026_04_01_10_00_00.hprof`. Файл будет автоматичнски удален через три дня.

Использование в поде#

Если вы не хотите использовать nscli, вы можете запустить команду непосредственно в поде:

./make_dump.sh

Снятие дампа globalserver
Dumping heap to /root/globalserver/workspace/mnt/sys/dumps/gs-cluster-1/gs-cluster-1-global-server-share-12345678-9abc-qgld8_2026_04_01_10_00_00.hprof.tmp ...
Heap dump file created [28915853 bytes in 0.038 secs]
Снят дамп и сохранен на системное (NFS) хранилище по адресу: `dumps/gs-cluster-1/gs-cluster-1-global-server-share-12345678-9abc-qgld8_2026_04_01_10_00_00.hprof`. Файл будет автоматичнски удален через три дня.
Содержание