लिनक्स प्रशासक पाठ्यक्रम के छात्रों के लिए लेख का अनुवाद तैयार किया गया था।

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

भाग 1: सत्यापित करें कि हेवीज़ को लिनक्स पर शामिल किया गया है (मूल यहाँ )

समस्या:
आपको यह जांचने की आवश्यकता है कि क्या HugePages आपके सिस्टम पर सक्षम है या नहीं।

समाधान:
यह बहुत आसान है:

cat /sys/kernel/mm/transparent_hugepage/enabled 

आपको कुछ इस तरह मिलेगा:

 always [madvise] never 

आपको उपलब्ध विकल्पों की सूची ( हमेशा, मैडविज़, कभी नहीं ) दिखाई देगी , जबकि वर्तमान सक्रिय विकल्प कोष्ठक (डिफ़ॉल्ट रूप से, मैडवीज़ ) में संलग्न किया जाएगा।

मैडविस का अर्थ है transparent hugepages केवल स्मृति क्षेत्रों के लिए शामिल है जो स्पष्ट रूप से मैडविज़ (2) के साथ विशाल शुल्क का अनुरोध करते हैं।

हमेशा मतलब है कि transparent hugepages हमेशा सभी प्रक्रियाओं के लिए सक्षम होती हैं। यह आमतौर पर प्रदर्शन में सुधार करता है, लेकिन अगर आपके पास एक उपयोग का मामला है जहां कई प्रक्रियाएं कम मात्रा में मेमोरी का उपभोग करती हैं, तो कुल मेमोरी लोड नाटकीय रूप से बढ़ सकता है।

कभी भी इसका मतलब यह नहीं है कि मैडवीज़ का उपयोग करने पर भी transparent hugepages को शामिल नहीं किया जाएगा। अधिक जानकारी के लिए लिनक्स कर्नेल प्रलेखन देखें ।

डिफ़ॉल्ट मान कैसे बदलें

विकल्प 1 : सीधे sysfs बदलें (रिबूट करने के बाद, पैरामीटर डिफ़ॉल्ट मान पर वापस आ जाएगा):

 echo always >/sys/kernel/mm/transparent_hugepage/enabled echo madvise >/sys/kernel/mm/transparent_hugepage/enabled echo never >/sys/kernel/mm/transparent_hugepage/enabled 

विकल्प 2 : संशोधित कॉन्फ़िगरेशन के साथ कर्नेल को पुनः कनेक्ट करके सिस्टम डिफ़ॉल्ट को बदलें (यह विकल्प केवल तभी अनुशंसित होता है जब आप अपनी कर्नेल का उपयोग करते हैं):

• हमेशा डिफ़ॉल्ट पर सेट करने के लिए, उपयोग करें:
  

   CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y # Comment out CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y 

• डिफ़ॉल्ट रूप से सेट करने के लिए, उपयोग करें:
  

   CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y # Comment out CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y 

भाग 2: HugePages के फायदे और नुकसान

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

कृपया ध्यान दें कि हम लिनक्स पर चलने वाले 64-बिट x86 सिस्टम के बारे में बात कर रहे हैं, और मैं सिर्फ यह मानता हूं कि सिस्टम पारदर्शी हेवीपेज का समर्थन करता है (क्योंकि यह कोई नुकसान नहीं है कि विशालता को प्रतिस्थापित नहीं किया जाता है), जैसा कि लगभग किसी भी आधुनिक में है। लिनक्स का वातावरण।

नीचे दिए गए लिंक में मैं और अधिक तकनीकी विवरण संलग्न करूंगा।

आभासी स्मृति

यदि आप C ++ प्रोग्रामर हैं, तो आप जानते हैं कि मेमोरी में ऑब्जेक्ट्स के विशिष्ट पते (पॉइंटर मान) होते हैं।

