LimitNPROC dhidi ya TasksMax: kile ambacho kitengo cha OpenVPN hukihesabu

Kuanzisha OpenVPN kushindikana mara nyingi huja kama malalamiko kuhusu rasilimali pamoja na pendekezo lenye nia njema la kuongeza kikomo, na pendekezo hilo hufanya kazi katika takriban nusu ya matukio. Nyuma ya kushindwa huko kuna vihesabu viwili visivyohusiana. Kimoja ni kikomo cha kernel juu ya idadi ya kazi zinazomilikiwa na kitambulisho halisi cha mtumiaji, na hurithiwa wakati mchakato unatekelezwa. Kingine ni bajeti ya cgroup ambayo meneja wa huduma huitumia kwa kitengo na kila kitu anachogawanya. Kusoma thamani halisi ya kila kimoja, kwa kitengo kinachofanya kazi kweli, hugharimu kidogo kuliko kukisia.

Vihesabu viwili, maswali mawili

LimitNPROC ni RLIMIT_NPROC chini ya jina la systemd, na kitengo chake cha uhasibu ni kitambulisho halisi cha mtumiaji. Kila mchakato unaomilikiwa na mtumiaji huyo huhesabiwa katika jumla moja, ikiwa ni pamoja na kazi zilizoanzishwa na vitengo vingine, kikao cha kuingia au kazi ya kipanga. Kwa hiyo kikomo hiki si kilele cha kila huduma hata kinapowekwa ndani ya kitengo cha huduma, na huduma inayogawanya msaidizi kwa kila mteja hushindana na kila kitu kingine kinachofanya kazi chini ya akaunti hiyo. Kazi ya cron yenye shughuli nyingi chini ya mtumiaji huyo huyo inaweza kusukuma kitengo cha VPN zaidi ya mstari ambacho hakikuwahi kuuvuka peke yake.

TasksMax ana mmiliki mwingine: kidhibiti cha pids kwenye cgroup ya kitengo, kinachohesabu kazi badala ya michakato. Nyuzi ni kazi, kwa hiyo daemon anayeonekana kuwa na uzi mmoja lakini ana kundi la wafanyakazi anaweza kutumia bajeti inayoonekana kwa jicho la kwanza kuwa kubwa zaidi kuliko idadi ya michakato yake. EffectiveTasksMax huripoti kile ambacho madaraja ya cgroup yanaruhusu kweli baada ya vipande vya wazazi kusema yao.

Kwa nini msamaha wa root hubadilisha jibu

Kernel haitumii RLIMIT_NPROC kwa mchakato ulio na CAP_SYS_RESOURCE au CAP_SYS_ADMIN, ndiyo sababu kitengo kinachofanya kazi kama root bila kuachana na mapendeleo hakiwekewi kikomo na mpangilio huo. Msamaha huu mmoja hufafanua ushauri pinzani ambao watu hubadilishana: kuongeza LimitNPROC hutengeneza usambazaji ulioachana na mapendeleo na haufanyi chochote kwa ule uliobaki na mapendeleo. Angalia User= na kama daemon hubadilisha utambulisho baada ya kuanza kabla ya kutoa sifa au lawama kwa mpangilio huo. Kitengo chenye mapendeleo kinachohamia baadaye kwenye akaunti isiyo na mapendeleo hurejea chini ya kikomo wakati wa kuhamia, jambo ambalo hufanya mfululizo wa matukio ya kushindwa ustahili kusomwa pia.

Hatua ya kushindwa hupunguza zaidi. Kukataliwa wakati wa maandalizi ya utekelezaji, hitilafu ya kugawanya inayoripotiwa na daemon mwenyewe, na uundaji wa kazi uliokataliwa ndani ya cgroup hutoa mistari tofauti ya journal, na ni mmoja tu wao hujibiwa na bajeti kubwa zaidi.

Soma thamani halisi, sio za shell

ulimit -u ya shell shirikishi hufafanua shell hiyo. Haifafanui kile meneja wa huduma alikabidhi kwa daemon, na haisemi chochote kuhusu uhasibu wa cgroup. Uliza kitengo badala yake, ukitumia jina la nakala lililopo kwenye mwenyeji na sio mfano kutoka kwenye mwongozo.

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

Ndani ya kontena jibu linahitaji usomaji mwingine mbili, kwa sababu thamani ya ndani ya infinity hufafanua tu mtazamo wa mgeni. Muulize mmiliki wa mwenyeji juu ya kilele cha pids cha kontena lenyewe, na thibitisha kama meneja wa huduma wa ndani anaweza kukabidhi kidhibiti hicho kabisa. Kitengo kilichopachikwa hakiwezi kushikilia bajeti ambayo cgroup ya mzazi wake haikuwahi kutoa.

Pima ukubwa wa marekebisho na uyathibitishe chini ya mzigo

Chagua nambari kutoka kwenye mzigo wa kazi na sio kutoka kwenye maandishi ya hitilafu. Hesabu michakato ambayo daemon huanzisha kwa kila mteja aliyounganishwa au kwa kila wito wa msaidizi, zidisha kwa usawa wa wakati unaotarajiwa kubebwa na usambazaji, ongeza ukingo kwa vikao vya utawala, kisha linganisha nambari hiyo na thamani mbili halisi. Ubadilishaji wa ndani wa aina ya drop-in huweka mabadiliko yakiwa yanaweza kukaguliwa na hustahimili masasisho ya vifurushi, wakati kuhariri faili ya kitengo iliyosafirishwa huficha mabadiliko hadi sasisho lijalo litakapobadilisha. Andika hesabu kando ya ubadilishaji, kwa sababu mtu ajaye atakayeiongeza au kuipunguza anahitaji dhana, sio nambari ya mwisho.

Mabadiliko ya bajeti hutumika wakati wa utekelezaji, kwa hiyo kupakia upya peke yake hakubadilishi ukubwa wa michakato inayofanya kazi tayari. Anzisha upya kitengo kupitia mzunguko wake wa kawaida wa maisha, kubali usumbufu wa kikao, na soma vihesabu tena kwenye nakala mpya.

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

Kinachothibitisha marekebisho ni kitengo kilichoanzishwa upya ambacho idadi ya kazi zake iko chini ya vilele vyote viwili wakati kinabeba mzigo uliokusudiwa, pamoja na journal ambayo hairipoti tena kumalizika kwa kazi au kugawanya katika hatua hiyo hiyo. Hifadhi nambari za kabla na baada pamoja na mabadiliko, ili uchunguzi ujao uanze kutoka kwa kipimo na sio kutoka kwa ushauri huo huo. Ikiwa idadi bado inafikia kilele, hesabu ilikuwa mbaya na sio kikomo kilichokuwa kidogo kwa bahati, na tofauti hiyo inafaa kujulikana kabla ya kuanzisha upya kunakofuata.