Контрольные группы в systemd: учёт и ограничение ресурсов
Механизм ядра для группировки процессов, учёта их потребления и ограничения ресурсов. systemd помещает каждый unit в свою контрольную группу и строит из них дерево.
Что делает
Именно контрольные группы позволяют systemd надёжно отслеживать процессы службы. Старые системы инициализации теряли «осиротевшие» процессы, а здесь они остаются в группе — отсюда возможность остановить службу целиком и посмотреть её потребление.
Дерево устроено просто: системные службы лежат в system.slice, сеансы пользователей в user.slice, свои группы служб — в собственных срезах. Ограничения наследуются: потолок среза ограничивает всех его участников.
Где ставится. Дерево видно командами systemd-cgls и systemd-cgtop, ограничения задаются параметрами unit.
Значения
| Значение | Что происходит |
|---|---|
systemd-cgls | дерево контрольных групп с процессами. |
systemd-cgtop | потребление по группам, как top. |
systemctl status имя | в конце вывода показывает группу службы и её процессы. |
/sys/fs/cgroup | файловая система, через которую всё это работает. |
Пример
Кто потребляет память и процессор на машине.
systemd-cgtop -1 --order=memory
systemd-cgls /system.slice --no-pager | head -40
systemctl status myapp.service --no-pager | tail -12Последние строки вывода состояния — это список процессов службы из её контрольной группы. По нему видно, что служба породила на самом деле.
Типичные ошибки
Ограничение среза сильнее ограничения службы: упор может быть не там, где вы правите.
В контейнерах доступ к дереву групп часто урезан, и часть ограничений не применяется.
На системах со смешанной иерархией (первая и вторая версия одновременно) поведение ограничений неполное.
Связанные ошибки
- status=219/CGROUP в systemdКод 219/CGROUP: не удалось создать или настроить контрольную группу службы. Причины на уровне системы и контейнеров.
- Failed with result 'resources'Состояние resources: systemd не смог выделить ресурсы для запуска службы. Чем отличается от кодов 200-й группы и что проверять.
- Failed with result 'oom-kill'Состояние oom-kill: процесс службы убит из-за нехватки памяти. Как понять, упёрлись в предел службы или в память машины.
Рядом стоящие параметры
Где важен на практике
Источники
- systemd.resource-control(5)
- Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)