Linux cgroups v2: управление ресурсами процессов

Смотрим текущее состояние cgroups через несколько инструментов:

# Общая информация о cgroups в системе
systemctl status  # показывает cgroup-дерево

# Дерево cgroups через systemd
systemd-cgls

# Статистика использования ресурсов
systemd-cgtop

# Посмотреть cgroup конкретного процесса
cat /proc/$(pgrep nginx)/cgroup
# Пример вывода:
# 0::/system.slice/nginx.service

# Просмотр файлов cgroup nginx
ls /sys/fs/cgroup/system.slice/nginx.service/
# cpu.max  memory.current  memory.max  cgroup.procs  io.stat  ...

# Текущее использование памяти
cat /sys/fs/cgroup/system.slice/nginx.service/memory.current

Проверяем, какие контроллеры включены:

# Корневые контроллеры
cat /sys/fs/cgroup/cgroup.controllers
# cpu io memory pids

# Включённые субтроллеры для следующего уровня
cat /sys/fs/cgroup/cgroup.subtree_control
# cpu io memory pids

# Включить контроллер для пространства (если не включён)
echo "+cpu +memory +io" > /sys/fs/cgroup/cgroup.subtree_control

Три способа ограничить CPU для сервиса:

# 1. Через systemctl set-property (немедленно + сохраняется)
systemctl set-property nginx.service CPUQuota=50%
# 50% одного ядра. Для 2 ядер полностью: CPUQuota=200%

# 2. Через unit-файл (override)
systemctl edit nginx.service
# Добавляем в открывшийся редактор:
# [Service]
# CPUQuota=50%
# CPUWeight=80

# 3. Через drop-in файл вручную
mkdir -p /etc/systemd/system/nginx.service.d/
cat > /etc/systemd/system/nginx.service.d/limits.conf << 'EOF'
[Service]
CPUQuota=50%
CPUWeight=80
EOF
systemctl daemon-reload && systemctl restart nginx

# Проверка
cat /sys/fs/cgroup/system.slice/nginx.service/cpu.max
# 50000 100000  — 50000 мкс из 100000 мкс = 50%

systemctl show nginx.service -p CPUQuota,CPUWeight

CPUWeight (1-10000, default=100) — относительный приоритет при конкуренции. CPUQuota — жёсткий лимит. При высокой нагрузке лучше использовать оба.

Управление памятью с мягким и жёстким лимитом:

# Мягкий лимит — начало throttling при достижении
systemctl set-property myapp.service MemoryHigh=400M

# Жёсткий лимит — OOM kill при достижении
systemctl set-property myapp.service MemoryMax=512M

# Зарезервировать память (гарантия)
systemctl set-property myapp.service MemoryMin=128M

# Отключить swap для сервиса
systemctl set-property myapp.service MemorySwapMax=0

# Проверка текущего использования
systemctl show myapp.service -p MemoryHigh,MemoryMax,MemoryCurrent

# Реальное потребление прямо из cgroup
cat /sys/fs/cgroup/system.slice/myapp.service/memory.current
cat /sys/fs/cgroup/system.slice/myapp.service/memory.stat

На серверах с PostgreSQL мы выставляем MemoryHigh на 75% от shared_buffers + work_mem * max_connections, а MemoryMax на 90% от RAM. Это защищает от OOM kill других сервисов при неожиданном росте запросов.

Ограничение дисковых операций — важно для серверов с несколькими сервисами на одном диске:

# Узнаём device number для диска
ls -la /dev/sda
# brw-rw---- 1 root disk 8, 0 ... /dev/sda
# Major:Minor = 8:0

# Ограничение чтения и записи
systemctl set-property myapp.service IOReadBandwidthMax="/dev/sda 50M"
systemctl set-property myapp.service IOWriteBandwidthMax="/dev/sda 30M"

# Относительный приоритет I/O (1-10000)
systemctl set-property myapp.service IOWeight=50  # Ниже default 100

# Для SSD — лимит IOPS
systemctl set-property myapp.service IOReadIOPSMax="/dev/sda 5000"
systemctl set-property myapp.service IOWriteIOPSMax="/dev/sda 3000"

# Статистика I/O по cgroup
cat /sys/fs/cgroup/system.slice/myapp.service/io.stat

Создаём изолированный cgroup для процесса:

# Создаём cgroup
mkdir /sys/fs/cgroup/myapp

# Включаем контроллеры
echo "+cpu +memory" > /sys/fs/cgroup/myapp/cgroup.subtree_control

# Устанавливаем лимиты
echo "50000 100000" > /sys/fs/cgroup/myapp/cpu.max   # 50% CPU
echo $((512 * 1024 * 1024)) > /sys/fs/cgroup/myapp/memory.max  # 512 МБ
echo $((400 * 1024 * 1024)) > /sys/fs/cgroup/myapp/memory.high

# Запускаем процесс в cgroup
echo $$ > /sys/fs/cgroup/myapp/cgroup.procs  # текущий shell
./myapp  # запускается в контексте cgroup

# Или через systemd-run
systemd-run --scope -p CPUQuota=50% -p MemoryMax=512M ./myapp

# Мониторинг
cat /sys/fs/cgroup/myapp/cpu.stat
cat /sys/fs/cgroup/myapp/memory.events  # показывает OOM-события

Набор команд для ежедневного мониторинга:

# Интерактивный топ по cgroups
systemd-cgtop -d 1  # обновление каждую секунду

# Потребление памяти всех сервисов
systemctl list-units --type=service --state=running \
  | awk '{print $1}' \
  | xargs -I{} sh -c 'echo -n "{}: "; systemctl show {} -p MemoryCurrent | cut -d= -f2'

# Экспорт метрик cgroups в Prometheus
# Используем node_exporter с флагом --collector.cgroups
# Метрики: node_cgroup_cpu_usage_seconds_total, node_cgroup_memory_usage_bytes

# Проверка OOM-событий
cat /sys/fs/cgroup/system.slice/myapp.service/memory.events
# anon 12345
# file 67890
# oom 0        <- если не 0 — был OOM kill
# oom_kill 0

Показатель oom_kill в memory.events — первое, что мы проверяем при жалобах на нестабильную работу сервиса. Если там не ноль, значит процесс убивали по памяти и нужно или поднять лимит или оптимизировать приложение.