संसाधनों के लिए संघर्ष, भाग 6: cpuset या Sharing हमेशा सही नहीं होता है

जब cgroups के बारे में बात करते हैं, तो Red Hat उपयोगकर्ता अक्सर एक ही प्रश्न पूछते हैं: “मेरे पास एक ऐसा आवेदन है जो देरी के संदर्भ में बहुत संवेदनशील है। क्या इस एप्लिकेशन को कुछ प्रोसेसर कोर पर बांधने से इस एप्लिकेशन को बाकी हिस्सों से अलग करना संभव है? ”



बेशक आप कर सकते हैं। अन्यथा, हम इस मुद्दे को आज के लेख के विषय के रूप में नहीं चुनेंगे।

बचपन में, हमें अक्सर कहा जाता था कि साझा करना अच्छा और सही है। द्वारा और बड़े, जिस तरह से यह है। लेकिन अपवाद हैं।

जैसा कि हमने इस श्रृंखला की पहली पोस्ट में लिखा था, डिफ़ॉल्ट रूप से, Red Hat Enterprise Linux 7 एक गोलाकार तरह की दादी की तरह व्यवहार करता है। इस अर्थ में कि वह उन सभी के बीच प्रणाली संसाधनों को उचित रूप से वितरित करने की कोशिश कर रहा है जो उनसे पूछते हैं। हालांकि, वास्तविक जीवन में, दादी के पास पालतू जानवर हैं जो अधिक प्राप्त करते हैं। Sysadmin में अनुवादित, इसका मतलब है कि ऐसी परिस्थितियां हैं जब कुछ एप्लिकेशन या सेवाएं दूसरों की तुलना में अधिक महत्वपूर्ण हैं, इसलिए उन्हें सभी संभव ध्यान दिया जाना चाहिए ताकि वे यथासंभव संवेदनशील हों।

Red Hat Enterprise Linux 7 दो चरणों में ऐसा करता है:

1. हम प्रोसेसर कोर के एक हिस्से को अलग करते हैं ताकि उन्हें ऐसे एप्लिकेशन के अनन्य उपयोग में स्थानांतरित किया जा सके।
2. हम अलग-अलग गुठली के लिए इस एप्लिकेशन को बांधने वाले cgroups समूह और इकाई फाइलें बनाते हैं।

इन पदों से उदाहरण के बारे में एक छोटी सी विषयांतर

Hat Enterprise Linux 7.4 ने बदल दिया है कि उपयोगकर्ता सत्र जैसे अल्पकालिक स्लाइस कैसे काम करते हैं। नतीजतन, वे अब मक्खी पर cgroup सेटिंग्स को नहीं बदल सकते हैं, कॉन्फ़िगरेशन में स्थायी बदलाव कर सकते हैं, या systemctl सेट-प्रॉपर्टी कमांड का उपयोग करके ड्रॉप-इन फ़ाइलों को बना सकते हैं। हां, यह शर्म की बात है, लेकिन लिनक्स विकास समुदाय ने ऐसा तय किया है। अच्छी खबर यह है कि इन परिवर्तनों ने सेवा को प्रभावित नहीं किया है। यही है, यदि एप्लिकेशन यूनिट फ़ाइलों (डेमन के रूप में काम) के माध्यम से शुरू और बंद हो जाते हैं, तो हमारे सभी उदाहरण काम करते हैं। इसके अलावा, प्राचीन उपकरणों जैसे cgcreate और cgset का उपयोग करके अपने स्वयं के cgroups बनाना संभव है, और फिर CPU और अन्य नियंत्रणों का उपयोग करने के लिए इन समूहों में उपयोगकर्ता सत्र और प्रक्रियाएं रखें। जीवन में, सब कुछ बदल जाता है, इसलिए हम केवल नई तकनीकों का अनुकूलन और आविष्कार कर सकते हैं। और अब हम आज के विषय की ओर मुड़ते हैं।

आइसोलिपस के साथ अलगाववाद का निर्माण

