linuxlab.io
Учебники▾
  • Линукс и сети
    Файловая система, процессы, TCP/IP, BGP и OSPF
    →
  • Terraform и IaC
    HCL, state, plan/apply на sandbox LocalStack
    →
  • Git и GitHub
    Объектная модель, plumbing, ветвление, GitHub Actions
    →
Все учебники →
ЦеныО платформеВойтиСоздать аккаунт
/
  • Введение
  • Уроки
  • How it works
  • Симулятор
  • База знаний
  • Собеседование
Index
Categories
All entries
Footer
linuxlab-УчебникиЦеныО платформеКонфиденциальность и куки
Copyright © 2026 LinuxLab. Все права защищены.
home/linux/kb/Процессы и ресурсы/cgroups

kb/processes ── Процессы и ресурсы ── advanced

cgroups (v2)

cgroups v2 - иерархическая виртуальная FS под `/sys/fs/cgroup` через которую ядро лимитирует CPU/память/I/O процессов. Docker/k8s/systemd пишут сюда.

view as markdownaka: cgroup, cgroups-v2, control-groups

Что такое cgroup

Control group - группа процессов с общими ограничениями ресурсов (CPU, RAM, I/O, PIDs, network) и общим учётом потребления.

В cgroups v2 (стандарт на современных Ubuntu/Debian/Fedora) - одна иерархия каталогов под /sys/fs/cgroup/. Каждый каталог это cgroup. Подкаталоги - дочерние cgroup'ы (наследуют лимиты родителя).

Каждый процесс приписан к ровно одному cgroup'у. Узнать свой:

bash
cat /proc/self/cgroup
# 0::/system.slice/docker-abc123.scope

Полный путь = /sys/fs/cgroup + значение из файла.

Контроллеры

В рамках одной иерархии включаются «контроллеры» - модули учёта/лимитов:

  • cpu - share / quota; cpu.max = quota period (e.g. 50000 100000 = половина CPU)
  • memory - memory.max = hard limit, memory.high = soft (троттл с reclaim)
  • io - bandwidth и iops по устройствам (io.max)
  • pids - pids.max (сколько процессов разрешено)
  • cpuset - пиннинг к конкретным ядрам и NUMA-нодам

Включаются через cgroup.subtree_control:

bash
cat /sys/fs/cgroup/cgroup.controllers       # доступные
cat /sys/fs/cgroup/cgroup.subtree_control   # включённые на дочерних

Что туда пишут Docker / k8s / systemd

Когда ты делаешь docker run --cpus=0.5 --memory=256m:

  • Docker создаёт /sys/fs/cgroup/system.slice/docker-<id>.scope/
  • Пишет cpu.max = "50000 100000" (50ms из 100ms)
  • Пишет memory.max = 268435456
  • Помещает PID контейнерного init в cgroup.procs

k8s pod с resources: limits: { cpu: 500m, memory: 256Mi } делает то же через kubelet → cri-o/containerd → ядро.

systemd unit с MemoryMax=512M - то же самое, только через slice/scope-юниты.

PSI - Pressure Stall Information

Самое полезное в v2 - файлы cpu.pressure, memory.pressure, io.pressure. Они показывают сколько % времени процесс ждал ресурс. PSI точнее load-average потому что нормализован и работает per-cgroup (важно в контейнерах).

some avg10=12.34 avg60=8.90 avg300=4.50 total=...
full avg10=2.10  avg60=1.80 avg300=0.90 total=...

some = хотя бы один процесс ждал; full = ВСЕ процессы ждали.

OOM в cgroup

Когда процесс в cgroup'е упирается в memory.max, срабатывает oom-killer

  • но только в пределах этого cgroup'а, остальная система не страдает.

§ команды

bash
cat /proc/self/cgroup

В каком cgroup'е находится текущий процесс

bash
MY=$(awk -F: '{print $3}' /proc/self/cgroup); ls /sys/fs/cgroup$MY

Какие контроллеры доступны для нашего cgroup'а

bash
cat /sys/fs/cgroup/cpu.max

CPU-лимит текущего корневого cgroup'а: `<quota> <period>` µs или `max`

bash
cat /sys/fs/cgroup/memory.current

Сколько RAM cgroup использует прямо сейчас (байты)

bash
cat /sys/fs/cgroup/cpu.pressure

PSI - точная метрика «насколько ресурс в дефиците» на per-cgroup уровне

§ см. также

  • process-and-pidПроцесс и PIDПроцесс - это запущенная программа со своим PID, памятью, открытыми дескрипторами и UID. Все процессы образуют дерево, корень - init (PID 1).
  • namespacesLinux namespacesNamespaces - механизм ядра, который даёт процессу собственный изолированный view на ресурс (сеть, mount-points, PID, UID, IPC, hostname, time). На них построены все контейнеры.
  • cgroups-v2-deepcgroups v2 - unified hierarchy, PSI, eBPF controlcgroups v2 - один tree вместо отдельных hierarchies на controller. Чистая семантика, новые fields (memory.high, io.cost). PSI показывает resource pressure. eBPF может управлять resources. Default в RHEL 9, Ubuntu 22+.
  • oom-killerOOM killerOOM killer - механизм ядра, который выбирает и завершает процесс когда система упирается в лимит памяти. В контейнерах работает per-cgroup.
  • kubelet-internalskubelet - архитектура агента ноды Kuberneteskubelet - демон на каждой ноде. Получает PodSpec через API, запускает контейнеры через CRI, монтирует volumes через CSI, следит за health. При pressure делает eviction. Image GC и cgroup-tree - тоже его.

§ упоминается в уроках

  • ›advanced-02-cgroups-v2
  • ›advanced-07-perf-and-flame
  • ›beginner-02-directory-tree
Footer
linuxlab-
Copyright © 2026 LinuxLab. Все права защищены.
Учебники
Цены
О платформе
Конфиденциальность и куки