LimitNPROC va TasksMax: OpenVPN birligi nimani sanaydi

OpenVPN ishga tushishining muvaffaqiyatsizligi ko'pincha resurslar haqidagi shikoyat va cheklovni oshirish haqidagi yaxshi niyatli taklif bilan birga keladi, va bu taklif faqat taxminan yarmida ishlaydi. Bu muvaffaqiyatsizliklar ortida bir-biriga bog'liq bo'lmagan ikkita hisoblagich turadi. Biri haqiqiy foydalanuvchi ID'siga tegishli vazifalar soniga yadro cheklovi bo'lib, jarayon bajarilganda meros qilib olinadi. Ikkinchisi xizmat menejeri birlikka va u shoxlaydigan hamma narsaga qo'llaydigan cgroup byudjetidir. Har birining amaldagi qiymatini, haqiqatda ishlayotgan birlik uchun o'qish taxmindan arzonroq.

Ikki hisoblagich, ikki savol

LimitNPROC — systemd nomi ostidagi RLIMIT_NPROC, uning hisob birligi haqiqiy foydalanuvchi ID'si. Bu foydalanuvchiga tegishli har bir jarayon bir xil yig'indiga sanaladi, boshqa birliklar, kirish sessiyasi yoki rejalashtiruvchi vazifasi boshlagan ish ham qo'shiladi. Shuning uchun bu cheklov xizmat birligi ichida o'rnatilgan bo'lsa ham har bir xizmat uchun alohida shift emas, va har bir mijoz uchun yordamchi shoxlaydigan xizmat o'sha hisob ostida ishlaydigan boshqa hamma narsa bilan raqobatlashadi. Xuddi shu foydalanuvchi ostidagi band cron vazifasi VPN birligini u o'zi hech qachon kesib o'tmagan chiziqdan nariga surib yuborishi mumkin.

TasksMax boshqa egaga ega: birlik cgroup'i ustidagi pids boshqaruvchisi, u jarayonlarni emas, vazifalarni sanaydi. Iplar ham vazifadir, shuning uchun bir ipli ko'rinadigan, lekin ishchilar havzasiga ega daemon jarayonlari sonidan bir qarashda ancha katta ko'rinadigan byudjetni sarflashi mumkin. EffectiveTasksMax ota-ona bo'laklari o'z so'zini aytgandan keyin cgroup ierarxiyasi aslida nimaga ruxsat berishini bildiradi.

Nega root istisnosi javobni o'zgartiradi

Yadro CAP_SYS_RESOURCE yoki CAP_SYS_ADMIN tutgan jarayonga RLIMIT_NPROC ni qo'llamaydi, shuning uchun imtiyozlardan voz kechmasdan root sifatida ishlaydigan birlik bu sozlama bo'yicha amalda cheksizdir. Aynan shu yagona istisno odamlar almashadigan qarama-qarshi maslahatlarni tushuntiradi: LimitNPROC ni oshirish imtiyozlardan voz kechgan joylashtirishni tuzatadi va imtiyozli qolgan joylashtirish uchun hech narsa qilmaydi. Bu sozlamaga yaxshilik yoki ayb yozishdan oldin User= va daemon ishga tushgandan keyin o'z shaxsini o'zgartiradimi-yo'qmi, tekshiring. Imtiyozli birlik keyinchalik imtiyozsiz hisobga o'tsa, o'tish lahzasida yana cheklov ostiga tushadi, bu esa nosozlik vaqt chizig'ini ham o'qishga arziydigan qiladi.

Nosozlik bosqichi buni yanada toraytiradi. Bajarishga tayyorgarlik paytida rad etish, daemonning o'zi xabar bergan shoxlanish xatosi va cgroup ichida rad etilgan vazifa yaratish turli journal satrlarini beradi, va faqat bittasiga kattaroq byudjet javob beradi.

Amaldagi qiymatlarni o'qing, shellnikini emas

Interaktiv shellning ulimit -u o'sha shellni tavsiflaydi. U xizmat menejeri daemonga nima berganini tavsiflamaydi va cgroup hisobi haqida hech narsa aytmaydi. Buning o'rniga birlikdan so'rang, qo'llanmadagi misol emas, xostda mavjud nusxa nomidan foydalanib.

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

Konteyner ichida javob yana ikkita o'qishni talab qiladi, chunki infinity kabi ichki qiymat faqat mehmonning ko'rinishini tavsiflaydi. Xost egasidan konteynerning o'z pids shiftini so'rang va ichki xizmat menejeri bu boshqaruvchini umuman topshira oladimi, tasdiqlang. Ichma-ich joylashgan birlik ota-ona cgroup'i hech qachon bermagan byudjetni ushlab turolmaydi.

Tuzatish hajmini o'lchang va uni yuk ostida isbotlang

Sonni xato matnidan emas, ish yukidan tanlang. Daemon har bir ulangan mijoz yoki har bir yordamchi chaqiruvi uchun qancha jarayon boshlashini sanang, joylashtirish ko'tarishi kerak bo'lgan parallellikka ko'paytiring, ma'muriy sessiyalar uchun biroz zaxira qo'shing va keyin bu sonni ikkita amaldagi qiymat bilan solishtiring. Mahalliy drop-in qayta yozish o'zgarishni ko'rib chiqish mumkin bo'lgan holatda saqlaydi va paket yangilanishlaridan keyin ham saqlanib qoladi, holbuki jo'natilgan birlik faylini tahrirlash o'zgarishni keyingi yangilanish uni almashtirguncha yashiradi. Arifmetikani qayta yozish yoniga yozib qo'ying, chunki keyin uni oshiradigan yoki tushiradigan odamga yakuniy son emas, taxminlar kerak.

Byudjet o'zgarishlari bajarish paytida qo'llaniladi, shuning uchun faqat qayta yuklash allaqachon ishlab turgan jarayonlar hajmini o'zgartirmaydi. Birlikni odatdagi hayot tsikli orqali qayta ishga tushiring, sessiya uzilishini qabul qiling va hisoblagichlarni yangi nusxada qayta o'qing.

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

Tuzatishni isbotlaydigan narsa — mo'ljallangan yukni ko'tarib turganda vazifalar soni ikkala shiftdan ham past bo'lgan qayta ishga tushirilgan birlik, shuningdek o'sha bosqichda endi vazifa yoki shoxlanish tugagani haqida xabar bermaydigan journal. O'zgarish bilan birga oldingi va keyingi sonlarni saqlang, keyingi tekshiruv o'sha maslahatdan emas, o'lchovdan boshlansin. Agar son hali ham shiftga yetsa, arifmetika xato bo'lgan, cheklov tasodifan juda kichik emas, va bu farqni keyingi qayta ishga tushirishdan oldin bilish kerak.