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. Өзгөртүү менен кошо мурунку жана кийинки сандарды сактаңыз, кийинки иликтөө ошол кеңештен эмес, өлчөөдөн башталсын. Эгер сан дагы деле чекке жетсе, арифметика туура эмес болгон, чек кокустан өтө кичине эмес, жана бул айырманы кийинки кайра баштоодон мурун билүү керек.