Serverul meu de acasă rulează hardware vechi (Core i5-3450, software RAID1 pe discuri SATA) și deseori are probleme când rulez lucruri cu performanță intensivă, cum ar fi o lucrare de compilare, pe lângă serviciile „normale” care rulează în fundal (DNS, Web, DHCP, e-mail etc. etc.)
Recent, aproape că mi-am distrus sistemul când un job de compilare a ajuns la aproape 100% CPU și, în consecință, așteptarea I/O a crescut vertiginos și practic niciun alt proces nu a mai putut obține resurse gratuite.
Am citit despre cgroup2 și am încercat. Setați opțiunea grub systemd.unified_cgroup_hierarchy=1 și repornit. Am creat un nou cgroup, am activat I/O și controlerul CPU și am putut să arunc PID-ul compilatorului meu în cgroup.procs și am putut să-l pun cu succes în „background” rulând cu doar 5% CPU și fără a interfera cu restul sistemul. Lucrarea de compilare a durat aproape o eternitate (câteva zile), dar nu m-a deranjat. Cu toate acestea, de mai multe ori pe zi, brusc setarea mea cpu.max a dispărut și sistemul a ieșit din nou din echilibru.După ce am citit mai multe despre cgroup și systemd, cred că este pentru că m-am amestecat cu controalele systemd și, practic, systemd părea să resetați setările mele personalizate înapoi la valorile implicite (cpu.max == 'max 1000000'), care apoi a început să-mi distrugă sistemul.
Așa că am citit despre cum să o fac corect.
Mai întâi am pus Delegat=adevarat pentru a mea [email protected] fișier și repornit.
Apoi am încercat să deschid un nou „job” alergând systemd-run --user CPUQuota=5% stress-ng --matrix 0 -t 10m care a funcționat cu succes, adică utilizarea procesorului per proces a fost limitată la 5%/4 per fir de stres!
Pot vedea un director nou mai jos /sys/fs/cgroup/user.slice/user-1000.slice/[email protected] care conține setarea mea:
cat /sys/fs/cgroup/user.slice/user-1000.slice/[email protected]/run-raef937da699b484b80f1bf03bc049f7a.service/cpu.max
5000 100000
și cgroups.procs conține PID-ul corespunzător al stress-ng. Succes!
Acum s-ar putea să vreau să schimb acea setare. Fie pentru că este de asemenea scăzut sau din ce alt motiv. Pot să scriu o altă valoare direct în cpu.max? Sau ar trebui să folosesc un instrument de comandă systemd pentru a face asta? (Care?)
Cealaltă problemă a mea este: dacă nu știu în prealabil că o comandă pe care o voi rula ar putea avea un impact negativ asupra performanței sistemului meu, cum pot să o constrâng mai târziu fără a o ucide și a rula din nou folosind systemd- alerga?
Să presupunem că doar rulez „stress-ng” în shell-ul meu (fără systemd-run), pot vedea că PID este membru al sesiunii normale cgroup
cat /proc/742779/cgroup
0::/user.slice/user-1000.slice/session-2232.scope
Dar acea cgroup este gestionat de systemd, așa că nu trebuie (și nici nu pot cu drepturi normale de utilizator) să scriu în structurile sale cpu.max, io.max etc., corect?
Ce modalități de limitare am pentru procesele care rulează deja în fișierul sesiune-xxx.scop în loc de sub mea [email protected]? Pot „prelua proprietatea” asupra PID 742779 și îl transfer cumva în contul meu [email protected] sesiune?
Știu că există cgcreate, cgclassify, etc. dar acestea sunt doar cgroup1, corect? (Măcar ei îmi dau cgcreate: inițializarea libcgroup a eșuat: Cgroup nu este montat ca urmare.)
