#Как выглядит неисправность
Контейнер может завершаться с кодом 137, OOMKilled=true или ошибкой Out of memory внутри приложения. Код 137 не всегда означает нехватку памяти: процесс мог получить SIGKILL по иной причине. Сверяйте несколько признаков.
#Причины и признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Жёсткий лимит памяти DockerПриложение достигает --memory / mem_limit | OOMKilled=true в inspect, растёт MEMORY в stats | Снизить потребление или обоснованно поднять лимит |
| Утечка памяти в приложенииПотребление растёт даже на постоянной нагрузке | Повторные OOM после продолжительной работы | Измерить память и исправить приложение |
#Пошаговое устранение
- 1. Сопоставьте статус, код выхода и признак OOMВ терминале Docker выполните docker ps -a и docker inspect ... ИМЯ. Если OOMKilled=true — Docker зафиксировал убийство из-за памяти. Если только ExitCode=137, проверьте события и действия оператора.Linux · Терминал (Bash)КомандаЧтение состояния контейнера.
docker inspect --format '{{.State.ExitCode}} oom={{.State.OOMKilled}}' ИМЯ
- 2. Посмотрите лимиты контейнераВыполните docker inspect --format ... ИМЯ и найдите Memory. Ноль означает отсутствие заданного Docker жёсткого лимита, но остаются пределы хоста или родительских групп.Linux · Терминал (Bash)КомандаЛимит в байтах, только чтение.
docker inspect --format '{{.HostConfig.Memory}}' ИМЯ
- 3. Посмотрите потребление живого контейнераЕсли контейнер работает, запустите docker stats --no-stream ИМЯ. Сравните MEMORY USAGE / LIMIT с ресурсами хоста. Если контейнер остановлен, stats не покажет его прошлое потребление; используйте ранее собранные метрики.Linux · Терминал (Bash)КомандаОдин снимок использования ресурсов, без изменения параметров.
docker stats --no-stream ИМЯ
- 4. Проверьте журнал приложения и хостаВыполните docker logs --tail 100 ИМЯ. На Linux-хосте администратор может сверить сообщения ядра об OOM в journalctl -k, но не копируйте журналы с ключами и данными пользователей.Linux · Терминал (Bash)КомандаВывод может содержать конфиденциальные сведения.
docker logs --tail 100 ИМЯ
- 5. Сравните нагрузку и поведение памятиВ тестовой копии повторите одинаковую нагрузку, сравните пиковую память и частоту сборки мусора. Для Node.js, JVM, Python или БД используйте штатные профилировщики своей среды; не предполагайте, что любой рост RSS означает утечку.
- 6. Измените одно ограничение на тестовой копииПри доказанной недостаточности лимита согласуйте допустимый объём RAM. В compose.yaml используйте поддерживаемый вашей версией Compose параметр mem_limit для сервиса либо настройки платформы; затем docker compose config --quiet и пересоздание тестового сервиса.
- 7. Проверьте, что запас достаточенПовторите нагрузочный тест и docker stats --no-stream, убедитесь, что OOMKilled остаётся false и приложение отвечает. Если ресурс растёт без стабилизации, не лечите утечку бесконечным увеличением лимита.
#Как проверить результат
Успех: воспроизводимый тест проходит, контейнер не убивается из-за OOM, у хоста остаётся резерв памяти.
#Если проблема осталась
Не повторяйте опасные действия на рабочем окружении. Сравните первоначальный симптом с новым состоянием, сохраните обезличенные сообщения и версии компонентов, проверьте резервную копию; перед изменением общей истории Git или данных/сети Docker обратитесь к ответственному администратору проекта.