लिनक्स कर्नेल में सबसे महत्वपूर्ण घटकों में से एक प्रक्रिया अनुसूचक है। यदि थोड़ा गहरा है, तो एक प्रक्रिया एक निष्पादन योग्य कोड है जो किसी एप्लिकेशन या सेवा का हिस्सा है। वास्तव में, इस प्रक्रिया में निर्देशों की एक श्रृंखला शामिल है जो कंप्यूटर करता है, यह या वह कार्य करता है, चाहे वह सील्स को देख रहा हो या बहुत गंभीर हो।

इन निर्देशों को केंद्रीय प्रोसेसर, उर्फ ​​सीपीयू द्वारा नियंत्रित किया जाता है। आधुनिक कंप्यूटर पर, CPU में आमतौर पर कोर नामक कई प्रोसेसर होते हैं।

डिफ़ॉल्ट रूप से, शेड्यूलर प्रत्येक प्रोसेसर कोर को कार्यकारी मॉड्यूल में से एक मानता है, जिसमें वह नई प्रक्रियाओं को प्रस्तुत करता है जैसे वे दिखाई देते हैं। इस मामले में, शेड्यूलर कम या ज्यादा समान रूप से कोर के बीच उभरती प्रक्रियाओं को वितरित करने की कोशिश करता है, लोड को ध्यान में रखता है। दुर्भाग्य से, अनुसूचक को यह नहीं बताया जा सकता है कि यह विशेष प्रक्रिया अंततः प्रक्रियाओं के एक पूरे समूह को जन्म देगी, और इस समूह को अन्य प्रक्रियाओं से अलगाव में निष्पादित करना होगा, इस अर्थ में कि उनके पास सामान्य प्रोसेसर कोर नहीं होना चाहिए।

इसलिए, हमें किसी तरह प्लानर को बताने की जरूरत है ताकि वह प्रोसेसर कोर के हिस्से को न छुए, यानी उन्हें हिट होने की कोई प्रक्रिया न दे। और फिर हम खुद (या किसी अन्य प्रक्रिया की मदद से) उन प्रक्रियाओं पर जबरन दबाव डालेंगे जिन्हें हम कर्नेल अनुसूचक से अलग करने के लिए आवश्यक मानते हैं। यह ग्रब कॉन्फ़िगरेशन फ़ाइल में कर्नेल बूट लाइन में आइसोलिपस पैरामीटर का उपयोग करके किया जा सकता है। नीचे दिए गए उदाहरण में, हमारे पास चार कर्नेल के साथ एक मशीन है जिस पर दो ग्रब फ़ाइलें हैं: एक / / आदि डिफ़ॉल्ट में स्थित है और इसे grub.noiso कहा जाता है (यह डिफ़ॉल्ट कॉन्फ़िगरेशन बैकअप है), और दूसरा वहां निहित है और बस ग्रब है ताकि यह हो सके grub2-mkconfig को उठाया। इस दूसरी फ़ाइल को प्रक्रिया अनुसूचक से 1-3 गुठली को अलग करने के लिए संपादित किया गया है।


चेतावनी: Red Hat Enterprise Linux 7 पर, आपको कभी भी बूट / फ़ोल्डर में grub.conf फ़ाइल को मैन्युअल रूप से संशोधित करने की आवश्यकता नहीं है। इसके बजाय, / etc / default / grub के लिए आवश्यक परिवर्तन करें और फिर उपयुक्त उपयोगिता का उपयोग करके grub.conf फ़ाइल का पुनर्निर्माण करें, उदाहरण के लिए, इस तरह:


अलग-अलग पैरामीटर का उपयोग करते समय, जारी प्रोसेसर कोर को कॉमा द्वारा अलग करने के लिए सूचीबद्ध करना आवश्यक है, नंबरिंग 0. से शुरू होती है। सिस्टम रिबूट होने के बाद, प्रक्रिया अनुसूचक कुछ कोर सिस्टम प्रक्रियाओं के लिए इन कोर का उपयोग नहीं करेगा, सिवाय प्रत्येक कोर पर जरूरी होना चाहिए। यह जाँचने के लिए कि क्या हमारी विधि काम करती है, हम कई लोड प्रक्रियाएँ शुरू करेंगे और फिर हम शीर्ष कमांड के माध्यम से प्रत्येक कर्नेल को लोड करते हुए देखेंगे।


