Руководство ядра по cgroup v2 разделяет общую иерархию и контроллеры ресурсов. Вложенная группа не может отменить ограничения, заданные выше в дереве. При разборе лимита нужно знать путь группы и уровень, на котором действует правило.

Почему число в контейнере не весь ресурс

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

Запросите у ответственного версию cgroups, доступные контроллеры и эффективные ограничения. Не переносите имя файла или значение из v1 в v2 как универсальный формат. Возможность чтения настроек также не дает разрешения менять их на общем узле.

Два разных порога памяти в v2

ПолеСмысл по документации v2
memory.highПорог давления на освобождение памяти и замедления группы
memory.maxЖесткая граница, при невозможности освобождения возможен OOM внутри группы

Превышение memory.high само по себе не вызывает OOM killer. У memory.max есть оговорки о временном превышении и поведении отдельных выделений. Поэтому не называйте оба значения одинаковым «максимумом RAM» и не диагностируйте завершение процесса по одной строке.

Как сформулировать проверку

Сохраните группу приложения, уровни выше нее, время ошибки и признаки потребления ресурса. Отделите ограничение CPU, память, ввод-вывод и число процессов. Если не хватает права читать нужный уровень, укажите это как неизвестное, а не подставляйте размер из тарифной витрины.

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

Cgroups не заменяют namespaces и seccomp: это другие механизмы. Практическая подготовка описана в Docker. Источник прочитан 7 октября 2026 года; группы, контроллеры и лимиты не менялись, процессы не переносились. Другие определения находятся в словаре.