Linux proc_pid_oom_score(5) описывает оценку процесса для выбора при OOM. Документация cgroup v2 отдельно рассматривает OOM внутри группы при достижении memory.max и невозможности снизить использование. Это разные сведения: оценка и фактическое событие.

Завершение не всегда OOM

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

Не обещайте, что при OOM всегда будет выбран процесс с самым большим объемом памяти. Для вывода нужны условия и политика конкретной среды. Само наличие оценки oom_score не означает, что процесс уже был жертвой.

Где действует ограничение

НаблюдениеЧто уточнить
Процесс остановилсяЕсть ли подтвержденное OOM-событие?
У сервера еще есть памятьНет ли ограничения группы приложения?
Событие повторяетсяКакая операция и потребление ему предшествуют?

В учебной ситуации группа достигает своей границы при запасе в других частях системы. Это не противоречие и не измерение вашего тарифа. Разберите cgroups и уровни иерархии вместо автоматического утверждения «весь сервер переполнен».

Восстановление должно сохранять данные

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

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

Источники прочитаны 7 октября 2026 года. Процессы не завершались, оценки и политики OOM не менялись, память не нагружалась. Не защищайте все процессы от завершения как способ диагностики. Разбор учета памяти есть в overcommit Linux, другие термины - в словаре.