LimitNPROC және TasksMax: OpenVPN бірлігі нені санайды

OpenVPN іске қосылуының сәтсіздігі көбіне ресурстар туралы шағым және шекті көтеру туралы ниеті жақсы ұсыныспен бірге келеді, ал бұл ұсыныс шамамен жарты жағдайда ғана істейді. Бұл сәтсіздіктердің артында өзара байланысы жоқ екі санауыш тұр. Біреуі нақты пайдаланушы ID-іне тиесілі тапсырмалар санына ядроның қоятын шегі, ол процесті іске қосқанда мұраланады. Екіншісі қызмет менеджері бірлікке және ол тармақтайтын барлық нәрсеге қолданатын cgroup бюджеті. Әрқайсысының нақты мәнін, шынымен жұмыс істеп тұрған бірлік үшін оқу болжамнан арзан.

Екі санауыш, екі сұрақ

LimitNPROC — systemd атауы астындағы RLIMIT_NPROC, ал оның есепке алу бірлігі нақты пайдаланушы ID-і. Осы пайдаланушыға тиесілі әрбір процесс бірдей жиынтыққа саналады, оның ішінде басқа бірліктер, кіру сессиясы немесе жоспарлаушы тапсырмасы бастаған жұмыс та бар. Сондықтан бұл шек қызмет бірлігінің ішінде қойылса да, қызмет сайынғы шек емес, және әрбір клиент үшін көмекші тармақтайтын қызмет сол есептік жазба астында жұмыс істейтін қалған барлық нәрсемен бәсекелеседі. Сол пайдаланушы астындағы бос емес cron тапсырмасы VPN бірлігін ол өзі ешқашан кесіп өтпеген сызықтан әрі итеруі мүмкін.

TasksMax басқа иесі бар: бірліктің cgroup-ындағы pids контроллері, ол процестерді емес, тапсырмаларды санайды. Ағындар тапсырмалар, сондықтан бір ағынды болып көрінетін, бірақ жұмысшылар пулы бар демон өз процестер санынан әлдеқайда үлкен көрінетін бюджетті жұмсауы мүмкін. EffectiveTasksMax ата-аналық слайстар өз сөзін айтқаннан кейін cgroup иерархиясы шын мәнінде неге рұқсат беретінін хабарлайды.

Неліктен root ерекшелігі жауапты өзгертеді

Ядро CAP_SYS_RESOURCE немесе CAP_SYS_ADMIN тасымалдайтын процеске RLIMIT_NPROC қолданбайды, сондықтан артықшылықтардан бас тартпай root ретінде жұмыс істейтін бірлік бұл параметр бойынша іс жүзінде шексіз. Осы жалғыз ерекшелік адамдар алмасатын қарама-қайсы кеңестерді түсіндіреді: LimitNPROC көтеру артықшылықтардан бас тартқан орналастыруды түзейді және артықшылығы сақталған орналастыруға мүлдем ештеңе істемейді. Бұл параметрге мақтау немесе кінә артпастан бұрын User= және демон іске қосылғаннан кейін өзінің сәйкестігін ауыстыра ма, соны тексеріңіз. Артықшылығы бар бірлік кейінірек артықшылығы жоқ есептік жазбаға ауысса, ауысу сәтінде қайтадан шек астына түседі, бұл сәтсіздіктің уақыт сызығын да оқуға тұрарлық етеді.

Сәтсіздік кезеңі оны одан әрі тарылтады. Орындауға дайындалу кезіндегі бас тарту, демонның өзі хабарлаған тармақтау қатесі және cgroup ішінде қабылданбаған тапсырма жасау әртүрлі journal жолдарын береді, және солардың тек біреуіне үлкенірек бюджет жауап береді.

Нақты мәндерді оқыңыз, shell-дікін емес

Интерактивті shell-дің ulimit -u сол shell-ді сипаттайды. Ол қызмет менеджерінің демонға не бергенін сипаттамайды және cgroup есебі туралы ештеңе айтпайды. Оның орнына бірліктен сұраңыз, нұсқаулықтағы мысалды емес, хостта бар дана атауын пайдаланыңыз.

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

Контейнердің ішінде жауапқа тағы екі оқу қажет, өйткені infinity ішкі мәні тек қонақтың көрінісін сипаттайды. Хост иесінен контейнердің өз pids шегін сұраңыз және ішкі қызмет менеджері бұл контроллерді мүлдем өкілеттік ете ала ма, соны растаңыз. Кірістірілген бірлік ата-аналық cgroup ешқашан бермеген бюджетті ұстай алмайды.

Түзетудің көлемін өлшеп, оны жүктеме астында дәлелдеңіз

Санды қате мәтінінен емес, жұмыс жүктемесінен таңдаңыз. Демон әрбір қосылған клиентке немесе әрбір көмекші шақыруға қанша процесс іске қосатынын санаңыз, орналастыру көтеруі тиіс параллельдікке көбейтіңіз, әкімшілік сессияларға аздап қор қосыңыз, содан кейін бұл санды екі нақты мәнмен салыстырыңыз. Жергілікті drop-in қайта жазу өзгерісті қарауға қолайлы етіп ұстайды және пакет жаңартуларынан кейін де сақталады, ал жеткізілген бірлік файлын өңдеу өзгерісті келесі жаңарту оны алмастырғанша жасырады. Арифметиканы қайта жазудың қасына жазыңыз, өйткені оны кейін көтеретін немесе төмендететін адамға түпкі сан емес, болжамдар керек.

Бюджет өзгерістері орындау кезінде қолданылады, сондықтан тек қайта жүктеу қазірдің өзінде жұмыс істеп тұрған процестердің өлшемін өзгертпейді. Бірлікті әдеттегі өмірлік циклі арқылы қайта іске қосыңыз, сессияның үзілуін қабылдаңыз және санауыштарды жаңа данада қайта оқыңыз.

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

Түзетуді дәлелдейтін нәрсе — тапсырмалар саны екі шектің де астында тұрып, көзделген жүктемені көтеріп тұрған қайта іске қосылған бірлік, сондай-ақ сол кезеңде тапсырмалар немесе тармақтау сарқылуы туралы енді хабарламайтын journal. Өзгеріспен бірге алдыңғы және кейінгі сандарды сақтаңыз, келесі тергеу сол кеңестен емес, өлшеуден басталсын. Егер сан әлі де шекке жетсе, арифметика қате болды, шек кездейсоқ тым кішкентай емес, және бұл айырмашылықты келесі қайта іске қосуға дейін білу керек.