Omezení zdrojů cgroups v2 se systémem systemd

cgroups v2 je jednotný rámec pro řízení zdrojů jádra Linuxu. Nahrazuje roztříštěnou hierarchii v1 jediným stromem, který konzistentně zpracovává CPU, paměť a I/O a podporuje izolaci kontejnerů v Dockeru, Kubernetes a systemd. Tento příspěvek popisuje, jak povolit cgroups v2, nastavit limity přes systemd a aplikovat je na skutečné scénáře hostingu s více nájemci.

Povolení cgroups v2

Moderní distribuce se dodávají s cgroups v2 povolenými ve výchozím nastavení: Ubuntu 21.10+, Debian 11+, Fedora 31+ a RHEL/Rocky 9+. Starší systémy mohou používat hybridní hierarchii nebo stále používat výchozí nastavení v1. Zkontrolujte pomocí:

stat -fc %T /sys/fs/cgroup/

Výstup příkazu cgroup2fs potvrzuje, že v2 je aktivní. tmpfs obvykle znamená v1.

Chcete-li přepnout hybridní systém na čistou verzi v2, upravte /etc/default/grub a připojte následující k GRUB_CMDLINE_LINUX_DEFAULT:

systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all

Poté znovu vygenerujte GRUB a restartujte:

sudo update-grub
sudo reboot

Pro produkční prostředí použijte jádro 5.2 nebo novější, abyste získali cgroup freezer pro v2 a systemd 244+ pro plnou cpuset delegaci. Na Rocky Linux 8 a RHEL 8 možná budete muset také explicitně povolit účtování přidáním těchto řádků do /etc/systemd/system.conf:

DefaultCPUAccounting=yes
DefaultMemoryAccounting=yes
DefaultIOAccounting=yes

Znovu načtěte pomocí sudo systemctl daemon-reexec. Po restartu ověřte, které řadiče jsou k dispozici:

cat /sys/fs/cgroup/cgroup.controllers

Měli byste vidět cpu, memory, io, a pids uvedené. Tyto řadiče nejsou ve výchozím nastavení povoleny pro podřízené cgroups. Chcete-li je aktivovat, zapište do kontrolního souboru kořenového podstromu:

echo "+cpu +memory +io" | sudo tee /sys/fs/cgroup/cgroup.subtree_control

Pro podrobný přehled o tom, jak se v2 vnitřně liší od v1, je nejlepší zdroj přednáška Michaela Kerriska na NDC TechTown:

Jak systemd organizuje cgroups

systemd vytvoří cgroup pro každou službu, kterou spustí, pojmenovanou podle jednotky. nginx.service získává /sys/fs/cgroup/system.slice/nginx.service/, a každý proces, který spustí, se nachází uvnitř této cgroup. Tři typy jednotek se přímo mapují na hierarchii:

Čtyři výchozí segmenty jsou dodávány v základním nastavení: -.slice (root), system.slice, user.slicea machine.slice. Jakékoli omezení aplikované na segment se automaticky vztahuje na všechny služby v něm.

Jedno pravidlo verze 2, které stojí za zapamatování: procesy mohou existovat pouze v listových uzlech. Cgroup s podřízenými cgroupy nemůže přímo hostovat procesy, proto systemd nikdy neumisťuje služby do trunk slice.

Omezení vždy nastavujte prostřednictvím systemd, místo abyste zapisovali přímo do /sys/fs/cgroup/ . Ruční zápisy se po restartu neuchovají a jsou v rozporu s výhradním vlastnictvím hierarchie systémem systemd. Pro systemctl set-property pro jednorázové změny a dočasné jednotky (systemctl edit nginx.service) pro trvalé změny.

Omezení CPU

cgroups v2 nabízí dvě možnosti řízení CPU: pevný limit (cpu.max, dostupný jako CPUQuota v systemd) a proporcionální váhu (cpu.weight / CPUWeight).

CPUQuota je absolutní strop. CPUQuota=50% umožňuje polovinu jádra; CPUQuota=200% umožňuje čas odpovídající dvěma plným jádrům. Služba je omezena, pokud se pokusí jít výše, bez ohledu na to, jak málo je vytížena zbylá část CPU.

CPUWeight má význam pouze v případě soupeření o zdroje. Rozsah je 1 až 10 000, výchozí hodnota je 100. Tři služby s váhami 150, 100 a 50 obdrží přibližně 50 %, 33 % a 17 % času procesoru, pokud o něj všechny žádají najednou. Pokud je CPU jinak nečinné, váhy nic neomezují.

U úloh citlivých na latenci přiřaďte procesy ke konkrétním jádrům pomocí AllowedCPUs=. Tím se sníží přepínání kontextu a udrží se cache na jádru aktivní:

[Service]
CPUQuota=200%
CPUWeight=150
AllowedCPUs=0-3

Použijte pevnou kvótu, pokud potřebujete předvídatelné náklady (fakturace pro více nájemců, izolace hlučných sousedů). Použijte váhy, pokud chcete maximální využití hardwaru a potřebujete pouze pořadí priorit během špiček.

Omezení paměti s cgroups v2

Paměť má dvě úrovně: memory.high (měkké, omezování) a memory.max (tvrdý, OOM). Pro informace o swapu, uvolňování stránek a jádrovém OOM killeru si přečtěte náš doprovodný příspěvek o správě paměti v Linuxu.

