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 हो। परिवर्तनसँगै अघि र पछिका संख्याहरू राख्नुहोस्, ताकि अर्को अनुसन्धान उही सल्लाहबाट होइन, मापनबाट सुरु होस्। यदि संख्या अझै सीमासम्म पुग्छ भने गणना नै गलत थियो, सीमा संयोगवश धेरै सानो थिएन, र अर्को रिस्टार्ट अघि यो भिन्नता जान्नु उपयुक्त हुन्छ।