LimitNPROC विरुद्ध TasksMax: एक OpenVPN युनिट काय मोजते

अयशस्वी OpenVPN स्टार्ट बऱ्याचदा संसाधनाची तक्रार आणि मर्यादा वाढवण्याचा सद्भावी सल्ला अशा स्वरूपात येतो, आणि तो सल्ला फक्त सुमारे अर्ध्या प्रकरणांमध्येच काम करतो। या अयशस्वीतेमागे दोन असंबंधित काउंटर आहेत। एक म्हणजे खऱ्या वापरकर्ता ID च्या मालकीच्या कार्यांच्या संख्येवरील कर्नेलची मर्यादा, आणि प्रक्रिया चालवताना ती वारशाने मिळते। दुसरे म्हणजे cgroup बजेट, जे सेवा व्यवस्थापक एका युनिटवर आणि त्यातून फोर्क होणाऱ्या प्रत्येक गोष्टीवर लागू करतो। प्रत्यक्षात चालणाऱ्या युनिटसाठी प्रत्येकाचे प्रभावी मूल्य वाचणे अंदाजापेक्षा कमी खर्चिक आहे।

दोन काउंटर, दोन प्रश्न

LimitNPROC हे systemd नावाखालील RLIMIT_NPROC आहे, आणि त्याचे हिशोबाचे एकक खरा वापरकर्ता ID आहे। त्या वापरकर्त्याच्या मालकीची प्रत्येक प्रक्रिया त्याच बेरजेत मोजली जाते, त्यात इतर युनिट, लॉगिन सत्र किंवा शेड्युलर जॉबने सुरू केलेले कामही समाविष्ट आहे। त्यामुळे ही मर्यादा सेवा युनिटच्या आत सेट केली असली तरी सेवेनिहाय मर्यादा नाही, आणि प्रत्येक क्लायंटसाठी सहाय्यक फोर्क करणारी सेवा त्या खात्याखाली चालणाऱ्या बाकी सर्वांशी स्पर्धा करते। त्याच वापरकर्त्याखालील व्यग्र क्रॉन जॉब VPN युनिटला तिने एकटीने कधीही ओलांडली नसलेल्या रेषेच्या पलीकडे ढकलू शकतो।

TasksMax चा मालक वेगळा आहे: युनिटच्या cgroup वरील pids नियंत्रक, जो प्रक्रियांऐवजी कार्ये मोजतो। थ्रेड कार्ये आहेत, त्यामुळे एका थ्रेडसारखे दिसणारे पण वर्कर पूल असलेले डीमॉन त्याच्या प्रक्रिया संख्येपेक्षा पहिल्या दृष्टीक्षेपात खूप मोठे दिसणारे बजेट वापरू शकते। EffectiveTasksMax पालक स्लाइसनी आपले म्हणणे सांगितल्यानंतर cgroup श्रेणी प्रत्यक्षात काय परवानगी देते ते सांगते।

root अपवाद उत्तर का बदलतो

कर्नेल CAP_SYS_RESOURCE किंवा CAP_SYS_ADMIN असलेल्या प्रक्रियेवर RLIMIT_NPROC लागू करत नाही, त्यामुळे विशेषाधिकार सोडून न देता root म्हणून चालणारे युनिट त्या सेटिंगमुळे प्रत्यक्षात अमर्यादित असते। हाच एकमेव अपवाद लोकांमध्ये देवाणघेवाण होणाऱ्या विरोधाभासी सल्ल्याचे स्पष्टीकरण देतो: LimitNPROC वाढवल्याने विशेषाधिकार सोडलेले डिप्लॉयमेंट बर होते आणि विशेषाधिकार टिकवलेल्यासाठी काहीही होत नाही। त्या सेटिंगला श्रेय किंवा दोष देण्यापूर्वी User= आणि डीमॉन सुरू झाल्यानंतर ओळख बदलतो का ते तपासा। विशेषाधिकार असलेले युनिट नंतर विशेषाधिकार नसलेल्या खात्यात गेल्यास बदलाच्या क्षणी पुन्हा मर्यादेखाली येते, यामुळे अयशस्वीतेची कालरेषाही वाचनीय होते।

अयशस्वीतेचा टप्पा ते आणखी संकुचित करतो। अंमलबजावणीच्या तयारीदरम्यान नकार, डीमॉनने स्वतः नोंदवलेली फोर्क त्रुटी, आणि cgroup मध्ये नाकारलेली कार्य निर्मिती या वेगवेगळ्या journal ओळी देतात, आणि त्यापैकी एकालाच मोठे बजेट उत्तर देते।

प्रभावी मूल्ये वाचा, शेलची नाही

इंटरॅक्टिव्ह शेलचे ulimit -u तेच शेल वर्णन करते। सेवा व्यवस्थापकाने डीमॉनला काय दिले याचे ते वर्णन करत नाही, आणि 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 जे त्याच टप्प्यावर आता कार्य किंवा फोर्क संपल्याची नोंद देत नाही। बदलासोबत आधीची आणि नंतरची संख्या ठेवा, जेणेकरून पुढील तपास त्याच सल्ल्यापासून नाही, मोजमापापासून सुरू होईल। जर संख्या अजूनही मर्यादेपर्यंत पोहोचत असेल, तर गणित चुकीचे होते, मर्यादा योगायोगाने खूप लहान नव्हती, आणि पुढील रीस्टार्टपूर्वी हा फरक जाणून घेणे योग्य आहे।