cgroups v2 erőforráskorlátozások a systemd-vel

A cgroups v2 a Linux kernelt egységesítő erőforrás-vezérlő keretrendszer. A széttagolt v1 hierarchiát egyetlen fával váltja fel, amely következetesen kezeli a CPU-t, a memóriát és az I/O-t, és alátámasztja a konténerek elszigeteltségét a Dockerben, a Kubernetesben és a systemd-ben. Ez a bejegyzés bemutatja, hogyan lehet engedélyezni a cgroups v2-t, hogyan lehet korlátokat beállítani a systemd segítségével, és hogyan lehet ezt alkalmazni valós, több bérlős tárhely-forgatókönyvekben.

A cgroups v2 engedélyezése

A modern disztribúciók alapértelmezés szerint a cgroups v2-vel kerülnek forgalomba: Ubuntu 21.10+, Debian 11+, Fedora 31+ és RHEL/Rocky 9+. A régebbi rendszerek hibrid hierarchiát futtathatnak, vagy továbbra is a v1-et használják alapértelmezésként. Ellenőrizze a következővel:

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

A cgroup2fs kimenete megerősíti, hogy a v2 aktív. tmpfs általában a v1-et jelenti.

Ha hibrid rendszert szeretne tisztán v2-re váltani, szerkessze a /etc/default/grub fájlt, és illessze be a következőket a GRUB_CMDLINE_LINUX_DEFAULT:

systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all

Ezután generálja újra a GRUB-ot, és indítsa újra a rendszert:

sudo update-grub
sudo reboot

Termelési környezetben futtassa a 5.2-es vagy újabb kernelt, hogy megkapja a v2-hez szükséges cgroup freezer-t, valamint a 244-es vagy újabb systemd-t a teljes cpuset delegációhoz. A Rocky Linux 8 és az RHEL 8 rendszereken előfordulhat, hogy kifejezetten engedélyeznie kell az elszámolást azáltal, hogy ezeket a sorokat hozzáadja a /etc/systemd/system.conf:

DefaultCPUAccounting=yes
DefaultMemoryAccounting=yes
DefaultIOAccounting=yes

Indítsa újra a sudo systemctl daemon-reexec. Az újraindítás után ellenőrizze, mely vezérlők állnak rendelkezésre:

cat /sys/fs/cgroup/cgroup.controllers

A következőket kell látnia cpu, memory, io, és pids listázva. Ezek a vezérlők alapértelmezés szerint nincsenek engedélyezve a gyermek cgroupok számára. Az aktiváláshoz írjon a gyökér alfa-fa vezérlőfájlba:

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

Ha alaposan meg szeretné ismerni, hogy a v2 belsőleg miben különbözik a v1-től, Michael Kerrisk NDC TechTown előadása a legjobb forrás:

Hogyan szervezi a systemd a cgroupokat

A systemd minden elindított szolgáltatáshoz létrehoz egy cgroupot, amelyet az egység után nevez el. nginx.service gets /sys/fs/cgroup/system.slice/nginx.service/, és minden általa indított folyamat abban a cgroupban fut. Három egységtípus kapcsolódik közvetlenül a hierarchiához:

Négy alapértelmezett szelet érkezik a csomagban: -.slice (root), system.slice, user.sliceés machine.slice. A szeletre alkalmazott bármely korlátozás automatikusan vonatkozik az abban található összes szolgáltatásra.

Egy v2-es szabály, amit érdemes megjegyezni: a folyamatok csak a leveles csomópontokban létezhetnek. Egy gyermek cgroupokkal rendelkező cgroup nem tud közvetlenül folyamatokat tárolni, ezért a systemd soha nem helyezi a szolgáltatásokat egy szelet törzsébe.

A korlátozásokat mindig a systemd-n keresztül állítsa be, ne pedig közvetlenül a /sys/fs/cgroup/ . A kézi írások nem maradnak meg az újraindítás után, és ütköznek a systemd kizárólagos tulajdonjogával a hierarchiában. Használja a systemctl set-property egyszeri változtatásokhoz és egységek beillesztéséhez (systemctl edit nginx.service) az állandó változtatásokhoz.

CPU-korlátozások

A cgroups v2 két CPU-vezérlőt biztosít: egy kemény korlátot (cpu.max, amely CPUQuota a systemd-ben) és egy arányos súlyozást (cpu.weight / CPUWeight).

CPUQuota az abszolút felső határ. CPUQuota=50% fél magot engedélyez; CPUQuota=200% két teljes magnyi időt engedélyez. A szolgáltatást korlátozzák, ha ennél magasabb értéket próbál elérni, függetlenül attól, hogy a CPU többi része mennyire tétlen.

CPUWeight csak versengés esetén számít. A tartomány 1 és 10 000 között van, az alapértelmezett érték 100. Három szolgáltatás, amelyek súlyozása 150, 100 és 50, nagyjából a CPU-idő 50%-át, 33%-át és 17%-át kapja meg, ha mind egyszerre igénylik azt. Ha a CPU egyébként tétlen, a súlyok nem korlátoznak semmit.

Késleltetésérzékeny terhelések esetén a folyamatokat konkrét magokhoz lehet rendelni a AllowedCPUs=. Ez csökkenti a kontextusváltást és melegen tartja az egyes magok cache-ét:

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

Használjon kemény kvótát, ha kiszámítható költségekre van szüksége (többbérlős számlázás, zajos szomszédok elszigetelése). Használjon súlyozást, ha maximális hardverkihasználtságot szeretne, és csak csúcsidőszakokban van szüksége prioritási sorrendre.

Memóriahatárok a cgroups v2-vel

