Linux: Cgroups — Как контейнеры держат свои обещания (и как вы можете)

Вы когда-нибудь задумывались, как Docker или Kubernetes могут гарантировать, что один контейнер не "съест" все ресурсы сервера, оставив остальные голодать? Ответ — cgroups (Control Groups).

Что такое cgroups?
Это механизм ядра Linux, который позволяет организовывать процессы в иерархические группы и управлять их доступом к системным ресурсам:

CPU: Сколько процессорного времени может использовать группа.

Memory: Максимальный объем оперативной памяти.

Disk I/O: Приоритет и скорость чтения/записи на диск.

Network: Ограничения на сетевой трафик.

▪️ Почему это важно для админа?

Контейнеры (Docker, Podman, LXC): Они используют cgroups как основу для изоляции ресурсов. Когда вы задаете -m 512M для Docker-контейнера, это cgroups устанавливает лимит памяти.

Защита от "шумных соседей": Если у вас несколько сервисов на одном VDS/сервере, вы можете создать cgroup для каждого и гарантировать, что один прожорливый процесс не подвесит всю систему.

Обеспечение SLA: Для критически важных сервисов можно выделить гарантированный минимум ресурсов.

Тюнинг производительности: Можно приоритезировать ресурсы для одних процессов и ограничить для других.

▪️ Простой пример: Ограничиваем CPU для "прожорливого" процесса
Представьте, что у вас есть скрипт heavy_calc.sh, который грузит одно ядро на 100%.

Создаем cgroup (например, cpulimit):

Bash

sudo mkdir /sys/fs/cgroup/cpu/cpulimit

Путь может немного отличаться в зависимости от версии Linux и наличия systemd.

Устанавливаем лимит CPU (например, 50% одного ядра):

Bash

# Для systemd cgroups v2:
# cd /sys/fs/cgroup/user.slice/user-1000.slice/
# sudo echo "cpu.max 50000 100000" > cpu.max
# Или более универсально для cgroups v1:
sudo bash -c "echo 50000 > /sys/fs/cgroup/cpu/cpulimit/cpu.cfs_quota_us"
sudo bash -c "echo 100000 > /sys/fs/cgroup/cpu/cpulimit/cpu.cfs_period_us"

cpu.cfs_period_us - общий период (100мс = 100000мкс)
cpu.cfs_quota_us - сколько микросекунд можно использовать за период. 50% = 50000мкс

Добавляем процесс в cgroup:
Сначала запустите ваш "прожорливый" процесс в фоновом режиме, получите его PID.

Bash

./heavy_calc.sh &
PID=$! # Запоминаем PID
sudo bash -c "echo $PID > /sys/fs/cgroup/cpu/cpulimit/tasks"

Теперь этот процесс не сможет использовать более 50% одного ядра, даже если сервер свободен.

🧠 Взгляд архитектора:
Понимание cgroups — это фундамент для работы с контейнерными технологиями и тонкой настройки производительности Linux-систем. Это тот уровень контроля, который позволяет строить по-настоящему стабильную и предсказуемую инфраструктуру, где ресурсы распределяются не случайным образом, а согласно вашим четким правилам.

#Linux #Cgroups #Containers #Performance #Systemd #DevOps

Linux & systemd: Управляем ресурсами "на лету" без перезагрузки

Представьте, один из сервисов (например, тестовое веб-приложение или скрипт аналитики) начал потреблять слишком много CPU или памяти, влияя на работу основных служб. Классическое решение — убить процесс. Архитектурное — ограничить его аппетиты.

systemd позволяет управлять ресурсами (CPU, память, I/O) для любого сервиса с помощью cgroups (Control Groups), и делать это "на лету".

Практический кейс: Ограничить сервис analytics.service максимум 20% CPU и 512MB RAM.

Проверяем текущее потребление:
systemd-cgtop — это htop для контрольных групп. Он покажет, какие сервисы и пользователи сколько ресурсов потребляют.

Bash

sudo systemd-cgtop

