cgroups v2 ressursipiirangud koos systemd-ga

cgroups v2 on Linuxi tuuma ühtne ressursside kontrolli raamistik. See asendab killustatud v1 hierarhia ühe puuga, mis haldab CPU-d, mälu ja I/O-d järjepidevalt ning toetab konteinerite eraldatust Dockeris, Kubernetes ja systemd-s. See postitus käsitleb, kuidas cgroups v2-d aktiveerida, piiranguid systemd kaudu seadistada ja seda rakendada reaalsetes mitme kasutajaga hosting-stsenaariumites.

Cgroups v2 aktiveerimine

Kaasaegsetes distributsioonides on cgroups v2 vaikimisi aktiveeritud: Ubuntu 21.10+, Debian 11+, Fedora 31+ ja RHEL/Rocky 9+. Vanemad süsteemid võivad kasutada hübriidhierarhiat või olla vaikimisi seadistatud versioonile v1. Kontrollige järgmiselt:

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

Väljund cgroup2fs kinnitab, et v2 on aktiivne. tmpfs tähendab tavaliselt v1.

Hübriidsüsteemi puhtale v2-le üleminekuks redigeerige /etc/default/grub ja lisage järgmine tekst faili GRUB_CMDLINE_LINUX_DEFAULT:

systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all

Seejärel genereerige GRUB uuesti ja taaskäivitage süsteem:

sudo update-grub
sudo reboot

Tootmiskeskkonnas kasutage tuuma 5.2 või uuemat, et saada v2 jaoks cgroup freezer, ning systemd 244+ täieliku cpuset delegatsiooni. Rocky Linux 8 ja RHEL 8 puhul võib olla vaja ka arvestust selgesõnaliselt lubada, lisades need read faili /etc/systemd/system.conf:

DefaultCPUAccounting=yes
DefaultMemoryAccounting=yes
DefaultIOAccounting=yes

Laadige uuesti sudo systemctl daemon-reexec. Pärast taaskäivitamist kontrollige, millised kontrollerid on saadaval:

cat /sys/fs/cgroup/cgroup.controllers

Peaksite nägema cpu, memory, ioja pids loetletud. Need kontrollerid ei ole vaikimisi lubatud alam-cgroupide jaoks. Nende aktiveerimiseks kirjutage juur-alamkataloogi kontrollifaili:

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

Põhjaliku ülevaate saamiseks sellest, kuidas v2 sisemiselt v1-st erineb, on Michael Kerriski NDC TechTowni ettekande parim allikas:

Kuidas systemd korraldab cgruppe

systemd loob iga käivitatava teenuse jaoks cgroupi, mis nimetatakse ühiku järgi. nginx.service saab /sys/fs/cgroup/system.slice/nginx.service/, ja iga protsess, mille ta käivitab, asub selles cgroupis. Kolm üksuse tüüpi on hierarhiaga otseselt seotud:

Nelja vaikimisi lõiku on kohe kasutusvalmis: -.slice (root), system.slice, user.sliceja machine.slice. Iga lõigule kehtestatud piirang kehtib automaatselt ka kõikidele selles olevatele teenustele.

Üks v2 reegel, mida tasub meeles pidada: protsessid võivad asuda ainult lehe sõlmedes. Cgroup, millel on alam-cgroupid, ei saa protsesse otse majutada, mistõttu systemd ei paiguta teenuseid kunagi viilu tüvesse.

Määrake piirangud alati systemd kaudu, mitte kirjutades otse /sys/fs/cgroup/ otse. Käsitsi kirjutamine ei säili taaskäivituste järel ja on vastuolus systemd-i ainuõigusega hierarhia üle. Kasutage systemctl set-property ühekordseteks muudatusteks ja unit drop-in'ideks (systemctl edit nginx.service) püsivateks muudatusteks.

CPU piirangud

cgroups v2 pakub kahte CPU-kontrolli: kõva piirang (cpu.max, mis on esitatud CPUQuota systemd-s) ja proportsionaalne kaal (cpu.weight / CPUWeight).

CPUQuota on absoluutne ülempiir. CPUQuota=50% lubab pool tuuma; CPUQuota=200% lubab kahe täis tuuma jagu aega. Teenust piiratakse, kui see üritab üle minna, hoolimata sellest, kui vähe on ülejäänud CPU-l koormust.

CPUWeight on oluline ainult konkurentsi korral. Vahemik on 1 kuni 10 000, vaikimisi 100. Kolm teenust kaaludega 150, 100 ja 50 saavad ligikaudu 50%, 33% ja 17% protsessori ajast, kui nad kõik seda korraga tahavad. Kui CPU on muul ajal vaba, ei piira kaalud midagi.

Viivitusele tundlike töökoormuste puhul kinnita protsessid kindlatele tuumadele käsuga AllowedCPUs=. See vähendab konteksti vahetamist ja hoiab tuuma-põhise vahemälu aktiivsena:

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

Kasutage kindlat kvooti, kui vajate prognoositavaid kulusid (mitme kasutaja arveldamine, mürakaaslaste isoleerimine). Kasutage kaalukoefitsiente, kui soovite maksimaalset riistvara kasutamist ja vajate prioriteetide järjestamist vaid koormuse tipphetkedel.

Mälupiirangud cgroups v2-ga

