पाठ्यक्रम विद्यार्थीहरूको लागि तयार लेखको अनुवाद "लिनक्स प्रशासक".

पहिले, मैले लिनक्समा विशाल पृष्ठहरू कसरी परीक्षण र सक्षम गर्ने बारे कुरा गरें।
यो लेख मात्र उपयोगी हुनेछ यदि तपाईंसँग वास्तवमा विशाल पृष्ठहरू प्रयोग गर्ने ठाउँ छ। मैले धेरै मानिसहरूलाई भेटेको छु जो विशाल पृष्ठहरूले जादुई रूपमा उत्पादकतामा सुधार गर्नेछन् भन्ने सम्भावनाले मूर्ख बनाएको छ। यद्यपि, विशाल पेजिङ एक जटिल विषय हो र यदि गलत तरिकाले प्रयोग गरियो भने प्रदर्शन घटाउन सक्छ।

भाग १: लिनक्समा विशाल पृष्ठहरू सक्षम छन् भनेर प्रमाणित गर्दै (मूल यहाँ)

समस्या:
तपाईंले आफ्नो प्रणालीमा HugePages सक्षम छ कि छैन जाँच गर्न आवश्यक छ।

समाधान:
यो धेरै सरल छ:

cat /sys/kernel/mm/transparent_hugepage/enabled

तपाईंले यो जस्तै केहि पाउनुहुनेछ:

always [madvise] never

तपाईंले उपलब्ध विकल्पहरूको सूची देख्नुहुनेछ (सधैं, पागल, कहिल्यै), र हाल सक्रिय विकल्प कोष्ठकहरूमा संलग्न गरिनेछ (पूर्वनिर्धारित रूपमा पागल).

पागल यसको मतलब transparent hugepages केवल मेमोरी क्षेत्रहरूका लागि सक्षम गरिएको छ जुन स्पष्ट रूपमा विशाल पृष्ठहरू प्रयोग गरेर अनुरोध गर्दछ पागल (२).

सधैं यसको मतलब transparent hugepages सधैं सबै प्रक्रियाहरूको लागि सक्षम। यसले सामान्यतया कार्यसम्पादन सुधार गर्छ, तर यदि तपाइँसँग प्रयोगको मामला छ जहाँ धेरै प्रक्रियाहरूले थोरै मात्रामा मेमोरी उपभोग गरिरहेका छन्, तब समग्र मेमोरी लोड नाटकीय रूपमा बढ्न सक्छ।

कहिल्यै यसको मतलब transparent hugepages madvise प्रयोग गरेर अनुरोध गर्दा पनि समावेश गरिने छैन। थप जान्नको लागि, सम्पर्क गर्नुहोस् कागजात लिनक्स कर्नेलहरू।

पूर्वनिर्धारित मान कसरी परिवर्तन गर्ने

विकल्प 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

• पूर्वनिर्धारित रूपमा madvise सेट गर्न, प्रयोग गर्नुहोस्:

  CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
  # Comment out CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y

भाग २: HugePages का फाइदा र बेफाइदाहरू

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

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

म तलको लिङ्कहरूमा थप प्राविधिक विवरण संलग्न गर्नेछु।

भर्चुअल मेमोरी

यदि तपाइँ एक C++ प्रोग्रामर हुनुहुन्छ भने, तपाइँलाई थाहा छ कि मेमोरीमा वस्तुहरूमा विशिष्ट ठेगानाहरू छन् (सूचक मानहरू)।

यद्यपि, यी ठेगानाहरूले मेमोरी (RAM ठेगानाहरू) मा भौतिक ठेगानाहरू प्रतिबिम्बित गर्दैनन्। तिनीहरू भर्चुअल मेमोरीमा ठेगानाहरू प्रतिनिधित्व गर्छन्। प्रोसेसरसँग एक विशेष MMU (मेमोरी व्यवस्थापन इकाई) मोड्युल छ जसले कर्नेल नक्शा भर्चुअल मेमोरीलाई भौतिक स्थानमा मद्दत गर्दछ।

यस दृष्टिकोणका धेरै फाइदाहरू छन्, तर सबैभन्दा महत्त्वपूर्णहरू निम्न हुन्:

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

पृष्ठहरू के हुन्?

भर्चुअल मेमोरी पृष्ठहरूमा विभाजित छ। प्रत्येक व्यक्तिगत पृष्ठले एक विशिष्ट भौतिक मेमोरीमा पोइन्ट गर्दछ, यसले RAM मा भएको क्षेत्रलाई संकेत गर्न सक्छ, वा यसले भिडियो कार्ड जस्ता भौतिक उपकरणमा तोकिएको ठेगानालाई संकेत गर्न सक्छ।

