कंप्यूटर हार्डवेयर हैं। और आज हम शुरुआती बिंदु पर लौट आए, इस अर्थ में कि अब आप शायद ही कभी एक भौतिक मेजबान पाते हैं जिस पर एक ही कार्य किया जाता है। यहां तक कि अगर केवल एक एप्लिकेशन सर्वर पर चल रहा है, तो इसकी संभावना सबसे अधिक कई प्रक्रियाओं, कंटेनरों, या यहां तक कि आभासी मशीनों (वीएम) से होती है, और वे सभी एक ही सर्वर पर काम करते हैं। Red Hat Enterprise Linux 7 ऐसी परिस्थितियों में सिस्टम संसाधनों के वितरण के साथ अच्छी तरह से मुकाबला करता है, लेकिन डिफ़ॉल्ट रूप से यह एक दयालु दादी की तरह व्यवहार करता है, अपने पोते का घर के बने केक के साथ व्यवहार करता है और कहता है: "सभी के लिए समान, सभी के लिए समान।"
सिद्धांत रूप में, "समान रूप से विभाजित" का सिद्धांत, सुंदर है, लेकिन व्यवहार में, कुछ प्रक्रियाएं, कंटेनर या वीएम दूसरों की तुलना में अधिक महत्वपूर्ण हैं, और इसलिए उन्हें अधिक प्राप्त करना चाहिए।
लिनक्स में लंबे समय से संसाधन प्रबंधन उपकरण (अच्छा, अलिमित, आदि) हैं, लेकिन Red Hat Enterprise Linux 7 और systemd के आगमन के साथ, हमारे पास अंततः OS में निर्मित ऐसे उपकरणों का एक शक्तिशाली सेट है। तथ्य यह है कि सिस्टमड का प्रमुख घटक एक तैयार-निर्मित, अनुकूलित समूह है जो ओएस स्तर पर पूरी तरह से उपयोग किया जाता है।
खैर, ये किस तरह के समूह हैं, और संसाधन या प्रदर्शन प्रबंधन कहां जाता है?
कर्नेल स्तर नियंत्रण
जनवरी 2008 में जारी किए गए संस्करण 2.6.24 से शुरू होकर, लिनक्स कर्नेल ने मूल रूप से "प्रोसेस कंटेनर" नाम के तहत Google द्वारा मूल रूप से आविष्कार और निर्मित किया गया था, और लिनक्स में इसे "नियंत्रण समूहों" के रूप में जाना जाता है, संक्षिप्त समूह। संक्षेप में, cgroups एक कर्नेल तंत्र है जो आपको उपयोग को सीमित करने, रिकॉर्ड रखने और सिस्टम संसाधनों (सीपीयू, मेमोरी, डिस्क I / O, नेटवर्क, आदि) की खपत को अलग करने की अनुमति देता है। Cgroups जाँच और पुनः आरंभ करने के लिए प्रक्रियाओं को स्थिर कर सकते हैं। Cgroups नियंत्रकों ने पहले Red Hat Enterprise Linux के संस्करण 6 में दिखाई दिया, लेकिन वहां उन्हें मैन्युअल रूप से कॉन्फ़िगर करना पड़ा। लेकिन Red Hat Enterprise Linux 7 और systemd के आगमन के साथ, cgroups का पूर्व-कॉन्फ़िगर सेट OS के साथ बंडल हो जाता है।
यह सब ओएस के कर्नेल स्तर पर काम करता है और इसलिए प्रत्येक प्रक्रिया पर सख्त नियंत्रण की गारंटी देता है। इसलिए अब किसी भी मैलवेयर के लिए सिस्टम को लोड करना बेहद मुश्किल है, ताकि यह प्रतिक्रिया और जमा करना बंद कर दे। हालांकि, निश्चित रूप से, हार्डवेयर (उदाहरण के लिए, ड्राइवरों) के लिए सीधी पहुंच के साथ छोटी गाड़ी कोड अभी भी इसके लिए सक्षम है। उसी समय, Red Hat Enterprise Linux 7 cgroups के साथ बातचीत करने के लिए एक इंटरफ़ेस प्रदान करता है, और उनके साथ सभी काम मुख्य रूप से systemd कमांड के माध्यम से किया जाता है।
आपका केक का टुकड़ा
नीचे दिए गए आरेख, एक कटा हुआ पाई की याद दिलाता है, Red Hat Enterprise Linux 7 सर्वर पर डिफ़ॉल्ट रूप से तीन cgroups दिखाता है - सिस्टम, उपयोगकर्ता और मशीन। इनमें से प्रत्येक समूह को "स्लाइस" (स्लाइस सेक्टर) कहा जाता है। जैसा कि आप आंकड़े में देख सकते हैं, प्रत्येक स्लाइस में बाल स्लाइसिंग सेक्टर हो सकते हैं। और, केक के मामले में, कुल मिलाकर, सभी स्लाइस संबंधित संसाधन का 100% देते हैं।
अब एक उदाहरण के रूप में प्रोसेसर संसाधनों का उपयोग करते हुए कई cgroups अवधारणाओं को देखें।
ऊपर दिए गए आंकड़े से पता चलता है कि प्रोसेसर का समय तीन ऊपरी-स्तरीय स्लाइस (सिस्टम, उपयोगकर्ता और मशीन) के बीच समान रूप से विभाजित है। लेकिन यह केवल लोड के तहत होता है। यदि उपयोगकर्ता स्लाइस से कुछ प्रक्रिया प्रोसेसर संसाधनों का 100% मांगती है, और किसी और को इन संसाधनों की आवश्यकता नहीं है, तो यह प्रोसेसर समय के सभी 100% प्राप्त करेगा।
तीन शीर्ष स्तरीय स्लाइसों में से प्रत्येक को इसके प्रकार के कार्यभार के लिए डिज़ाइन किया गया है, जो माता-पिता के स्लाइस के भीतर बाल क्षेत्रों को स्लाइस करता है:
- प्रणाली - डेमॉन और सेवाएं।
- उपयोगकर्ता - उपयोगकर्ता सत्र। प्रत्येक उपयोगकर्ता को एक बच्चा टुकड़ा मिलता है, और एक ही स्लाइस में एक ही यूआईडी "लाइव" के साथ सभी सत्र, ताकि विशेष रूप से चालाक समझदार संसाधनों से अधिक संसाधन प्राप्त न कर सकें।
- मशीन - वर्चुअल मशीन, जैसे केवीएम मेहमान।
इसके अलावा, तथाकथित "बॉल" (शेयर) की अवधारणा का उपयोग संसाधनों के उपयोग को नियंत्रित करने के लिए किया जाता है। एक गेंद एक सापेक्ष संख्यात्मक पैरामीटर है; इसका मूल्य केवल उसी cgroup में शामिल अन्य गेंदों के मूल्यों की तुलना में समझ में आता है। डिफ़ॉल्ट रूप से, सभी स्लाइस में 1024 के बराबर एक गेंद होती है। ऊपर की आकृति में सिस्टम स्लाइस में, 1024 के बराबर CPU-गेंदों को httpd, sshd, crond और gdm के लिए सेट किया जाता है। सिस्टम, उपयोगकर्ता, और मशीन के लिए गेंद के मान भी 1024 हैं। क्या यह थोड़ा भ्रमित है? वास्तव में, इसे एक पेड़ के रूप में दर्शाया जा सकता है:
- सिस्टम - 1024
- httpd - 1024
- sshd - 1024
- क्रोंड - 1024
- gdm - 1024
- उपयोगकर्ता - 1024
- bash (मिकेटर) - 1024
- bash (dorf) - 1024
- मशीन - 1024
इस सूची में, हमारे पास कई चल रहे डेमॉन, कुछ उपयोगकर्ता और एक वर्चुअल मशीन है। अब कल्पना करें कि वे सभी एक साथ सभी प्रोसेसर समय का अनुरोध करते हैं जो प्राप्त किया जा सकता है।
संक्षेप में:
- स्लाइस सिस्टम प्रोसेसर समय का 33.333% प्राप्त करता है और समान रूप से चार राक्षसों के बीच साझा करता है, जो उनमें से प्रत्येक को 8.25% सीपीयू संसाधन देता है।
- उपयोगकर्ता का टुकड़ा प्रोसेसर समय का 33.333% प्राप्त करता है और इसे दो उपयोगकर्ताओं के बीच साझा करता है, जिनमें से प्रत्येक के पास CPU संसाधनों का 16.5% है। यदि उपयोगकर्ता मिस्त्री सभी चलने वाली प्रक्रियाओं को लॉग आउट करता है या रोक देता है, तो डोरफ़ोर में 33% सीपीयू संसाधनों तक पहुंच होगी।
- स्लाइस मशीन प्रोसेसर समय का 33.333% प्राप्त करती है। यदि आप वीएम को बंद करते हैं या इसे निष्क्रिय मोड में डालते हैं, तो सिस्टम और उपयोगकर्ता स्लाइस को लगभग 50% सीपीयू संसाधन प्राप्त होंगे, जो तब उनके बच्चे के स्लाइस के बीच साझा किए जाएंगे।
इसके अलावा, किसी भी डेमॉन, उपयोगकर्ता या वर्चुअल मशीन के लिए, आप न केवल रिश्तेदार में प्रवेश कर सकते हैं, बल्कि प्रोसेसर समय की खपत पर भी पूर्ण प्रतिबंध लगा सकते हैं, न केवल एक, बल्कि कई प्रोसेसर भी। उदाहरण के लिए, उपयोगकर्ता स्लाइस मिंटर में CPUQuota संपत्ति है। यदि आप इसे 20% पर सेट करते हैं, तो किसी भी परिस्थिति में मिस्त्री एक सीपीयू के संसाधनों का 20% से अधिक प्राप्त नहीं करेगा। मल्टी-कोर सर्वर पर, CPUQuota 100% से अधिक हो सकता है ताकि टुकड़ा एक से अधिक प्रोसेसर के संसाधनों का उपयोग कर सके। उदाहरण के लिए, CPUQuota = 200% के साथ, एक स्लाइस पूरी तरह से दो प्रोसेसर कोर का उपयोग कर सकता है। यह समझना महत्वपूर्ण है कि सीपीयूकोटा आरक्षित नहीं है, दूसरे शब्दों में, यह किसी भी सिस्टम लोड के लिए प्रोसेसर के दिए गए प्रतिशत की गारंटी नहीं देता है - यह केवल अधिकतम है जो अन्य सभी स्लाइस और सेटिंग्स को ध्यान में रखते हुए एक स्लाइस में आवंटित किया जा सकता है।
पूर्ण से ट्विस्ट!
मैं स्लाइस सेटिंग्स कैसे बदल सकता हूं?
इसके लिए, प्रत्येक स्लाइस में कस्टम गुण होते हैं। और चूंकि यह लिनक्स है, हम मैन्युअल रूप से कॉन्फ़िगरेशन फ़ाइलों में सेटिंग्स लिख सकते हैं या कमांड लाइन से सेट कर सकते हैं।
दूसरे मामले में, systemctl सेट-प्रॉपर्टी कमांड का उपयोग किया जाता है। यहां स्क्रीन पर क्या होगा यदि आप यह कमांड टाइप करते हैं, तो अंत में स्लाइस का नाम (हमारे मामले में, उपयोगकर्ता) जोड़ें और फिर विकल्पों को प्रदर्शित करने के लिए टैब कुंजी दबाएं:
इस स्क्रीनशॉट में सभी गुण cgroup सेटिंग्स नहीं हैं। हम मुख्य रूप से उन लोगों में रुचि रखते हैं जो ब्लॉक, सीपीयू और मेमोरी पर शुरू होते हैं।
यदि आप कमांड लाइन को पसंद नहीं करते हैं, लेकिन फ़ाइलों (उदाहरण के लिए, कई मेजबानों पर स्वचालित तैनाती के लिए) को कॉन्फ़िगर करते हैं, तो आपको / etc / systemd / system फ़ोल्डर में फ़ाइलों से निपटना होगा। जब आप systemctl कमांड का उपयोग करके गुण सेट करते हैं, तो ये फ़ाइलें स्वचालित रूप से बनाई जाती हैं, लेकिन उन्हें एक टेक्स्ट एडिटर में भी बनाया जा सकता है, जिसे Puppet के माध्यम से स्टैम्प किया जाता है, या यहां तक कि मक्खी पर स्क्रिप्ट द्वारा उत्पन्न किया जाता है।
इसलिए, cgroups की मूल अवधारणाओं के साथ, सब कुछ स्पष्ट होना चाहिए। अगली बार हम कुछ परिदृश्यों से गुजरेंगे और देखेंगे कि कुछ संपत्तियों में परिवर्तन प्रदर्शन को कैसे प्रभावित करते हैं।
और सचमुच कल, हम सभी को Red Hat फोरम रूस 2018 में आमंत्रित करते हैं - सीधे Red Hat इंजीनियरों से प्रश्न पूछने का अवसर मिलेगा।हमारे संसाधन लड़ाई श्रृंखला के अन्य cgroups पोस्ट यहां उपलब्ध हैं: