संसाधनों के लिए संघर्ष, भाग 2: हम Cgroups की सेटिंग्स के साथ खेलते हैं

हमने Red Hat Enterprise Linux 7 में नियंत्रण समूहों (Cgroups) का अध्ययन करना शुरू किया - एक कर्नेल-स्तरीय तंत्र जो आपको सिस्टम संसाधनों के उपयोग को नियंत्रित करने की अनुमति देता है, सैद्धांतिक नींव की संक्षिप्त जांच की और अब CPU, मेमोरी और I / O संसाधनों को प्रबंधित करने का अभ्यास करें।


हालांकि, कुछ भी बदलने से पहले, यह पता लगाना हमेशा उपयोगी होता है कि अब सब कुछ कैसे व्यवस्थित किया जाता है।

दो उपकरण हैं जिनके साथ आप सिस्टम में सक्रिय cgroups की स्थिति देख सकते हैं। सबसे पहले, यह systemd-cgls है - एक कमांड जो पेड़ की तरह दिखने वाली सूची को cgroups और रनिंग प्रक्रियाओं को प्रदर्शित करता है। उसका आउटपुट कुछ इस तरह दिखता है:


यहां हम शीर्ष-स्तरीय cgroups देखें: user.slice और system.slice। हमारे पास आभासी मशीनें नहीं हैं, इसलिए, लोड के तहत, इन शीर्ष-स्तरीय समूहों को 50% CPU संसाधन प्राप्त होते हैं (क्योंकि मशीन टुकड़ा सक्रिय नहीं है)। User.slice में दो बच्चे स्लाइस हैं: user-1000.slice और user-0.slice। उपयोगकर्ता स्लाइस की पहचान उपयोगकर्ता आईडी (यूआईडी) द्वारा की जाती है, इसलिए चल रही प्रक्रियाओं को छोड़कर, मालिक की पहचान करना मुश्किल हो सकता है। हमारे मामले में, ssh सत्र बताते हैं कि उपयोगकर्ता 1000 मिस्त्री है, और उपयोगकर्ता 0 क्रमशः रूट है।

दूसरी कमांड जिसका हम उपयोग करेंगे, वह है systemd-cgtop। यह वास्तविक समय में संसाधनों के उपयोग की एक तस्वीर दिखाता है (सिस्टम-क्लैग का उत्पादन, वैसे, वास्तविक समय में भी अपडेट किया जाता है)। स्क्रीन पर, यह कुछ इस तरह दिखता है:


सिस्टमड-cgtop के साथ एक समस्या है - यह केवल उन सेवाओं और स्लाइस के लिए आंकड़े दिखाता है जिनके लिए संसाधन उपयोग लेखांकन सक्षम है। / / / Systemd / system में उपयुक्त उपनिर्देशिकाओं में ड्रॉप-इन गोपनीय फाइलों को बनाकर लेखांकन सक्षम किया गया है। उदाहरण के लिए, नीचे स्क्रीनशॉट में sshd सेवा के लिए CPU और मेमोरी उपयोग सक्षम करता है। अपने आप को ऐसा करने के लिए, बस एक पाठ संपादक में एक ही ड्रॉप-इन बनाएं। इसके अलावा, लेखांकन को व्यवस्थित सेट-प्रॉपर्टी sshd.service CPUAccounting = true कमांड MemoryAccounting = true के साथ भी सक्षम किया जा सकता है।


ड्रॉप-इन बनाने के बाद, आपको systemctl डेमॉन-रीलोड कमांड दर्ज करना होगा, साथ ही संबंधित सर्विस के लिए systemctl पुनरारंभ <service_name> कमांड। नतीजतन, आप संसाधनों के उपयोग पर आंकड़े देखेंगे, लेकिन यह एक अतिरिक्त बोझ पैदा करेगा, क्योंकि संसाधनों को लेखांकन पर भी खर्च किया जाएगा। इसलिए, लेखांकन को सावधानीपूर्वक और केवल उन सेवाओं और cgroups के लिए शामिल किया जाना चाहिए जिन्हें इस तरह से निगरानी करने की आवश्यकता है। हालांकि, अक्सर सिस्टमड-cgtop के बजाय, आप शीर्ष या iotop कमांड के साथ कर सकते हैं।

मज़ा और उपयोगी के लिए सीपीयू-गेंदों को बदलें

अब देखते हैं कि प्रोसेसर बॉल (सीपीयू शेयर्स) में बदलाव प्रदर्शन को कैसे प्रभावित करता है। उदाहरण के लिए, हमारे पास दो अप्रभावी उपयोगकर्ता और एक सिस्टम सेवा होगी। मिक्र्टर लॉगिन वाले उपयोगकर्ता के पास 1000 का यूआईडी है, जिसे / etc / passwd फ़ाइल का उपयोग करके सत्यापित किया जा सकता है।


