cgroups и ограничения ресурсов

rlimits: потолки ресурсов на процесс, применяемые ядром.

Каждый процесс наследует набор rlimits от родителя. У каждого лимита есть мягкое значение (текущий применяемый потолок, который процесс может понижать, но не поднимать выше жёсткого) и жёсткое значение (потолок для мягкого — только root может его поднять).

# Просмотр rlimits текущей оболочки:
ulimit -a
# core file size          (blocks, -c) 0
# max locked memory       (kbytes, -l) 8192
# open files                      (-n) 1024    ← RLIMIT_NOFILE мягкий
# max user processes              (-u) 63296   ← RLIMIT_NPROC

# Два лимита, которые чаще всего встречаются в продакшене:

# RLIMIT_NOFILE: максимальное количество открытых файловых дескрипторов
# По умолчанию мягкий: 1024. По умолчанию жёсткий: 1048576 (Ubuntu).
# При превышении: "Too many open files" (errno EMFILE)
# Node.js или Java-сервер под нагрузкой нуждается в гораздо большем.

# RLIMIT_NPROC: максимальное число процессов/потоков пользователя
# При превышении fork() возвращает EAGAIN: "Resource temporarily unavailable"
# Fork-бомбы останавливаются здесь.

Установка rlimits: ulimit для сессии, /etc/security/limits.conf для постоянства.

# Поднять лимит открытых файлов для текущей оболочки и её детей:
ulimit -n 65536
ulimit -n
# 65536

# Это влияет только на текущую сессию.
# Для сервиса — в /etc/security/limits.conf:
# *         soft  nofile  65536
# *         hard  nofile  1048576
# www-data  soft  nproc   4096

# Для systemd-сервисов — предпочтительнее LimitNOFILE в unit-файле:
# [Service]
# LimitNOFILE=65536
# Это правильный способ — limits.conf обходится для сервисов без PAM.

# Проверить реальные лимиты работающего процесса (PID 1234):
cat /proc/1234/limits
# Limit                     Soft Limit   Hard Limit   Units
# Max open files            65536        1048576      files
# Max processes             63296        63296        processes

cgroups v2: единая иерархия.

cgroups v2 (по умолчанию на Ubuntu 22.04+) использует единую файловую иерархию в /sys/fs/cgroup. Каждый процесс принадлежит ровно одной cgroup. systemd автоматически отображает сервисы на cgroups.

# Просмотр иерархии cgroup:
systemd-cgls
# Control group /:
# -.slice
#   ├─system.slice
#   │ ├─nginx.service
#   │ │ └─987 nginx: worker process
#   └─user.slice

# cgroup текущего процесса:
cat /proc/$$/cgroup
# 0::/user.slice/user-1000.slice/session-1.scope

# Доступные контроллеры:
cat /sys/fs/cgroup/cgroup.controllers
# cpuset cpu io memory hugetlb pids rdma misc

# Текущее использование памяти cgroup:
cat /sys/fs/cgroup/system.slice/nginx.service/memory.current
# 45678592   (байты — около 44 МБ)

# Использование CPU:
cat /sys/fs/cgroup/system.slice/nginx.service/cpu.stat
# usage_usec 123456789

CPUQuota и MemoryMax в systemd: установка лимитов для сервиса.

systemd транслирует директивы unit-файла в записи cgroup. Напрямую писать в /sys/fs/cgroup почти никогда не нужно.

# Установить лимит памяти и квоту CPU для сервиса:
sudo systemctl edit nginx
# Добавить:
# [Service]
# MemoryMax=512M
# CPUQuota=50%

# MemoryMax: cgroup memory.max — жёсткий потолок. При превышении
# ядро вызывает локальный OOM killer cgroup (убивает процесс в этой cgroup).
# НЕ системный OOM killer.

# CPUQuota=50%: cgroup получает не более 50% одного ядра CPU за период
# (период по умолчанию 100мс). На 4-ядерной машине 50% = одно ядро на полной
# скорости, НЕ 50% от всех 4 ядер.

sudo systemctl daemon-reload
sudo systemctl restart nginx

# Проверить применение лимитов:
systemctl show nginx | grep -E 'MemoryMax|CPUQuota'
# MemoryMax=536870912
# CPUQuotaPerSecUSec=500000

# Из cgroup напрямую:
cat /sys/fs/cgroup/system.slice/nginx.service/memory.max
# 536870912
cat /sys/fs/cgroup/system.slice/nginx.service/cpu.max
# 50000 100000   (50мс бюджета за 100мс период = 50%)

# Временные лимиты (без изменения unit-файла, для тестирования):
sudo systemctl set-property nginx.service MemoryMax=256M