На мультисервисном хосте один из сервисов периодически потребляет всю доступную память и CPU, вызывая деградацию соседних сервисов ('шумный сосед'). Как вы спроектируете изоляцию ресурсов через systemd slices/cgroups, и какие компромиссы при этом возникают?

Короткий ответ

Единого правильного набора лимитов не существует: решение требует сгруппировать сервисы в systemd slices с заданными MemoryMax/CPUQuota/IOWeight, подобранными по реальному профилю нагрузки каждого сервиса, балансируя между строгой изоляцией (жёсткие лимиты, предотвращающие шумного соседа) и риском искусственного троттлинга/OOM-килла легитимных пиков нагрузки.

Как это работает подробнее

systemd позволяет организовать сервисы в иерархию slices (аналог дерева cgroups), где каждому slice или отдельному сервису можно задать лимиты CPU (CPUQuota, CPUWeight), памяти (MemoryMax, MemoryHigh) и ввода-вывода (IOWeight, IOReadBandwidthMax); ядро физически обеспечивает эти лимиты через cgroups v2, троттля CPU при превышении квоты и убивая процессы cgroup-level OOM killer'ом при превышении MemoryMax, что изолирует воздействие одного сервиса на остальные на одном хосте.

Пример кода

example.txtКопировать

# /etc/systemd/system/batch.slice
[Slice]
MemoryHigh=2G
MemoryMax=3G
CPUWeight=20
# /etc/systemd/system/api.slice
[Slice]
CPUWeight=80
IOWeight=500

Что использовать на практике

• Практика. подход: сначала профилировать нормальное и пиковое потребление каждого сервиса (через systemd-cgtop, metrics из cgroup v2 — cpu.stat, memory.current), затем задать MemoryHigh чуть выше нормального потребления как мягкий предел (soft throttle через reclaim) и MemoryMax как жёсткий потолок с запасом на легитимные пики, а CPUWeight — как относительный приоритет между сервисами вместо жёсткого CPUQuota там, где это уместно, чтобы не терять доступные простаивающие ресурсы в периоды низкой конкуренции.
• Компромисс. systemd-cgtop покажет реальное потребление CPU/памяти по каждому slice; при конкуренции за CPU сервисы в api.slice получат приоритет (CPUWeight=80 против 20), а сервисы в batch.slice будут троттлиться первыми, не затрагивая критичный API-трафик.

Подводные камни

• Риск. копировать лимиты с другого окружения без профилирования конкретной нагрузки; задавать слишком жёсткий MemoryMax, который соответствует среднему, а не пиковому потреблению, что приводит к частым OOM-киллам при нормальных всплесках; забывать, что IO-изоляция (IOWeight) не менее важна, чем CPU/память, если 'шумный сосед' на самом деле насыщает диск, а не CPU.