LimitNPROC prieš TasksMax: ką skaičiuoja OpenVPN unitas

Nepavykęs OpenVPN paleidimas dažnai ateina kaip skundo dėl resursų ir geranoriško pasiūlymo padidinti kokią nors ribą derinys, o pasiūlymas padeda tik maždaug pusėje atvejų. Už šių nepavykimų slypi du nesusiję skaitikliai. Vienas yra branduolio riba, kiek užduočių priklauso realiam naudotojo ID, ir ji paveldima vykdant procesą. Kitas yra cgroup biudžetas, kurį paslaugų tvarkyklė taiko unitui ir viskam, ką jis išsišakoja. Perskaityti kiekvieno efektyviąją reikšmę tam unito, kuris iš tikrųjų veikia, kainuoja mažiau nei spėjimas.

Du skaitikliai, du klausimai

LimitNPROC yra RLIMIT_NPROC po systemd vardu, o jo apskaitos vienetas yra tikrasis naudotojo ID. Kiekvienas procesas, kurį tas naudotojas valdo, skaičiuojamas į tą pačią sumą, įskaitant darbą, kurį pradėjo kiti unitai, prisijungimo sesija ar planuoklės užduotis. Todėl ši riba nėra kiekvienos paslaugos lubos, net kai ji nustatyta paslaugos unito viduje, o paslauga, kuri kiekvienam klientui išsišakoja pagalbininką, konkuruoja su viskuo kitu, kas veikia su ta paskyra. Užimta cron užduotis po tuo pačiu naudotoju gali pastumti VPN unitą už linijos, kurios jis pats niekada nekirto.

TasksMax turi kitą savininką: pids valdiklį unito cgroup, kuris skaičiuoja užduotis, o ne procesus. Gijos yra užduotys, todėl iš pažiūros vienagijis, bet darbuotojų telkinį turintis demonas gali sunaudoti biudžetą, kuris iš pirmo žvilgsnio atrodo daug didesnis už jo procesų skaičių. EffectiveTasksMax praneša, ką cgroup hierarchija iš tikrųjų leidžia po to, kai tėviniai segmentai pasakė savo.

Kodėl root išimtis pakeičia atsakymą

Branduolys netaiko RLIMIT_NPROC procesui, kuris turi CAP_SYS_RESOURCE arba CAP_SYS_ADMIN, todėl unitas, veikiantis kaip root neatsisakydamas privilegijų, praktiškai nėra ribojamas šiuo nustatymu. Ši vienintelė išimtis paaiškina prieštaringus patarimus, kuriuos žmonės keičiasi: LimitNPROC padidinimas sutaiso diegimą, kuris atsisakė privilegijų, ir visiškai nieko nepadaro tam, kuris liko privilegijuotas. Prieš priskirdami šiam nustatymui nuopelną ar kaltę, patikrinkite User= ir ar demonas po paleidimo keičia tapatybę. Privilegijuotas unitas, kuris vėliau pereina prie neprivilegijuotos paskyros, perėjimo momentu vėl patenka po riba, todėl gedimo laiko juosta taip pat verta perskaityti.

Gedimo etapas dar labiau susiaurina. Atsisakymas ruošiant vykdymą, demono paties pranešta išsišakojimo klaida ir atmesta užduoties kūrimas cgroup viduje duoda skirtingas journal eilutes, ir tik į vieną jų atsako didesnis biudžetas.

Skaitykite efektyviąsias reikšmes, o ne apvalkalo

ulimit -u interaktyvaus apvalkalo aprašo tą apvalkalą. Jis neaprašo, ką paslaugų tvarkyklė perdavė demonui, ir nieko nesako apie cgroup apskaitą. Vietoj to užklauskite unitą, naudodami egzemplioriaus vardą, kuris egzistuoja pagrindiniame kompiuteryje, o ne pavyzdį iš vadovo.

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

Konteinerio viduje atsakymui reikia dar dviejų nuskaitymų, nes vidinė infinity reikšmė aprašo tik svečio vaizdą. Paklauskite pagrindinio kompiuterio savininko apie paties konteinerio pids lubas ir patvirtinkite, ar vidinė paslaugų tvarkyklė apskritai gali perduoti tą valdiklį. Įdėtasis unitas negali laikyti biudžeto, kurio jo tėvinis cgroup niekada nesuteikė.

Įvertinkite pataisos dydį ir įrodykite ją esant apkrovai

Skaičių rinkitės iš darbo krūvio, o ne iš klaidos teksto. Suskaičiuokite procesus, kuriuos demonas paleidžia kiekvienam prisijungusiam klientui ar kiekvienam pagalbininko iškvietimui, padauginkite iš lygiagretumo, kurį diegimas turi atlaikyti, pridėkite atsargą administracinėms sesijoms ir tada palyginkite šį skaičių su dviem efektyviosiomis reikšmėmis. Vietinis drop-in perrašymas išlaiko pakeitimą peržiūrimą ir išgyvena paketų naujinimus, o pateikto unito failo redagavimas paslepia pakeitimą, kol kitas naujinimas jį pakeis. Užrašykite aritmetiką šalia perrašymo, nes kitam žmogui, kuris ją padidins ar sumažins, reikia prielaidų, o ne galutinio skaičiaus.

Biudžeto pakeitimai taikomi vykdymo metu, todėl vien perrinkimas nepakeičia jau veikiančių procesų dydžio. Paleiskite unitą iš naujo per įprastą jo gyvavimo ciklą, priimkite sesijos pertraukimą ir dar kartą perskaitykite skaitiklius naujame egzemplioriuje.

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

Pataisą įrodo iš naujo paleistas unitas, kurio užduočių skaičius lieka žemiau abiejų lubų, kol jis neša numatytą apkrovą, kartu su journal, kuris tame pačiame etape nebepraneša apie užduočių ar išsišakojimo išsekimą. Išsaugokite prieš ir po skaičius kartu su pakeitimu, kad kitas tyrimas prasidėtų nuo matavimo, o ne nuo to paties patarimo. Jei skaičius vis dar pasiekia lubas, aritmetika buvo neteisinga, o ne riba atsitiktinai per maža, ir tą skirtumą verta žinoti prieš kitą paleidimą.