हालांकि, ये पते जरूरी नहीं कि मेमोरी में भौतिक पते (रैम में पते) को दर्शाते हैं। वे वर्चुअल मेमोरी में पते हैं। प्रोसेसर में एक विशेष MMU (मेमोरी मैनेजमेंट यूनिट) मॉड्यूल होता है जो कर्नेल मैप वर्चुअल मेमोरी को एक भौतिक स्थान में मदद करता है।

इस दृष्टिकोण के कई फायदे हैं, लेकिन उनमें से सबसे बुनियादी:

• प्रदर्शन (विभिन्न कारणों के लिए);
• कार्यक्रमों का अलगाव, अर्थात कोई भी कार्यक्रम दूसरे कार्यक्रम की स्मृति से नहीं पढ़ सकता है।

पेज क्या हैं?

वर्चुअल मेमोरी को पेजों में बांटा गया है। प्रत्येक व्यक्तिगत पेज एक विशिष्ट भौतिक मेमोरी की ओर इशारा करता है, यह मुख्य मेमोरी में एक क्षेत्र को इंगित कर सकता है, या यह एक भौतिक डिवाइस को सौंपे गए पते को इंगित कर सकता है, जैसे कि वीडियो कार्ड।

आपके द्वारा डील किए गए ज्यादातर पेज रैम या स्वैप के लिए हैं, यानी वे आपकी हार्ड ड्राइव या एसएसडी पर स्टोर किए जाते हैं। कर्नेल प्रत्येक पृष्ठ के भौतिक लेआउट को नियंत्रित करता है। यदि कोई स्पूफ़ किया गया पृष्ठ एक्सेस किया जाता है, तो कर्नेल उस थ्रेड को रोकता है जो मेमोरी तक पहुंचने की कोशिश कर रहा है, पेज को हार्ड ड्राइव / एसएसडी से रैम में पढ़ता है, और फिर थ्रेड को निष्पादित करना जारी रखता है।

यह प्रक्रिया स्ट्रीम के लिए पारदर्शी है, अर्थात यह हार्ड ड्राइव / SSD से सीधे पढ़ा जाना जरूरी नहीं है। सामान्य पृष्ठों का आकार 4096 बाइट्स है। विशालकाय आकार में 2 मेगाबाइट हैं।

सहयोगी अनुवाद बफर (TLB)

जब कोई प्रोग्राम किसी मेमोरी पेज को एक्सेस करता है, तो केंद्रीय प्रोसेसर को पता होना चाहिए कि किस भौतिक पेज से डेटा पढ़ना है (यानी, वर्चुअल पेज मैप है)।

कोर में एक डेटा संरचना (पेज टेबल) है जिसमें उपयोग किए गए पृष्ठों के बारे में सभी जानकारी है। इस डेटा संरचना का उपयोग करके, आप वर्चुअल पते को भौतिक पते पर मैप कर सकते हैं।

हालाँकि, पेज टेबल बल्कि जटिल है और धीरे-धीरे चलती है, इसलिए हम हर बार पूरी डाटा संरचना का विश्लेषण नहीं कर सकते हैं क्योंकि हर बार मेमोरी एक्सेस हो जाती है।

सौभाग्य से, हमारे प्रोसेसर में एक टीएलबी है जो आभासी और भौतिक पते के मानचित्रण को कैश करता है। इसका मतलब यह है कि इस तथ्य के बावजूद कि हमें पहुंच प्राप्त करने के पहले प्रयास पर पृष्ठ तालिका का विश्लेषण करने की आवश्यकता है, बाद के सभी पृष्ठ कॉल TLB में संसाधित किए जा सकते हैं, जो त्वरित संचालन सुनिश्चित करता है।

चूंकि यह एक भौतिक उपकरण (जो इसे मुख्य रूप से तेज बनाता है) के रूप में लागू किया जाता है, इसकी क्षमता सीमित है। इसलिए, यदि आप अधिक पृष्ठों का उपयोग करना चाहते हैं, तो टीएलबी उन सभी के लिए मैपिंग को स्टोर करने में सक्षम नहीं होगा, जिसके परिणामस्वरूप आपका कार्यक्रम बहुत धीमा काम करेगा।