Mälul on kaks taset: memory.high (pehme, piiramine) ja memory.max (kõva, OOM). Swap-i, lehekülgede taaskasutamise ja tuuma OOM-killer'i taustteabe saamiseks vaadake meie kaasnevat postitust Linuxi mäluhalduse kohta.

Seadke memory.high ligikaudu 10–20% alla memory.max. Tuum hakkab lehti tagasi võtma ja eraldamisi piirama, kui memory.high piir ületatakse, mis tavaliselt võimaldab töökoormusel taastuda enne OOM-killer'i käivitumist. Kui kasutamine jõuab memory.max, tapab tuum protsesse cgroupis.

Tüüpiline konfiguratsioon:

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

MemorySwapMax=0 keelab selle cgrupi jaoks vahetusmälut. Tasub teha latentsusele tundlike töökoormuste puhul (andmebaasid, reaalajas voogedastus), kus vahetusmälut sisend-väljund võib latentsust oluliselt halvendada.

Töötajate rühmade puhul, kus orvuks jäänud vendade maha jätmine rikuks jagatud seisundit, kirjutage 1 cgrupi memory.oom.group faili. Kui üks protsess tapetakse OOM-i tõttu, tapab tuum kõik cgrupi protsessid korraga.

Vaadake memory.events , et näha, kui tihti teenust on piiratud või OOM-tapetud:

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

The high ja oom_kill näitavad, kas teie piirangud on õigesti määratud. Püsivad nullist erinevad väärtused tähendavad, et töökoormus vajab rohkem vaba ruumi.

I/O piirangud

I/O-kontrolleril on sama kahe režiimiga disain: absoluutsed piirangud io.max ja proportsionaalne jagamine kaudu io.weight.

Piirangud kehtivad iga plokiseadme kohta, mida identifitseeritakse major:minor numbritega. Leidke need käsuga lsblk -o NAME,MAJ:MIN. Tüüpiline systemd konfiguratsioon:

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

io.weight töötab järgmiselt cpu.weight: vahemik 1 kuni 10 000, vaikimisi 100. Kui määrata kliendile suunatud teenusele 500 ja öisele varundusele 50, hoiab see ära, et varundus tipptundidel ketta üle koormaks, kuid laseb tal kasutada täielikku ribalaiust, kui midagi muud seda ei vaja.

I/O piirangud kehtivad ainult siis, kui suunate need õigele seadmele. Tuum jälgib I/O-d plokkseadme kaupa, seega piirang /dev/sda ei mõjuta I/O-d, mis läheb /dev/nvme0n1. Mitme kettaga hostidel seadke piirangud seadme kaupa.

Mitme kasutaja isolatsioon viiludega

Jagatud keskkondade puhul määrake iga rentija jaoks oma segment. Looge /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 piirab protsesside ja niitide koguarvu, mis takistab ühe kasutaja fork-pommi põhjustatud serveri kokkukukkumist. Paigutage kasutaja teenused sellesse lõiku (oma Slice=tenant-a.slice nende üksusfailide kaudu) ja need pärivad kõik automaatselt.

See mudel sobib ka müraka taustatöö eraldamiseks kasutajale suunatud teenustest. Paigutage varukoopiad, logifailide vahetus ja kogumitööd background.slice madala CPUWeight ja io.weight väärtustega. Need saavad täielikud ressursid, kui süsteem on ooterežiimis, ja astuvad kõrvale, kui saabub tootmisliiklus.

Docker ja Podman sarnaste konteinerite käitamisajade puhul lisage Delegate=yes nende systemd-üksusfailidesse. See võimaldab neil hallata oma alam-cgruppe ilma root-õigusteta ning vanemale lõigule seatud piirangud kehtivad endiselt kõigile allpool olevatele.

Jälgimine süsteemiga systemd-cgtop ja PSI

Cgroupi kohta CPU, mälu ja I/O reaalajas top-stiilis ülevaate saamiseks käivitage:

systemd-cgtop

Staatilise hierarhia ja protsesside asukoha vaatamiseks kasutage systemd-cgls.

Kõige kasulikum v2 funktsioon tootmise seireks on Pressure Stall Information (PSI). PSI näitab protsenti ajast, mil cgrupi ülesanded olid ressursi ootamisel seisma jäänud, ja see on esitatud kolmes failis iga cgrupi kohta:

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

100% kasutamisega ja 0% survega CPU on terve. Iga ülesanne, mis vajab CPU-d, saab seda. Sama CPU 80% kasutamisega, kuid 30% survega tähendab, et ülesanded ootavad järjekorras oma käivitamist. Hoiatage PSI, mitte kasutamise kohta: see tabab konkurentsi, mida kasutamise näitajad täielikult mööda lasevad.

Piirangute kohandamine reaalajas ilma midagi taaskäivitamata:

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

Muudatus rakendub kohe ja püsib ka pärast taaskäivitamist. Koos PSI-põhiste hoiatustega võimaldab see reageerida koormuse muutustele enne, kui need muutuvad OOM-tapmisteks või kontrollimatuks viivituseks.

Kui te kasutate suure tihedusega mitme kasutajaga töökoormusi ja vajate hosti, millel on piisavalt vaba ressurssi nende poliitikate puhtaks rakendamiseks, on meie pühendatud serverid just selleks loodud.