जैसा कि आप देख सकते हैं, सभी लोड प्रक्रिया सीपीयू 0 पर बैठी, बजाय सभी चार कोरों में समान रूप से वितरित की जा रही है। इसलिए, हमने बूट पैरामीटर को सही तरीके से पंजीकृत किया है।

Cpuset का उपयोग करके गुठली को बाइंड करता है

अब हम उन चीजों को आगे बढ़ाते हैं जो बेहतर है यदि आप यह नहीं समझते हैं कि आप ऐसा क्यों कर रहे हैं, और जो पूरी तरह से परीक्षण के बाद ही उत्पादन में तैनात करना बेहतर है ।

इन चेतावनियों के लिए क्या हैं? इस तथ्य के लिए कि हम करेंगे, सामान्य तौर पर, लिबर्कग्रुप टूलकिट का उपयोग करते हुए सरल चीजें, जो पिछले पोस्ट में लिखी गई थीं। यदि आपको याद है, तो यह cgroups बनाने, संशोधित करने और नष्ट करने के लिए आदेशों का एक सेट है। वास्तव में, वे Red Hat Enterprise Linux 6 का हिस्सा हैं, लेकिन उन्हें Red Hat Enterprise Linux 7 पर भी स्थापित किया जा सकता है, हालांकि यह संभव है कि यह संभावना भविष्य में गायब हो जाएगी। Libcgroup का उपयोग करने के लिए मुख्य अनुशंसाओं को संक्षेप में याद करें:

1. उन cgroup नियंत्रकों को नियंत्रित करने के लिए systemd का उपयोग करें जो खुद systemd के नियंत्रण में हैं (ये CPU, मेमोरी और ब्लॉक I / O हैं)।
2. अन्य सभी cgroup नियंत्रकों का प्रबंधन करने के लिए libcgroup टूल का उपयोग करें।
3. अपने कार्यों के अनियोजित परिणामों के बारे में बहुत सावधान रहें।

सीप्यूटेशन अवधारणा के साथ सब कुछ सरल है - यह प्रोसेसर कोर (नंबरिंग, रिकॉल, 0 से शुरू होता है) की एक सूची है, जो उन कार्यों को स्वीकार करता है जो इन कोर पर केवल निष्पादित होंगे। ये सबसे सामान्य प्रोसेसर कोर हैं, उन्हें या तो एक प्रक्रिया अनुसूचक द्वारा नियंत्रित किया जा सकता है (यह इस प्रकार है कि सिस्टम डिफ़ॉल्ट रूप से कॉन्फ़िगर किया गया है), या, इसके विपरीत, वे अनुसूचक से अलग हो सकते हैं (जैसा कि हमने ऊपर उदाहरण में किया था)।

आइए हमारे उदाहरण से सिस्टम पर निर्देशिका / sys / fs / cgroup filesystem की जांच करें। जैसा कि आप देख सकते हैं, सीपीयू निर्देशिका पहले से ही मौजूद है, क्योंकि यह नियंत्रक कर्नेल का हिस्सा है (हालांकि यह सिस्टमड के नियंत्रण में नहीं है)। हालाँकि, इसमें अभी तक cgroups नहीं हैं, इसलिए हम इस निर्देशिका में केवल डिफ़ॉल्ट सेटिंग्स देखते हैं।


जाँचें कि libcgroup टूलकिट हमारी मशीन पर स्थापित है:


यदि स्थापित नहीं है, तो यह आसानी से yum स्थापित libcgroup कमांड के साथ तय किया जा सकता है, यहां तक ​​कि रिबूट की भी आवश्यकता नहीं है।

अब cpuset बनाएं। ऐसा करने के लिए, हम cpuset के लिए एक नया cgroup बनाने के लिए और इसके गुणों को पंजीकृत करने के लिए निम्न कमांड्स का उपयोग करेंगे:


Cgcreate कमांड एक cgroup बनाता है जिसे टेस्टसेट कहा जाता है और इसे cpuset कंट्रोलर के अंदर रखता है। फिर हम अपने VM के तीसरे कोर को इस नए cpuset को असाइन करते हैं और NUMA ज़ोन 0 को इसे आवंटित करते हैं। भले ही आपका सिस्टम NUMA का उपयोग नहीं करता है (और हमारा सिर्फ इसका उपयोग नहीं करता है), आपको अभी भी ज़ोन को पंजीकृत करने की आवश्यकता है, अन्यथा आप cgroup group को कार्य असाइन नहीं कर सकते। । अब जांचें कि फ़ाइल सिस्टम पर टेस्टसेट डायरेक्टरी बनाई गई है और देखें कि इसके अंदर क्या है।