A memóriának két szintje van: memory.high (soft, throttling) és memory.max (kemény, OOM). A swap, a page reclaim és a kernel OOM killer háttérinformációiért lásd a Linux memóriakezelésről szóló kísérő bejegyzésünket.

Állítsa be memory.high körülbelül 10–20%-kal alacsonyabbra memory.max. A kernel elkezdi visszanyerni az oldalakat és korlátozni az allokációkat, amint memory.high , ami általában lehetővé teszi a terhelés helyreállását, mielőtt az OOM-killer beindulna. Ha a használat eléri memory.maxértéket, a kernel leállítja a cgroup-ban lévő folyamatokat.

Egy tipikus konfiguráció:

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

MemorySwapMax=0 letiltja a swap-ot ehhez a cgroup-hoz. Érdemes megtenni késleltetésérzékeny munkaterhelések (adatbázisok, valós idejű streaming) esetén, ahol a swap I/O tönkretenné a végső késleltetést.

Olyan munkavállalói poolok esetében, ahol az árva testvérek hátrahagyása megrongálná a megosztott állapotot, írja be 1 a cgroup memory.oom.group fájlba. Amikor egy folyamatot OOM-megszüntetnek, a rendszermag a cgroup összes folyamatát egyszerre szünteti meg.

Ellenőrizze memory.events , hogy megnézze, milyen gyakran korlátozták vagy OOM-killingelték egy szolgáltatást:

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

A high és oom_kill számlálók jelzik, hogy a korlátok mérete megfelelő-e. A tartósan nullától eltérő értékek azt jelentik, hogy a munkaterhelésnek több szabad kapacitásra van szüksége.

I/O-korlátok

Az I/O-vezérlő ugyanazzal a két üzemmóddal rendelkezik: abszolút korlátozás io.max és arányos megosztás a io.weight.

A korlátozások blokkeszközönként érvényesek, major:minor számokkal azonosíthatók. Ezeket a lsblk -o NAME,MAJ:MIN. Egy tipikus systemd konfiguráció:

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

io.weight úgy működik, mint cpu.weight: tartomány 1-től 10 000-ig, alapértelmezett érték 100. Ha 500-at rendelünk egy ügyfélszolgálati szolgáltatáshoz és 50-et egy éjszakai biztonsági mentéshez, akkor a biztonsági mentés nem terheli túl a lemezt csúcsidőben, de teljes sávszélességet használhat, ha másnak nincs rá szüksége.

Az I/O-korlátozások csak akkor érvényesek, ha a megfelelő eszközt célozza meg. A kernel blokkeszközönként követi nyomon az I/O-t, így a /dev/sda nem hat a /dev/nvme0n1. Több lemezzel rendelkező gazdagépeken állítsa be a korlátokat eszközönként.

Többbérlős elszigetelés szeletekkel

Megosztott környezetek esetében határozzon meg egy szeletet bérlőnként. Hozzon létre /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 korlátozza a folyamatok és szálak teljes számát, ami megakadályozza, hogy egy bérlőnél bekövetkező fork bomb leállítsa a gazdagépet. Helyezze a bérlői szolgáltatásokat ebbe a szeletbe (az Slice=tenant-a.slice az egységfájljaikban), és azok automatikusan öröklik az összes beállítást.

Ez a minta a zajos háttérmunkák és a felhasználóknak szóló szolgáltatások elválasztására is alkalmas. Helyezze a biztonsági mentéseket, a naplóváltást és a kötegelt feladatokat egy background.slice alacsony CPUWeight és io.weight értékekkel rendelkező szeletbe. Teljes erőforrásokat kapnak, amikor a rendszer tétlen, és félreállnak, amikor megérkezik a termelési forgalom.

Docker és Podman konténer futtatókörnyezetek esetében adja hozzá Delegate=yes a systemd egységfájljaikhoz. Ez lehetővé teszi számukra, hogy root jogosultság nélkül kezeljék saját alcsoportjaikat, és a szülő szeletre beállított korlátok továbbra is érvényesek legyenek az alatta lévő összes elemre.

Felügyelet a systemd-cgtop és a PSI segítségével

A CPU, a memória és az I/O cgrouponkénti élő top-stílusú megtekintéséhez futtassa a következő parancsot:

systemd-cgtop

A statikus hierarchia és a folyamatok elhelyezkedésének megtekintéséhez használja a systemd-cgls.

A termelésfelügyelet szempontjából a v2 leghasznosabb funkciója a Pressure Stall Information (PSI). A PSI jelenti, hogy a cgroup-on belüli feladatok mennyi időt töltöttek erőforrásra várva, és ezt három fájlban jeleníti meg cgroup-onként:

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

A 100%-os kihasználtságú, 0%-os nyomású CPU egészséges. Minden feladat, amely CPU-t igényel, megkapja azt. Ugyanez a CPU 80%-os kihasználtság mellett 30%-os nyomással azt jelenti, hogy a feladatok sorban állnak a futási időre. A kihasználtság helyett a PSI-re figyeljen: ez észleli azokat a versengéseket, amelyeket a kihasználtsági mutatók teljesen kihagynak.

A korlátok élőben módosíthatók, újraindítás nélkül:

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

A változás azonnal hatályba lép, és újraindítás után is megmarad. A PSI-alapú riasztásokkal kombinálva ez lehetővé teszi, hogy reagáljon a terhelésváltozásokra, mielőtt azok OOM-kill-ekhez vagy elszabadult késleltetéshez vezetnének.

Ha nagy sűrűségű, több bérlős munkaterheléseket futtat, és olyan hostra van szüksége, amelynek elegendő kapacitása van ezeknek a szabályoknak a zökkenőmentes alkalmazásához, dedikált szervereink pontosan erre lettek kialakítva.