🛠️ На сервере память есть, а сервис всё равно получил OOM kill

Это возможно, если процесс упёрся не в RAM всей машины, а в лимит своего cgroup.

Для cgroup v2 проверьте:

memory.current memory.max memory.events

memory.current — текущее потребление cgroup и descendants.

memory.max — hard limit.

Если usage достигает memory.max и reclaim не помогает, OOM killer может сработать внутри cgroup, даже если host RAM ещё не исчерпана.

В memory.events смотрите:

oom oom_kill

Важно:

oom ≠ oom_kill

OOM event не обязан каждый раз приводить к kill.

Почему free -h недостаточно?

Он показывает host-level картину.

Но сервис может иметь:

memory.max = 2 GiB

на машине с 64 GiB RAM.

Тогда host ещё свободен, а workload уже исчерпал свой лимит.

Диагностический порядок:

время падения → kernel/service logs → cgroup процесса → memory.current → memory.max → memory.events → unit/container limits → host memory

Только после этого различайте:

global OOM или cgroup-local OOM

Ещё две оговорки.

memory.high и memory.max — разные механизмы: high создаёт reclaim pressure и throttling, max — hard limit.

А memory.events иерархический. Если нужны только события самого cgroup, смотрите memory.events.local.

Не увеличивайте RAM или memory.max автоматически.

Сначала выясните, почему workload дошёл до предела.

Сохраните артефакты, которые стоит проверить до вывода «на сервере закончилась память».

🔹🔹🔹🔹