विशाल बचाव के लिए आते हैं

तो हम टीएलबी अतिप्रवाह से बचने के लिए क्या कर सकते हैं? (हम मानते हैं कि कार्यक्रम को अभी भी उसी मात्रा में मेमोरी की आवश्यकता है)।

यह वह जगह है जहाँ विशालकाय दिखाई देते हैं। 4096 बाइट्स के बजाय, टीएलबी में केवल एक प्रविष्टि की आवश्यकता होती है, टीएलबी में एक प्रविष्टि अब 2 मेगाबाइट की ओर इशारा कर सकती है। हम मान लेंगे कि टीएलबी में 512 प्रविष्टियाँ हैं, यहाँ बिना हेजपेज़ के हम मैच कर सकते हैं:

 4096 b⋅512=2 MB 

जबकि उनके साथ हम तुलना कर सकते हैं:

 2 MB⋅512=1 GB 

यही कारण है कि Hugepages कमाल है। वे महत्वपूर्ण प्रयास के बिना उत्पादकता बढ़ा सकते हैं। लेकिन महत्वपूर्ण आरक्षण हैं।

विशाल ने स्पूफिंग की

कर्नेल स्वचालित रूप से मेमोरी के प्रत्येक पृष्ठ के उपयोग की आवृत्ति को ट्रैक करता है। यदि भौतिक मेमोरी (RAM) अपर्याप्त है, तो कर्नेल अधिक महत्वपूर्ण पृष्ठों के लिए RAM के कुछ खाली करने के लिए कम महत्वपूर्ण (कम अक्सर उपयोग किए जाने वाले) पृष्ठों को हार्ड ड्राइव पर ले जाएगा।
असल में, वही Hugepages के लिए चला जाता है। हालाँकि, कर्नेल केवल संपूर्ण पृष्ठों को स्वैप कर सकता है, न कि व्यक्तिगत बाइट्स को।

मान लीजिए हमारे पास इस तरह का एक कार्यक्रम है:

 char* mymemory = malloc(2*1024*1024); //     Hugepage! //  mymemory -  //    , //      mymemory // ... //       putchar(mymemory[0]); 

इस स्थिति में, कर्नेल को हार्ड ड्राइव / SSD से 2 मेगाबाइट सूचनाओं को बदलने के लिए (रीड) करना होगा, बस आपको एक बाइट पढ़ना है। नियमित पृष्ठों के लिए, केवल 4096 बाइट्स को हार्ड ड्राइव / एसएसडी से पढ़ा जाना चाहिए।

इसलिए, यदि एक विशाल पृष्ठ को प्रतिस्थापित किया जाता है, तो इसका पठन तभी तेज होता है, जब आपको संपूर्ण पृष्ठ तक पहुंचने की आवश्यकता होती है। इसका मतलब है कि यदि आप मेमोरी के विभिन्न हिस्सों को बेतरतीब ढंग से एक्सेस करने की कोशिश कर रहे हैं और सिर्फ एक-दो किलोबाइट्स पढ़ रहे हैं, तो आपको नियमित पेजों का उपयोग करना चाहिए और किसी अन्य चीज की चिंता नहीं करनी चाहिए।

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

मेमोरी आवंटन

यदि आप C में लिखते हैं, तो आप जानते हैं कि आप malloc() का उपयोग करके ढेर से स्मृति की छोटी (या लगभग मनमानी रूप से बड़ी) मात्रा को क्वेरी कर सकते हैं। मान लें कि आपको 30 बाइट्स मेमोरी की आवश्यकता है:

 char* mymemory = malloc(30); 