Устанавливаем ограничения "на лету":
Эти настройки будут действовать до перезагрузки сервиса или системы. Идеально для экстренных ситуаций.

Bash

# Ограничиваем CPU до 20%
sudo systemctl set-property analytics.service CPUQuota=20%
# Ограничиваем память до 512MB
sudo systemctl set-property analytics.service MemoryMax=512M

Закрепляем настройки на постоянной основе:
Чтобы ограничения применялись при каждом запуске, нужно добавить их в unit-файл сервиса.

Bash

# Открываем unit для редактирования
sudo systemctl edit analytics.service

В открывшийся файл добавьте секцию [Service] с параметрами:

Ini, TOML

[Service]
CPUQuota=20%
MemoryMax=512M

Сохраните файл и перезагрузите конфигурацию: sudo systemctl daemon-reload.

Взгляд архитектора:
Это гарантия качества обслуживания (QoS) на уровне одного сервера. Управляя ресурсами, вы предотвращаете ситуацию, когда один второстепенный процесс кладёт всю систему. Это фундаментальный подход для построения стабильной и предсказуемой инфраструктуры, особенно в средах с множеством сервисов (multi-tenant).

#linux #systemd #cgroups #sre #гайд

Linux: "Почему мой Docker-контейнер тормозит?" Вскрываем `cgroups`

Вы выделили Docker-контейнеру 2 CPU, а он "задыхается". Вы запускаете htop на хосте — а там 20% простоя. Что происходит?

Происходит CPU Throttling (троттлинг). Ваш контейнер хочет больше CPU, но cgroups (Control Groups) его "душат".

cgroups — это технология ядра, которая изолирует и ограничивает ресурсы (CPU, RAM, I/O) для групп процессов. Это фундамент, на котором стоят systemd, Docker и Kubernetes.

Как увидеть "троттлинг" своими глазами:

Найдите "слайс" вашего контейнера:

Bash

# Найти "слайс" Docker
systemd-cgls | grep 'docker-'
# /docker-a1b2c3d4e5f6.scope
Прочитайте статистику CPU (самое важное):

Bash

# Идем в "папку" cgroup этого контейнера
cd /sys/fs/cgroup/cpu/docker/a1b2c3d4e5f6...

# Читаем файл статистики
cat cpu.stat

* nr_periods: Сколько раз процесс "приходил" за CPU.

* nr_throttled: Сколько раз ему было отказано (он был "задушен").

* throttled_time: Суммарное время, которое процесс провел в "задушенном" состоянии (в наносекундах).

Взгляд архитектора: Если nr_throttled (количество удушений) постоянно растет — вы нашли корень зла. Вы доказали, что проблема не в "тормозах", а в нехватке выделенных ресурсов. top вам этого никогда не покажет. Архитектор валидирует лимиты, а не гадает.

#linux #sre #docker #cgroups #performance #diagnostics #гайд #architect

🐧 Linux: systemd-run — запускаем скрипты в «песочнице» на лету 🛡️

Запускаешь тяжелый бэкап или скрипт миграции и боишься, что он съест всю память и положит прод? Не нужно писать сложные unit-файлы. В 2026 году админы используют Transient Scopes (временные скоупы).

Команда systemd-run позволяет обернуть любую команду в полноценный сервис с лимитами ресурсов прямо из консоли.

Команда дня:

# Запускаем скрипт, даем ему максимум 500Мб RAM и низкий приоритет CPU
systemd-run --scope -p MemoryMax=500M -p CPUWeight=20 ./heavy_script.sh

Что происходит: Скрипт запускается как обычно, но ядро Linux (cgroups) держит его в жестких рукавицах. Если скрипт попытается съесть 501 Мб — он будет убит (OOM), но основной сервер даже не поперхнется.

Почему это топ: Это идеальный способ тестировать лимиты для будущих сервисов или безопасно запускать "одноразовые" задачи на живом проде. 🧠

#linux #systemd #cgroups #performance #sysadmin #safety #devops