Поверхностный мониторинг кричит: «на хосте свободно 11 ГБ». Внутри cgroup v2 агент уже достиг memory.max, и kernel убил его без переговоров. Свободная RAM хоста не отменяет локальный лимит и OOM-событие. Проверка начинается не с top: cat /sys/fs/cgroup//memory.{current, high, max, events} и cat /sys/fs/cgroup//memory.stat. В memory.events ищите high, max, oom и oom_kill; PSI покажет цену давления: cat /proc/pressure/memory. Это отделяет reclaim от настоящего убийства. Практичная схема: memory.high ставится ниже memory.max, чтобы агент сначала замедлялся и чистил кэш, а между high и max оставляется операционный резерв. Контролируйте memory.events и memory.current в динамике, а не только процент использования. vmstat 1 и journalctl -k -g 'oom|Killed process' фиксируют след ядра. Слишком жёсткий max экономит считанные гигабайты, но цена — потерянные логи, слепой мониторинг и аварийная ручная работа. Это плохой TCO, особенно когда простой агента запускает штрафы или нарушает SL...