cgroups v2 на хосте: проверка режима и чтение ограничений ресурсов юнитов

Цель

Подтвердить, в каком режиме cgroup работает Linux-хост, и изучить ограничения ресурсов, которые systemd — а через него контейнерные среды — применяет к конкретному юниту или контейнеру.

Предварительные условия

Доступ к оболочке; для просмотра без изменений root не нужен, но необходим для просмотра некоторых сведений о cgroup других пользователей.

Шаги

1. Проверьте режим: stat -fc %T /sys/fs/cgroup. Документация ядра по cgroup v2 монтирует единую иерархию с типом файловой системы cgroup2, который stat показывает как cgroup2fs; такой вывод означает, что хост полностью использует cgroup v2 (единый режим). Если вместо этого указан tmpfs, используется гибридная или устаревшая конфигурация (cgroup v1), где /sys/fs/cgroup — tmpfs с отдельными точками монтирования контроллеров v1 под ней.
2. Просмотрите дерево как иерархию срезов, областей и служб: systemd-cgls выводит всё дерево cgroup с процессами под каждым юнитом; systemd-cgls /system.slice/docker.service (или соответствующий срез) ограничивает просмотр одной ветвью.
3. Наблюдайте за текущим потреблением ресурсов по cgroup: systemd-cgtop показывает задачи, процессор, память и ввод-вывод каждой контрольной группы, обновляясь как top; это помогает найти контейнер или службу, потребляющую ресурсы хоста, не зная заранее её PID.
4. Прочитайте настроенные ограничения юнита systemd напрямую: systemctl show <unit> --property=MemoryMax,MemoryHigh,CPUQuotaPerSecUSec. Контейнер Podman Quadlet работает под своим сервисным юнитом; контейнер docker run --memory=512m с драйвером cgroup systemd (обычное значение по умолчанию для cgroup v2) становится docker-<id>.scope под system.slice, а с драйвером cgroupfs размещается в /sys/fs/cgroup/docker/<id>/. В обоих случаях читайте memory.max и cpu.max в этом каталоге, чтобы получить исходные значения, принудительно применяемые ядром (max означает отсутствие ограничения).
5. Сопоставьте контейнер с его путём cgroup: systemctl status <container-unit> (для Quadlet/управления через systemd) либо возьмите PID главного процесса контейнера (docker inspect --format '{{.State.Pid}}' <container>) и прочитайте /proc/<pid>/cgroup, где единственная строка 0::<path> в cgroup v2 задаёт путь относительно /sys/fs/cgroup. (.HostConfig.CgroupParent обычно пуст: он показывает только явно заданного родителя.)

Ожидаемый результат

stat -fc %T /sys/fs/cgroup сообщает cgroup2fs; systemd-cgtop и systemd-cgls показывают ожидаемое дерево юнитов с текущими показателями, соответствующими данным собственных команд stats контейнерной среды.

Ограничения и основание проверки

Путь и точные имена файлов контроллеров (memory.max, cpu.max и т. д.) относятся к единой иерархии, описанной в руководстве администратора ядра по cgroup v2; хост на устаревшей cgroup v1 предоставляет другие имена файлов для отдельных контроллеров и другие параметры ограничений (memory.limit_in_bytes), которые здесь не рассматриваются.