यह प्रोग्रामर को लग सकता है कि आप ऑपरेटिंग सिस्टम से 30 बाइट्स मेमोरी का "अनुरोध" करते हैं और कुछ वर्चुअल मेमोरी को पॉइंटर लौटाते हैं। लेकिन वास्तव में malloc () सिर्फ एक सी फ़ंक्शन है जो ऑपरेटिंग सिस्टम से मेमोरी या नि: शुल्क मेमोरी के लिए अंदर से ब्रक और sbrk फ़ंक्शन को कॉल करता है।

हालांकि, प्रत्येक आवंटन के लिए अधिक से अधिक मेमोरी का अनुरोध करना अक्षम है; यह सबसे अधिक संभावना है कि किसी भी मेमोरी सेगमेंट को पहले ही मुक्त (free()) कर दिया गया है, और हम इसका पुन: उपयोग कर सकते हैं। malloc() मुक्त मेमोरी के पुन: उपयोग के लिए काफी जटिल एल्गोरिदम को लागू करता है।

उसी समय, सब कुछ आपके लिए किसी का ध्यान नहीं जाता है, तो यह आपको क्यों चिंतित होना चाहिए? लेकिन क्योंकि free() कॉल free() मतलब यह नहीं है कि मेमोरी ऑपरेटिंग सिस्टम में तुरंत वापस आ जाएगी ।

स्मृति विखंडन जैसी कोई चीज होती है। चरम मामलों में, ऐसे ढेर खंड होते हैं जहां केवल कुछ बाइट्स का उपयोग किया जाता है, जबकि बीच में सब कुछ मुक्त हो गया था (free()) ।

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

विशालता का कस्टम अनुप्रयोग

लेख पढ़ने के बाद, आपने यह निर्धारित किया है कि आपके कार्यक्रम के कौन से हिस्से विशालकाय के उपयोग से लाभान्वित हो सकते हैं और कौन से नहीं। तो क्या विशालकों को इसमें शामिल किया जाना चाहिए?

सौभाग्य से, आप madvise() का उपयोग केवल मेमोरी के क्षेत्रों के लिए विशालीकरण को सक्षम करने के लिए कर सकते हैं जहां यह उपयोगी होगा।

आरंभ करने के लिए, सत्यापित करें कि आलेख के आरंभ में निर्देशों का उपयोग करके मैडविज़ () मोड में हैवीपेज़ काम करता है।

फिर, madvise() का उपयोग madvise() कर्नेल को बताएं कि वास्तव में विशालकाय का उपयोग कहाँ करना है।

 #include <sys/mman.h> //    ,    size_t size = 256*1024*1024; char* mymemory = malloc(size); //   hugepages… madvise(mymemory, size, MADV_HUGEPAGE); // …    madvise(mymemory, size, MADV_HUGEPAGE | MADV_SEQUENTIAL) 

ध्यान दें कि यह विधि मेमोरी प्रबंधन के लिए कर्नेल के लिए एक सिफारिश है। इसका मतलब यह नहीं है कि कर्नेल स्वचालित रूप से दिए गए मेमोरी के लिए हैवीपेज का उपयोग करेगा।

स्मृति प्रबंधन और madvise() पर अधिक के लिए मैडविज़ मैनपेज देखें, इस विषय के लिए एक अविश्वसनीय रूप से खड़ी सीखने की अवस्था है। इसलिए, यदि आप इसे वास्तव में अच्छी तरह से समझने का इरादा रखते हैं, तो कम से कम कुछ सकारात्मक परिणाम गिनने से पहले कई हफ्तों तक पढ़ने और परीक्षण की तैयारी करें।

क्या पढ़ना है?

• आईबीएम ओपनस्टैक का लेख
• पारदर्शी विशालता बनाम गैर-पारदर्शी विशालपृष्ठ
• TLB पर विकिपीडिया लेख
• पारदर्शी विशालपृष्ठों पर लिनक्स कर्नेल प्रलेखन
• स्टैकओवरफ्लो: हैवीपेज मेमोरी विखंडन के लिए प्रवण हैं
• Microsoft वर्चुअल मेमोरी प्रबंधन आलेख

एक सवाल है? टिप्पणियों में लिखें!