जैसा कि आप देख सकते हैं, हमारे परिवर्तन यथावत हैं, लेकिन अभी तक इस cpuset पर कोई प्रक्रिया निष्पादित नहीं की गई है। यहाँ कुछ प्रक्रिया कैसे रोपें?

ऐसा करने के कई तरीके हैं:

• आप किसी मौजूदा प्रक्रिया के PID को कार्य फ़ाइल में चला सकते हैं। यह काम करता है, लेकिन बहुत सुंदर नहीं है।
• प्रक्रिया शुरू होने पर आप cgexec का उपयोग कर सकते हैं और समूह को निर्दिष्ट कर सकते हैं। यह काम करता है अगर आवेदन एक डेमॉन नहीं है; इसके अलावा, यह सब खूबसूरती से एप्लिकेशन लॉन्च स्क्रिप्ट में लिखा जा सकता है।
• डेमन रनिंग सिस्टमड के रूप में चलने वाले एप्लिकेशन के लिए, आप एक सेवा फ़ाइल बना सकते हैं।

चलो cgexec विकल्प देखें।


हमने foo.exe लॉन्च किया, बदले में, इसने एक चाइल्ड प्रोसेस लॉन्च किया, जो केवल प्रोसेसर को सक्रिय रूप से लोड करता है। Cgexec कमांड में --sticky ऑप्शन कहता है कि "किसी भी बच्चे की प्रक्रिया माता-पिता की प्रक्रिया के समान ही होनी चाहिए।" तो यह एक महत्वपूर्ण विकल्प है, और इसे याद रखना चाहिए। अब हम देखते हैं कि हमारे cgroup में दो प्रक्रियाएँ घूम रही हैं, और हम उनके PID को जानते हैं। शीर्ष पर एक नज़र डालें:


जैसा कि आप देख सकते हैं, सीपीयू 3 अब नेत्रगोलक को लोड किया गया है, और बाकी ठंडा हो रहे हैं।

और यहाँ एक यूनिट फ़ाइल सिस्टम अनुप्रयोग के समान अनुप्रयोग चलाने के लिए कैसा दिखता है:


यूनिट फ़ाइल में तीन ExecStartPre कमांड हैं जो उन सेटिंग्स को निष्पादित करते हैं जिन्हें हम पहले ही अपने हाथों से बनाने में कामयाब रहे हैं। इसके बाद ExecStart कमांड आती है, जो एप्लिकेशन लॉन्च करती है। और जब अनुप्रयोग बंद हो जाता है, तो ExecStopPost कमांड cgroup को हटाते हुए, अपने आप को साफ़ करता है।


जैसा कि आप देख सकते हैं, पिछले उदाहरण में, हमने set1 नाम से एक नया cgroup बनाया। हमने यह दिखाने के लिए किया कि आपके पास कई सक्रिय cgroups हो सकते हैं जो समान CPU साझा करते हैं। जिनके लिए यह उपयोगी लग सकता है, लेकिन इसके विपरीत किसी को भ्रमित करने के लिए।

अच्छा, यह काम करता है? ऐसा लगता है!


और अब हम अपनी सेवा के कार्य को पूरा करेंगे और सत्यापित करेंगे कि cgroup नष्ट हो गया है:


ध्यान: cgcreate का उपयोग करके बनाए गए cgroup समूह रिबूट के बाद सहेजे नहीं जाते हैं। इसलिए, ऐसे समूहों का निर्माण स्टार्टअप स्क्रिप्ट और यूनिट फाइलों में निर्धारित किया जाना चाहिए।

तो अब आपके शस्त्रागार में cgroups के साथ काम करने के लिए कुछ और उपकरण हैं। हमें उम्मीद है कि वे काम में आएंगे!

हमारे संसाधन लड़ाई श्रृंखला के अन्य cgroups पोस्ट यहां उपलब्ध हैं:

• भाग 1
• भाग २
• भाग 3
• भाग ४
• भाग 5