LimitNPROC eta TasksMax: zer zenbatzen du OpenVPN unitate batek

OpenVPN abiarazteak huts egitean, ohikoa da baliabideen inguruko kexa bat jasotzea, muga bat igotzeko asmo oneko iradokizun batekin batera, eta iradokizun horrek kasuen erdietan soilik funtzionatzen du. Hutsegite horien atzean erlaziorik gabeko bi kontagailu daude. Bata nukleoaren muga da, benetako erabiltzaile-ID batek dituen zeregin kopuruari buruzkoa, eta prozesua exekutatzean heredatzen da. Bestea cgroup aurrekontu bat da, zerbitzu-kudeatzaileak unitate bati eta honek adarkatzen duen guztiari aplikatzen diona. Bakoitzaren balio eraginkorra irakurtzea, benetan exekutatzen den unitatearentzat, uste bat baino merkeagoa da.

Bi kontagailu, bi galdera

LimitNPROC RLIMIT_NPROC da systemd izen baten pean, eta bere kontabilitate-unitatea benetako erabiltzaile-IDa da. Erabiltzaile horrek duen prozesu bakoitza guztizko beraren aurka zenbatzen da, beste unitate batzuek, saio-hasiera batek edo planifikatzailearen zeregin batek hasitako lana barne. Muga, beraz, ez da zerbitzu bakoitzeko sabaia, zerbitzu-unitate baten barruan ezarrita egon arren, eta bezero bakoitzeko laguntzaile bat adarkatzen duen zerbitzuak kontu horren pean exekutatzen den gainerako guztiarekin lehiatzen du. Erabiltzaile beraren pean dagoen cron zeregin lanpetu batek VPN unitate bat inoiz bakarrik gainditu ez zuen marra batetik harantz bultza dezake.

TasksMax beste jabe bat du: unitatearen cgrouparen pids kontrolagailua, zereginak zenbatzen dituena prozesuak baino. Hariak zereginak dira, beraz hari bakarreko itxura duen baina langile-multzo bat duen daemon batek bere prozesu kopurua baino askoz handiagoa dirudien aurrekontu bat kontsumi dezake. EffectiveTasksMax-ek cgroup hierarkiak benetan uzten duena jakinarazten du, guraso-sliceek beren esana esan ondoren.

Zergatik aldatzen du root salbuespenak erantzuna

Nukleoak ez die RLIMIT_NPROC aplikatzen CAP_SYS_RESOURCE edo CAP_SYS_ADMIN daramatzan prozesu bati, eta horregatik pribilegioak utzi gabe root gisa exekutatzen den unitate bat ez dago mugatuta ezarpen horren arabera. Salbuespen bakar honek azaltzen du jendeak trukatzen duen aholku kontraesankorra: LimitNPROC igotzeak pribilegioak utzi zituen inplementazio bat konpontzen du eta pribilegiatuta jarraitu zuenarentzat ez du ezer egiten. Egiaztatu User= eta daemonak abiarazi ondoren identitatea aldatzen duen ezarpen horri meritua edo errua eman aurretik. Geroago pribilegiorik gabeko kontu batera aldatzen den unitate pribilegiatu bat muga azpian geratzen da aldaketaren unean, eta horrek hutsegitearen denbora-lerroa ere irakurtzeko modukoa egiten du.

Hutsegitearen etapa horrek gehiago estutzen du. Exekuzio-prestaketan zehar uko egiteak, daemonak berak jakinarazitako adarkatze-erroreak eta cgroup baten barruan baztertutako zeregin-sorkuntzak journal lerro desberdinak sortzen dituzte, eta horietako bati bakarrik erantzuten dio aurrekontu handiago batek.

Irakurri balio eraginkorrak, oskolarenak ez

Oskol interaktibo baten ulimit -u oskol hori deskribatzen du. Ez du deskribatzen zerbitzu-kudeatzaileak daemonari eman ziona, eta ez du ezer esaten cgroup kontabilitateari buruz. Galdetu unitateari horren ordez, ostalarian existitzen den instantzia-izena erabiliz, gida bateko adibidea erabili beharrean.

systemctl show [email protected] -p User -p LimitNPROC -p TasksCurrent -p TasksMax -p EffectiveTasksMax
cat /proc/$(systemctl show -p MainPID --value [email protected])/limits | grep -i processes

Edukiontzi baten barruan erantzunak bi irakurketa gehiago behar ditu, infinity-ren barne-balioak gonbidatuaren ikuspegia baino ez baitu deskribatzen. Eskatu ostalariaren jabeari edukiontziaren beraren pids sabaia, eta egiaztatu barneko zerbitzu-kudeatzaileak kontrolagailu hori delegatu dezakeen. Unitate habiaratu batek ezin du gorde guraso cgroupak inoiz eman ez zion aurrekonturik.

Neurtu konponketaren tamaina eta frogatu kargapean

Aukeratu zenbaki bat karga-lanetik, ez errore-testutik. Zenbatu daemonak konektatutako bezero bakoitzeko edo laguntzaile-dei bakoitzeko abiarazten dituen prozesuak, biderkatu inplementazioak jasan behar duen konkortasunarekin, gehitu marjina bat administrazio-saioetarako, eta gero alderatu kopuru hori bi balio eraginkorrekin. Tokiko drop-in ordezkapen batek aldaketa berrikusgarri mantentzen du eta pakete-eguneratzeak gainditzen ditu, aldiz ontziratutako unitate-fitxategi bat editatzeak aldaketa ezkutatzen du hurrengo eguneratzeak ordezkatu arte. Idatzi aritmetika ordezkapenaren ondoan, hurrengo igoko edo jaitsiko duen pertsonak suposizioak behar baititu, ez azken zenbakia.

Aurrekontu-aldaketak exekuzioan aplikatzen dira, beraz berr kargatzeak bakarrik ez ditu birritan tamainatzen jada exekutatzen ari diren prozesuak. Berrabiarazi unitatea bere bizi-ziklo arruntaren bidez, saioaren etetea onartuz, eta irakurri kontagailuak berriro instantzia berrian.

sudo systemctl daemon-reload
sudo systemctl restart [email protected]
systemctl show [email protected] -p TasksCurrent -p EffectiveTasksMax
sudo journalctl -u [email protected] -b --no-pager | tail -n 20

Konponketa frogatzen duena berrabiarazitako unitate bat da, zeinaren zeregin-kopurua bi sabien azpitik geratzen baita aurreikusitako karga eramaten duen bitartean, gehi journal bat, jada etap berean zeregin edo adarkatze agorpenik jakinarazten ez duena. Gorde aurretik eta ondorengo zenbakiak aldaketarekin batera, hurrengo ikerketak neurketa batetik hasi dadin eta ez aholku beretik. Kopuruak oraindik sabaia iristen badu, aritmetika oker zegoen, ez muga kasualitatez txikiegia, eta aldea hori jakitea merezi du hurrengo berrabiarazpenaren aurretik.