तपाईंले या त RAM मा पोइन्ट गर्ने वा स्वैप गरिएका धेरैजसो पृष्ठहरू तपाईंको हार्ड ड्राइभ वा SSD मा भण्डारण गरिएका छन्। कर्नेलले प्रत्येक पृष्ठको भौतिक रूपरेखा प्रबन्ध गर्दछ। यदि स्पूफ गरिएको पृष्ठ पहुँच गरिएको छ भने, कर्नेलले मेमोरीमा पहुँच गर्न प्रयास गरिरहेको थ्रेडलाई रोक्छ, हार्ड ड्राइभ/एसएसडीबाट RAM मा पृष्ठ पढ्छ, र त्यसपछि थ्रेड कार्यान्वयन गर्न जारी राख्छ।

यो प्रक्रिया स्ट्रिम पारदर्शी छ, यसको मतलब यो आवश्यक छैन कि HDD/SSD बाट सीधा पढ्नुहोस्। सामान्य पृष्ठहरूको आकार 4096 बाइट हो। विशाल पृष्ठहरूको आकार 2 मेगाबाइट हो।

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

जब प्रोग्रामले मेमोरीको पृष्ठ पहुँच गर्छ, CPU ले कुन भौतिक पृष्ठबाट डाटा पढ्ने भन्ने थाहा हुनुपर्छ (अर्थात, भर्चुअल ठेगाना नक्सा छ)।

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

यद्यपि, पृष्ठ तालिका एकदम जटिल र ढिलो छ, त्यसैले हामी कुनै पनि प्रक्रियाले मेमोरी पहुँच गर्दा हरेक पटक सम्पूर्ण डेटा संरचनाको विश्लेषण गर्न सक्दैनौं।

सौभाग्यवश, हाम्रो प्रोसेसरसँग TLB छ जसले भर्चुअल र भौतिक ठेगानाहरू बीचको म्यापिङ क्यास गर्छ। यसको मतलब यो हो कि हामीले पहिलो पहुँच प्रयासमा पृष्ठ तालिका पार्स गर्न आवश्यक भए तापनि, पृष्ठमा सबै पछिल्ला पहुँचहरू छिटो सञ्चालनको लागि अनुमति दिँदै TLB मा ह्यान्डल गर्न सकिन्छ।

किनभने यो भौतिक उपकरणको रूपमा लागू गरिएको छ (जसले यसलाई पहिलो स्थानमा छिटो बनाउँछ), यसको क्षमता सीमित छ। त्यसैले यदि तपाइँ थप पृष्ठहरू पहुँच गर्न चाहनुहुन्छ भने, TLB ले ती सबैका लागि म्यापिङहरू भण्डारण गर्न सक्षम हुने छैन, जसले गर्दा तपाइँको कार्यक्रम धेरै ढिलो चल्छ।

विशाल पृष्ठहरू उद्धारमा आउँछन्

त्यसोभए हामी TLB ओभरफ्लोबाट बच्न के गर्न सक्छौं? (हामी मान्दछौं कि कार्यक्रमलाई अझै पनि मेमोरीको समान मात्रा चाहिन्छ)।

यो जहाँ विशाल पृष्ठहरू आउँछन्। 4096 बाइटको सट्टामा केवल एउटा TLB प्रविष्टि चाहिन्छ, एउटा TLB प्रविष्टिले अब ठूलो 2 मेगाबाइटलाई संकेत गर्न सक्छ। मानौं TLB सँग 512 प्रविष्टिहरू छन्, यहाँ विशाल पृष्ठहरू बिना हामी मिलाउन सक्छौं:

4096 b⋅512=2 MB

त्यसोभए हामी कसरी तिनीहरूसँग तुलना गर्न सक्छौं:

2 MB⋅512=1 GB

यही कारणले विशाल पृष्ठहरू उत्कृष्ट छन्। तिनीहरूले धेरै प्रयास बिना उत्पादकता सुधार गर्न सक्छन्। तर यहाँ महत्त्वपूर्ण चेतावनीहरू छन्।

विशाल पृष्ठहरू स्पूफिंग

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

मानौं हामीसँग यस्तो कार्यक्रम छ:

char* mymemory = malloc(2*1024*1024); // Возьмем это за одну Hugepage!
// Заполним mymemory какими-либо данными
// Сделаем много других вещей,
// которые приведут к подмене страницы mymemory
// ...
// Запросим доступ только к первому байту
putchar(mymemory[0]); 

यस अवस्थामा, कर्नेलले तपाईलाई एउटा बाइट पढ्नको लागि हार्ड ड्राइभ/एसएसडीबाट २ मेगाबाइट जति जानकारी प्रतिस्थापन (पढ्न) आवश्यक पर्दछ। नियमित पृष्ठहरूको लागि, हार्ड ड्राइभ/एसएसडीबाट मात्र 2 बाइटहरू पढ्न आवश्यक छ।

