Главная / Справочник ошибок / Контейнеры и Kubernetes
Процесс убит из-за нехватки памяти
Out of memory: Killed process 12345 (dotnet). Контейнер OOMKilled, exit code 137
OOMKilled, exit code 137, Out of memory: Killed process в логе ядра: Linux убил процесс или контейнер Directum RX, которому не хватило памяти. Как найти, кого и почему, и отличить утечку от тесного лимита.
Что это значит
Ядро Linux завершило процесс сигналом 9, потому что память кончилась. Код выхода 137 означает именно это (128 + 9). Бывает два случая. Контейнер упёрся в собственный лимит: в логе ядра Memory cgroup out of memory. Память кончилась на всём сервере, и ядро выбрало самый большой процесс. Вторым обычно оказывается база или сервис RX.
Сам процесс об этом ничего не пишет: его лог обрывается на полуслове.
Как проверить
dmesg -T | grep -i -E "out of memory|killed process" | tail
docker inspect -f '{{.Name}} oom={{.State.OOMKilled}} restarts={{.RestartCount}}' $(docker ps -aq)
docker stats --no-stream
kubectl describe pod <под> | grep -A5 "Last State"
Что сделать
- Понять, утечка это или тесный лимит. Снимите потребление памяти дважды с разницей в сутки при похожей нагрузке. Только растёт: утечка, нужны разработчики. Держится у лимита ровно: лимит мал.
- Тесный лимит поднять с запасом от 20 до 30 % над рабочим потреблением.
- Для Java и .NET проверить, что среда знает о лимите контейнера. Иначе куча считается от памяти сервера.
- Если убивают на уровне сервера, сложить потребности: база, брокер, поиск и сервисы на одном сервере должны помещаться в его память с запасом.
rxdoctor показывает убитые контейнеры и занятость памяти к лимиту пунктами OS-06 и OS-07. Командой rxdoctor diff удобно сравнить два замера.