यह महत्वपूर्ण है क्योंकि उपयोगकर्ता स्लाइस को यूआईडी द्वारा नाम दिया गया है न कि खाता नाम से।

अब, आइए ड्रॉप-इन निर्देशिका पर जाएं और देखें कि क्या इसके स्लाइस के लिए पहले से ही कुछ है।


नहीं, कुछ भी नहीं है। हालांकि कुछ और है - foo.service से संबंधित चीजों पर एक नज़र डालें:


यदि आप सिस्टमड यूनिट फ़ाइलों से परिचित हैं, तो आप यहाँ एक पूरी तरह से साधारण यूनिट फ़ाइल देखेंगे जो कमांड / usr / bin / sha1sum / dev / शून्य को एक सेवा के रूप में (दूसरे शब्दों में, एक डेमन) के रूप में चलाती है। हमारे लिए, क्या मायने रखती है कि फू ले जाएगा। सचमुच सभी प्रोसेसर संसाधन जो सिस्टम उसे उपयोग करने की अनुमति देगा। इसके अलावा, यहाँ हमारे पास 2048 के लिए foo सेवा के लिए foo मान सेट करने के लिए एक ड्रॉप-इन है। डिफ़ॉल्ट रूप से, जैसा कि आपको याद है, इसका उपयोग 1024 मान के साथ किया जाता है, इसलिए लोड foo के तहत system.lice के भीतर CPU संसाधनों का दोहरा हिस्सा प्राप्त होगा। , इसका मूल शीर्ष स्तर का टुकड़ा (चूंकि फू एक सेवा है)।

अब systemctl के माध्यम से foo चलाएं और देखें कि शीर्ष कमांड हमें क्या दिखाता है:


चूंकि सिस्टम में व्यावहारिक रूप से कोई अन्य काम करने वाली चीजें नहीं हैं, इसलिए फू सेवा (पीआईडी ​​2848) एक सीपीयू के लगभग सभी प्रोसेसर समय का उपभोग करती है।

अब उपयोगकर्ता के समीकरण में मिक्रटर को पेश करते हैं। सबसे पहले, हमने उसे सीपीयू बॉल को 256 तक काट दिया, फिर वह लॉग इन करता है और foo.exe शुरू करता है, दूसरे शब्दों में, समान प्रोग्राम, लेकिन उपयोगकर्ता प्रक्रिया के रूप में।


इसलिए मिस्त्री ने फू ल लॉन्च किया। और यहाँ शीर्ष कमांड अब दिखाता है:


अजीब बात है, है ना? उपयोगकर्ता मिस्त्री को प्रोसेसर का लगभग 10 प्रतिशत समय लगता है, क्योंकि उसके पास = 256 बॉल है, और foo.service 2048 है, नहीं?

अब हम dorf को समीकरण में शामिल करते हैं। यह 1024 के बराबर मानक सीपीयू गेंद के साथ एक और सामान्य उपयोगकर्ता है। वह फू भी चलाएगा, और फिर हम देखेंगे कि प्रोसेसर समय का वितरण कैसे बदल जाएगा।


dorf एक पुराने स्कूल का उपयोगकर्ता है, वह बस किसी भी स्मार्ट स्क्रिप्ट या किसी अन्य चीज़ के बिना, प्रक्रिया शुरू करता है। और फिर से हम शीर्ष के आउटपुट को देखते हैं:


तो ... चलो cgroups ट्री पर एक नज़र डालें और यह पता लगाने की कोशिश करें कि क्या है:


यदि आपको याद है, आमतौर पर एक प्रणाली में तीन शीर्ष स्तर के समूह होते हैं: सिस्टम, उपयोगकर्ता और मशीन। चूंकि हमारे उदाहरण में कोई वर्चुअल मशीन नहीं है, केवल सिस्टम और उपयोगकर्ता स्लाइस ही रहते हैं। उनमें से प्रत्येक में 1024 की सीपीयू-बॉल है, और इसलिए लोड के तहत इसे आधा प्रोसेसर समय मिलता है। चूंकि foo.service सिस्टम में रहता है, और इस स्लाइस में CPU समय के लिए कोई अन्य उम्मीदवार नहीं हैं, foo.service को 50% CPU संसाधन प्राप्त होते हैं।

