Контейнер завершился с кодом 137: хватало ли ему памяти

Код завершения контейнера 137 связан с SIGKILL и сам по себе не доказывает нехватку памяти. Сопоставьте состояние OOMKilled, события контейнера, ограничения памяти и журнал хоста за тот же период. Причину завершения и причину последующего запуска разбирайте отдельно: политика перезапуска может лишь повторять неисправный сценарий.

Начните с завершившегося экземпляра

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

Не объединяйте сведения разных экземпляров только потому, что у них одинаковое имя сервиса. Если система развёртывания создала замену, метаданные нового контейнера не становятся историей старого. Нужна привязка событий к конкретной нагрузке.

В справке Docker о коде 137 этот статус описан как завершение через SIGKILL. Среди возможных причин есть принудительное завершение. Поэтому формула «137 — значит добавить RAM» пропускает проверку источника сигнала.

Соберите несколько независимых признаков

В структуре состояния Moby, используемой при inspect, отдельно присутствуют OOMKilled, ExitCode, StartedAt и FinishedAt. Поля нужно читать вместе и относить к рассматриваемому запуску. Одной строки с числом недостаточно для истории события.

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

Проверьте обычную остановку, которая стала принудительной

В документации docker stop описан переход к SIGKILL после периода ожидания завершения. Первый сигнал может задаваться отдельно. Поэтому посмотрите, совпало ли событие с развёртыванием, ручной остановкой или обслуживанием.

Если приложение не завершает работу в предусмотренном порядке, разберите обработку остановки и незавершённые задания. Повышение памяти не является ответом на этот сценарий. Но и увеличение времени ожидания без понимания оставшейся работы не объясняет, почему процесс не успевает остановиться.

Лимит контейнера и давление на хост

Docker различает ограничения памяти контейнера и риск нехватки ресурсов на Linux-хосте. Свободная память всей машины не отменяет более низкую границу конкретной нагрузки. И отсутствие нужной границы может позволить одной нагрузке повлиять на соседние процессы.

Сохраните эффективный лимит и доступные метрики за период до завершения. Сравнивайте показатели с одинаковой областью учёта. Число из одного инструмента нельзя автоматически сопоставить с другим, не выяснив, что каждый включает.

В описании cgroup v2 memory.max задаёт жёсткую границу, а memory.events содержит счётчики, в том числе oom_kill. Для иерархических показателей учитывайте потомков; одиночный накопленный счётчик не задаёт точное время нужного события.

Пик и постоянный рост требуют разных решений

Учебный сценарий А: редкая обработка большого набора повышает расход, после чего приложение возвращается к обычному состоянию. Сценарий Б: расход растёт от одинаковых циклов и не возвращается. Это разные гипотезы для исследования, а не диагноз по форме одной линии.

Для первого сценария проверьте размер порции, параллельность и допустимую стоимость задания. Для второго — удержание данных и жизненный цикл объектов. Решение о новом лимите принимают вместе с этим разбором и запасом хоста.

Мы советуем не снимать все ограничения и не отключать защитные механизмы OOM ради одного процесса. Сохранность остальных сервисов — часть требований. В сопровождении сервера нужен общий бюджет размещения, а не только пожелание приложения занять больше памяти.

Почему контейнер снова стартует

В описании restart policies Docker политика задаёт условия автоматического запуска после завершения. Такой запуск не устраняет причину отказа. Если нагрузка повторяется, внешне успешное восстановление может скрывать последовательность одинаковых потерь.

Проверьте, кто управляет запуском именно в вашей среде: Docker или отдельная система эксплуатации. Не меняйте несколько механизмов независимо. Зафиксируйте также, что происходит с заданием, которое выполнялось в момент завершения, и где подтверждается его итог.

После возврата процесса клиентам может требоваться восстановление соединений, а обработчику — разбор незавершённой работы. Наличие нового процесса не подтверждает, что операция выполнена ровно один раз. Для значимых действий это самостоятельный критерий приёмки.

Порядок безопасной проверки

1. Выберите конкретное завершение и сохраните связанные метаданные.
2. Сопоставьте код, OOM-признаки, события управления и журнал хоста.
3. Проверьте действующие ограничения и историю расхода до отказа.
4. Разделите нехватку ресурса, внешнее завершение и ошибку штатной остановки.
5. Выберите исправление приложения или подтверждённого бюджета с планом возврата.
6. Проверьте небольшой контролируемый сценарий в отдельной среде.
7. Подтвердите состояние незавершённой работы и условия следующего запуска.

Для доработки приложения передайте размер задачи и последовательность роста, а не только код 137. При необходимости аудита отдельно согласуйте доступ к диагностике. Рабочий хост не нужно доводить до OOM ради доказательства: задача — разобраться по сохранённым признакам и проверить исправление ограниченно.