Cum să limitezi utilizarea CPU și RAM a unui proces cu Cgroups pe Ubuntu

Pe Ubuntu, cea mai sigură metodă generală de a limita o sarcină de lucru cu grupuri de control este să permiteți sistemului systemd să își creeze și să își gestioneze grupul de control. Folosiți această systemd-runopțiune pentru o comandă pe care o porniți acum sau configurați un serviciu systemd atunci când limita trebuie să reziste repornirilor. Setați CPUQuota=un plafon fix pentru timpul CPU și alegeți între MemoryHigh=pentru presiune și MemoryMax=pentru o limită fixă ​​de memorie. Aceste limite se aplică unității și proceselor sale fiice împreună.

Un cgroup (control group - grup de control) este un mecanism al kernelului Linux care organizează procesele astfel încât sistemul să poată contabiliza și controla utilizarea resurselor. Systemd-ul din Ubuntu plasează deja serviciile în cgroup-uri, astfel încât majoritatea utilizatorilor nu trebuie să creeze manual directoare /sys/fs/cgroup. Exemplele de mai jos utilizează interfața de control al resurselor a systemd și ar trebui verificate în raport cu versiunea systemd instalată pe versiunea dvs. de Ubuntu.

Alegeți controlul care corespunde problemei

Pentru majoritatea mașinilor Ubuntu interactive, un domeniu de aplicare tranzitoriu este cea mai rapidă alegere reversibilă. Pentru un serviciu de producție, utilizați unitatea de serviciu astfel încât politica să fie documentată și restaurată la pornire. Folosiți fișiere cgroup directe numai atunci când gestionați în mod deliberat o ierarhie delegată sau construiți un flux de lucru container/runtime.

Verificați sistemul Ubuntu înainte de a seta limite

Mai întâi verificați dacă systemd este disponibil și dacă sistemul de fișiere cgroup este unified v2:

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

Un rezultat al cgroup2fscelei de-a doua comenzi indică sistemul de fișiere cgroup v2 unificat. Versiunile Ubuntu și sistemele personalizate pot diferi, așa că nu presupuneți că fiecare mașină are aceeași ierarhie sau caracteristici systemd. De asemenea, puteți inspecta versiunea curentă de systemd cu prima comandă. Dacă montarea cgroup nu este v2, unele proprietăți ale resurselor sau comportamentul controlerului pot diferi; consultați pagina de manual Ubuntu pentru versiunea instalată înainte de a copia o configurație.

Alegeți valorile după măsurarea volumului de lucru. Lăsați loc pentru restul sistemului și rețineți că limitele setate pentru un serviciu utilizator sunt, de asemenea, constrânse de orice limite pentru felia sa părinte. Un grup de control copil nu poate primi mai multe resurse decât permite un strămoș.

Limitează o comandă pe care urmează să o începi

Pentru o comandă din propria sesiune de utilizator, lansați-o într-un domeniu tranzitoriu cu systemd-run --user --scope. De exemplu:

systemd-run --user --scope --unit=worker-capped \
  -p CPUQuota=50% \
  -p MemoryHigh=700M \
  -p MemoryMax=900M \
  -- python3 /opt/worker.py

Înlocuiți comanda Python cu programul pe care trebuie de fapt să îl rulați. Acest exemplu oferă cgroup-ului o lățime de bandă maximă a CPU-ului echivalentă cu jumătate dintr-un CPU, începe gestionarea presiunii memoriei în jurul valorii de 700 MiB și setează un maxim de 900 MiB de memorie fizică. Valorile memoriei utilizează unitățile de bază 1024 ale systemd. O cotă de 100%reprezintă până la un CPU de timp; 200%poate utiliza până la două CPU-uri atunci când sunt disponibile. Nu înseamnă un procent din toate nucleele din computer.

Comanda rulează în prim-plan deoarece acesta este un domeniu de aplicare. Când se închide, unitatea tranzitorie dispare. Eliminați-o --usernumai dacă intenționați să utilizați managerul de sistem și aveți privilegiile necesare; pentru o unitate tranzitorie la nivel de sistem, rulați comanda cu sudoși utilizați opțiunile de comandă corespunzătoare. Setările de resurse pot fi respinse dacă managerul sau controlerul cgroup nu le acceptă.

Setați limite pentru un serviciu systemd persistent

Pentru un serviciu precum worker.service, creați un drop-in în loc să editați fișierul unității furnizorului. Rulați sudo systemctl edit worker.serviceși adăugați:

[Service]
CPUQuota=50%
MemoryHigh=700M
MemoryMax=900M

Salvați elementul drop-in, apoi reîncărcați definițiile unităților systemd și reporniți serviciul astfel încât procesul să înceapă conform politicii revizuite:

sudo systemctl daemon-reload
sudo systemctl restart worker.service

Folosiți un plafon de memorie precaut. Dacă serviciul nu poate recupera suficientă memorie sub MemoryMax, kernelul poate invoca defecțiunea out-of-memory killer din interiorul acelui cgroup. Aceasta poate termina unul sau mai multe procese din grupul de servicii și poate întrerupe lucrul. Un model mai sigur este adesea setarea MemoryHighla un nivel la care recuperarea și limitarea sunt acceptabile, apoi setarea MemoryMaxunei limite finale mai mari. Testați cu încărcări de vârf realiste înainte de a implementa limite stricte.

Verificați unitatea și observați-i comportamentul

Pentru domeniul de aplicare tranzitoriu, verificați starea acestuia folosind numele unității pe care l-ați furnizat:

systemctl --user status worker-capped.scope
systemd-cgtop

Pentru un serviciu de sistem, omiteți --usercomanda status. Vizualizarea statusului confirmă existența și funcționarea unității; systemd-cgtoparată utilizarea resurselor în timp real de către grupul de control. Pentru a inspecta proprietățile configurate, interogați direct unitatea, de exemplu:

systemctl --user show worker-capped.scope \
  -p CPUQuotaPerSecUSec -p MemoryHigh -p MemoryMax

Memoria raportată pentru un cgroup nu este neapărat aceeași cu cifra setată de rezidentul unui proces: aceasta ia în considerare memoria încărcată grupului și poate include descendenții sarcinii de lucru. Tratați monitorizarea ca o dovadă a modului în care se comportă această sarcină de lucru în timp, nu ca un singur număr de optimizat orbește.

Ce se întâmplă dacă procesul este deja în desfășurare?

systemd-runpornește o comandă nouă în interiorul unei unități noi; nu preia un PID existent arbitrar și nu îl mută în acel domeniu de aplicare. Dacă procesul aparține unui serviciu systemd, aplică setările acelui serviciu cu un drop-in sau, pentru o modificare temporară, utilizează sudo systemctl set-property --runtime worker.service CPUQuota=50% MemoryHigh=700M MemoryMax=900M. --runtimeFormularul este temporar și nu înlocuiește o configurație de serviciu persistentă.

Dacă procesul este un program obișnuit în sesiunea desktop, metoda simplă și sigură este de obicei oprirea lui și relansarea lui sub systemd-run. Aplicarea unei proprietăți unei secțiuni mai largi, cum ar fi întreaga secțiune de utilizator, poate afecta multe aplicații fără legătură. Mutarea unui proces prin scrierea PID-ului său într-un fișier cgroup necesită controlul ierarhiei delegate relevante și trebuie să respecte regulile de plasare a proceselor cgroup v2; nu scrieți în directoarele gestionate de systemd prin presupunere.

Cum să alegi o politică de procesor și memorie

• Aveți nevoie de un plafon fix pentru CPU? Alegeți CPUQuota=. Valorile mai mici reduc consumul maxim de CPU, dar pot încetini finalizarea și pot crește timpul de așteptare.
• Aveți nevoie doar de o prioritate mai mică? Luați în considerare CPUWeight=mai degrabă decât o cotă. Ponderarea împarte CPU-ul relativ în competiție; nu rezervă un procent fix și nu împiedică utilizarea CPU-ului inactiv.
• Aveți nevoie de presiune asupra memoriei fără o oprire bruscă imediată? Setați MemoryHigh=-o ca prag principal de presiune și observați comportamentul de latență și recuperare.
• Aveți nevoie de o limită finală de izolare? Adăugați-o MemoryMax=cu suficient spațiu liber pentru vârfuri normale. Fiți pregătiți pentru comportamentul OOM atunci când limita nu poate fi respectată.
• Folosești deja un container? Preferi semnalizatoarele CPU și memorie acceptate de managerul de containere, care configurează grupurile de control pentru containerul respectiv și se potrivesc ciclului său de viață.

Nu există o limită ideală unică pentru fiecare sarcină de lucru. O lucrare în lot pe desktop poate tolera o cotă redusă și o capacitate de memorie moderată; un serviciu sensibil la latență poate necesita mai mult spațiu liber pentru CPU și o capacitate mai mare MemoryHighpentru a evita pauzele legate de recuperare. Începeți conservator, monitorizați unitatea în timpul unui vârf reprezentativ și ajustați câte o setare pe rând.

Referințe

• Documentația Ubuntu: grupuri de control și controlul resurselor systemd
• Pagina de manual Ubuntu: systemd-run
• Pagina de manual Ubuntu: systemd.resource-control
• Documentația kernelului Linux: Grup de control v2