इसके अलावा, उपयोगकर्ता dorf और mrichter उपयोगकर्ता स्लाइस में रहते हैं। पहली गेंद 1024, दूसरी - 256 है। इसलिए, डॉफ़र को मिक्रटर की तुलना में चार गुना अधिक प्रोसेसर समय मिलता है। अब देखते हैं कि शीर्ष शो क्या है: foo.service - 50%, dorf - 40%, मिस्त्री - 10%।

इसे एक उपयोग-मामले की भाषा में अनुवाद करते हुए, हम कह सकते हैं कि डॉर्फ की उच्च प्राथमिकता है। तदनुसार, cgroups कॉन्फ़िगर किए गए हैं ताकि उपयोगकर्ता उस समय के लिए संसाधनों को काट दे जो उन्हें dorf'u की आवश्यकता है। दरअसल, आखिरकार, मिस्त्री अकेले सिस्टम में थे, उन्हें प्रोसेसर समय का 50% प्राप्त हुआ, क्योंकि उपयोगकर्ता के स्लाइस में किसी और ने सीपीयू संसाधनों के लिए प्रतिस्पर्धा नहीं की।

वास्तव में, सीपीयू-गेंदों प्रोसेसर समय के एक निश्चित "गारंटी न्यूनतम" प्रदान करने का एक तरीका है, यहां तक ​​कि उपयोगकर्ताओं और सेवाओं के लिए कम प्राथमिकता के साथ।

इसके अलावा, हमारे पास सीपीयू संसाधनों के लिए एक कठिन कोटा निर्धारित करने का एक तरीका है, पूर्ण संख्या में एक निश्चित सीमा। हम इसे उपयोगकर्ता के लिए समृद्ध करेंगे और देखेंगे कि संसाधनों का वितरण कैसे बदलता है।



अब उपयोगकर्ता dorf के कार्यों को मार डालते हैं, और यहाँ क्या होता है:


मिकेटर के लिए, पूर्ण सीपीयू सीमा 5% है, इसलिए foo.service को बाकी प्रोसेसर समय मिलता है।

बदमाशी जारी रखें और foo.service बंद करें:


हम यहां क्या देख रहे हैं: मिस्त्री के पास प्रोसेसर समय का 5% है, और शेष 95% सिस्टम बेकार है। औपचारिक उपहास, हाँ।

वास्तव में, यह दृष्टिकोण आपको उन सेवाओं या अनुप्रयोगों को प्रभावी ढंग से शांत करने की अनुमति देता है जो अन्य प्रक्रियाओं के अवरोध के लिए सभी प्रोसेसर संसाधनों को अचानक स्विंग और खींचना पसंद करते हैं।

इसलिए, हमने सीखा कि कैसे cgroups के साथ वर्तमान स्थिति को नियंत्रित किया जाए। अब हम थोड़ा गहरा खुदाई करते हैं और देखते हैं कि वर्चुअल फाइल सिस्टम स्तर पर cgroup कैसे लागू किया जाता है।

सभी चल रहे cgroups के लिए रूट डायरेक्टरी / sys / fs / cgroup पर स्थित है। जब सिस्टम बूट होता है, तो यह सेवाओं और अन्य कार्यों के शुरू होते ही भर जाता है। सेवाओं को शुरू करने और रोकने के दौरान, उनकी उपनिर्देशिकाएं प्रकट होती हैं और गायब हो जाती हैं।

नीचे स्क्रीनशॉट में, हम सीपीयू नियंत्रक के लिए एक उपनिर्देशिका में गए, अर्थात् सिस्टम स्लाइस में। जैसा कि आप देख सकते हैं, फू के लिए उपनिर्देशिका अभी तक यहां नहीं है। Foo चलाएं और कुछ चीजों को जांचें, जैसे कि उसका PID और उसकी वर्तमान CPU बॉल:



महत्वपूर्ण चेतावनी: यहां आप मक्खी पर मूल्यों को बदल सकते हैं। हां, सिद्धांत रूप में यह शांत दिखता है (और वास्तव में, भी), लेकिन यह एक बड़ी गड़बड़ी में बदल सकता है। इसलिए, कुछ भी बदलने से पहले, सावधानी से सब कुछ तौलना और युद्ध सर्वर पर कभी नहीं खेलना चाहिए। लेकिन वैसे भी, एक आभासी फ़ाइल प्रणाली गहरी खुदाई करने के लिए कुछ है जैसा कि आप सीखते हैं कि cgroups कैसे काम करते हैं।

• भाग 1 - habr.com/company/redhatrussia/blog/423051
• भाग 3 - habr.com/company/redhatrussia/blog/425803
• भाग 4 - habr.com/company/redhatrussia/blog/427413
• भाग 5 - habr.com/company/redhatrussia/blog/429064
• भाग 6 - habr.com/company/redhatrussia/blog/430748