Nastavte memory.high přibližně o 10 až 20 % níže memory.max. Jádro začne uvolňovat stránky a omezovat alokace, jakmile memory.high , což obvykle umožní zotavení pracovního zatížení před spuštěním OOM killera. Pokud využití dosáhne memory.max, jádro ukončí procesy v cgroup.

Typická konfigurace:

[Service]
MemoryHigh=400M
MemoryMax=512M
MemorySwapMax=0

MemorySwapMax=0 zakazuje swap pro tuto cgroup. Stojí za to u pracovních zátěží citlivých na latenci (databáze, streamování v reálném čase), kde by swapové I/O výrazně zvýšilo latenci.

Pro skupiny pracovníků, kde by ponechání osiřelých sourozenců poškodilo sdílený stav, napište 1 do souboru memory.oom.group . Když je jeden proces ukončen kvůli nedostatku paměti (OOM), jádro ukončí všechny procesy v cgroup najednou.

Zkontrolujte memory.events , abyste zjistili, jak často byla služba omezena nebo ukončena z důvodu nedostatku paměti (OOM):

cat /sys/fs/cgroup/system.slice/nginx.service/memory.events

Hodnota high a oom_kill vám řeknou, zda jsou vaše limity nastaveny správně. Trvale nenulové hodnoty znamenají, že pracovní zátěž potřebuje více volného prostoru.

Limity I/O

Řadič I/O má stejnou dvourežimovou konstrukci: absolutní limity prostřednictvím io.max a proporcionální sdílení prostřednictvím io.weight.

Limity se vztahují na blokové zařízení, identifikované čísly major:minor. Najdete je pomocí lsblk -o NAME,MAJ:MIN. Typická konfigurace systemd:

[Service]
IOReadBandwidthMax=/dev/sda 50M
IOWriteBandwidthMax=/dev/sda 30M
IOReadIOPSMax=/dev/sda 1000
IOWriteIOPSMax=/dev/sda 500

io.weight funguje jako cpu.weight: rozsah 1 až 10 000, výchozí hodnota 100. Přiřazení hodnoty 500 službě pro zákazníky a 50 noční záloze zabrání tomu, aby záloha během špičky zaplnila disk, ale umožní jí využít plnou šířku pásma, když ji nic jiného nepotřebuje.

Limity I/O se uplatní pouze tehdy, když cílíte na správné zařízení. Jádro sleduje I/O podle blokového zařízení, takže limit na /dev/sda nemá žádný vliv na I/O směřující do /dev/nvme0n1. Na hostitelích s více disky nastavte limity pro každé zařízení.

Izolace více nájemců pomocí segmentů

Pro sdílená prostředí definujte segment pro každého nájemce. Vytvořte /etc/systemd/system/tenant-a.slice:

[Slice]
CPUQuota=200%
CPUWeight=150
MemoryHigh=3584M
MemoryMax=4096M
MemorySwapMax=0
IOReadBandwidthMax=/dev/sda 200M
TasksMax=512

TasksMax=512 caps omezuje celkový počet procesů a vláken, což zabraňuje tomu, aby fork bomb v jednom nájemci vyřadila hostitele z provozu. Umístěte služby nájemce do tohoto segmentu (prostřednictvím Slice=tenant-a.slice v jejich jednotkových souborech) a automaticky zdědí vše.

Tento vzor funguje také pro oddělení hlučných úloh na pozadí od služeb určených pro uživatele. Umístěte zálohy, rotaci logů a dávkové úlohy do background.slice s nízkým CPUWeight a io.weight hodnotami. Získají plné zdroje, když je systém nečinný, a ustoupí stranou, když dorazí produkční provoz.

U runtime kontejnerů, jako jsou Docker a Podman, přidejte Delegate=yes do jejich souborů jednotek systemd. To jim umožní spravovat vlastní podskupiny cgroups bez oprávnění root a limity nastavené na nadřazeném segmentu se stále vztahují na vše pod ním.

Monitorování pomocí systemd-cgtop a PSI

Pro živý přehled ve stylu top o CPU, paměti a I/O podle cgroup spusťte:

systemd-cgtop

Pro statickou hierarchii a informace o tom, které procesy se kde nacházejí, použijte systemd-cgls.

Nejužitečnější funkcí v2 pro monitorování produkčního prostředí je Pressure Stall Information (PSI). PSI hlásí procento času, po které byly úkoly v cgroupu zablokovány čekáním na zdroj, a to ve třech souborech pro každou cgroup:

cat /sys/fs/cgroup/tenant-a.slice/cpu.pressure
cat /sys/fs/cgroup/tenant-a.slice/memory.pressure
cat /sys/fs/cgroup/tenant-a.slice/io.pressure

CPU s 100% využitím a 0% tlakem je v pořádku. Každý úkol, který chce CPU, ho dostává. Stejné CPU s 80% využitím, ale 30% tlakem znamená, že úkoly čekají ve frontě na běh. Upozorňujte na PSI, ne na využití: zachytí to konflikty, které metriky využití zcela opomíjejí.

Upravujte limity za běhu bez restartování:

sudo systemctl set-property tenant-a.slice MemoryMax=6144M

Změna se uplatní okamžitě a přetrvává i po restartu. V kombinaci s upozorněními založenými na PSI vám to umožní reagovat na změny zatížení dříve, než se promění v OOM kills nebo nekontrolovatelnou latenci.

Pokud provozujete vysoce husté multi-tenantní pracovní zátěže a potřebujete hostitele s dostatečnou rezervou pro čisté uplatnění těchto zásad, naše dedikované servery jsou pro to stvořené.