omezení prostředků cgroups v2 pomocí systemd

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é.