त्यसकारण, यदि विशाल पृष्ठ ओभरराइड गरिएको छ भने, यदि तपाइँ सम्पूर्ण पृष्ठ पहुँच गर्न आवश्यक छ भने यो पढ्नको लागि मात्र छिटो छ। यसको मतलब यो हो कि यदि तपाइँ अनियमित रूपमा मेमोरीको विभिन्न भागहरू पहुँच गर्न प्रयास गर्दै हुनुहुन्छ र केवल केहि किलोबाइटहरू पढ्दै हुनुहुन्छ भने, तपाइँ नियमित पृष्ठहरू प्रयोग गर्नुपर्छ र अरू कुनै कुराको बारेमा चिन्ता नगर्नुहोस्।

अर्कोतर्फ, यदि तपाईंलाई क्रमशः मेमोरीको ठूलो भाग पहुँच गर्न आवश्यक छ भने, विशाल पृष्ठहरूले तपाईंको प्रदर्शन सुधार गर्नेछ। यद्यपि, तपाईंले यसलाई आफैं परीक्षण गर्न आवश्यक छ (अमूर्त सफ्टवेयरको साथ होइन) र के छिटो काम गर्दछ हेर्नुहोस्।

मेमोरीमा आवंटन

यदि तपाइँ C लेख्नुहुन्छ भने, तपाइँलाई थाहा छ कि तपाइँ मनमाने रूपमा सानो (वा लगभग मनमाने रूपमा ठूलो) मेमोरी को हिप प्रयोग गरेर अनुरोध गर्न सक्नुहुन्छ। malloc()। मानौं तपाईंलाई मेमोरीको 30 बाइट चाहिन्छ:

char* mymemory = malloc(30);

एक प्रोग्रामरको लागि, तपाईले अपरेटिङ सिस्टमबाट 30 बाइट मेमोरीको "अनुरोध" गर्दै हुनुहुन्छ र केही भर्चुअल मेमोरीमा पोइन्टर फर्काइरहनुभएको देखिन्छ। तर वास्तवमा malloc () केवल एक सी प्रकार्य हो जुन प्रकार्य भित्रबाट कल गर्दछ brk र sbrk अपरेटिङ सिस्टमबाट मेमोरी अनुरोध गर्न वा खाली गर्न।

यद्यपि, प्रत्येक विनियोजनको लागि अधिक र अधिक मेमोरी अनुरोध गर्न असक्षम छ; यो सम्भव छ कि केहि मेमोरी खण्ड पहिले नै मुक्त गरिएको छ (free())र हामी यसलाई पुन: प्रयोग गर्न सक्छौं। malloc() मुक्त मेमोरी पुन: प्रयोगको लागि धेरै जटिल एल्गोरिदमहरू लागू गर्दछ।

एकै समयमा, तपाइँको लागि सबै कुरा बेवास्ता हुन्छ, त्यसैले तपाइँ किन चिन्ता लिनु पर्छ? तर चुनौतीका कारण 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)

याद गर्नुहोस् कि यो विधि केवल कर्नेललाई कसरी मेमोरी प्रबन्ध गर्ने सल्लाह हो। यसको मतलब यो होइन कि कर्नेलले स्वचालित रूपमा दिइएको मेमोरीको लागि विशाल पृष्ठहरू प्रयोग गर्नेछ।

कागजातमा सन्दर्भ गर्नुहोस् (manpage) madviseमेमोरी व्यवस्थापन बारे थप जान्न र madvise(), यो विषय एक अविश्वसनीय ठाडो सिकाउने वक्र छ। त्यसोभए यदि तपाइँ यसमा साँच्चै राम्रो प्राप्त गर्न चाहानुहुन्छ भने, तपाइँ कुनै पनि सकारात्मक नतिजाहरू आशा गर्नु अघि केहि हप्ता पढ्न र परीक्षण गर्न तयार हुनुहोस्।

के पढ्ने ?

• IBM OpenStack लेख विशाल पृष्ठहरूमा
• पारदर्शी विशाल पृष्ठहरू बनाम गैर-पारदर्शी विशाल पृष्ठहरू
• TLB को बारेमा विकिपीडिया लेख
• पारदर्शी विशाल पृष्ठहरूमा लिनक्स कर्नेल कागजात
• StackOverflow: विशाल पृष्ठहरू मेमोरी खण्डीकरणको लागि प्रवण हुन्छन्
• भर्चुअल मेमोरी व्यवस्थापनमा माइक्रोसफ्ट लेख

एउटा प्रश्न छ? कमेन्टमा लेख्नुहोस !

स्रोत: www.habr.com