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

Для анализа ошибок в работе 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`](https://help.globalerp.ru/books/gs-docs-sphinx/master/spec/services/http/rest/monitor/index.html#id3).**

   Это сигнализирует о том, что приложение не отвечает на внешние проверки доступности, что может быть вызвано зависанием, нехваткой ресурсов, внутренней ошибкой или незапланированный переход [в другой режим работы сервера](https://help.globalerp.ru/books/gs-docs-sphinx/master/spec/server/server_modes.html).

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

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

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

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

- снимается дамп кучи и сохраняется в системное NFS-хранилище (в ту директорию `dumps/<группа_ресурсов>/...`);
- сервер приложений автоматически перезапускается, чтобы восстановить нормальную работу. 

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

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

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

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

- **Скачайте файл дампа** с NFS-хранилища для дальнейшего анализа или передачи разработчикам.
- **Проверьте логи сервера приложений и метрики в Grafana** (особенно, дашборд VM Memory) за период 5–15 минут до момента создания дампа, чтобы получить контекст произошедшего (нагрузка, количество запросов, использование памяти, время ответа и т.п.).
- **Сообщите о проблеме разработчикам Global ERP**, приложив при необходимости полученный дамп и собранную информацию. Это поможет быстрее диагностировать и устранить причину сбоя.

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

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

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

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

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

```text
Выберите под для снятия дампа: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, вы можете запустить команду непосредственно в поде:

```bash
./make_dump.sh
```

```text
Снятие дампа 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`. Файл будет автоматичнски удален через три дня.
```