अभ्यासक्रमाच्या विद्यार्थ्यांसाठी तयार केलेल्या लेखाचे भाषांतर "लिनक्स प्रशासक".

पूर्वी, मी Linux वर Hugepages ची चाचणी आणि सक्षम कसे करावे याबद्दल बोललो.
हा लेख फक्त तेव्हाच उपयुक्त ठरेल जेव्हा तुमच्याकडे प्रचंड पेजेस वापरण्यासाठी जागा असेल. मी अशा अनेक लोकांना भेटलो आहे ज्यांना Hugepages जादुईपणे उत्पादकता सुधारेल या आशेने फसले आहे. तथापि, विशाल पेजिंग हा एक जटिल विषय आहे आणि चुकीचा वापर केल्यास कार्यप्रदर्शन खराब होऊ शकते.

भाग 1: Linux वर विशाल पृष्ठे सक्षम आहेत याची पडताळणी करणे (मूळ येथे)

समस्या:
तुमच्या सिस्टीमवर HugePages सक्षम आहे का ते तपासणे आवश्यक आहे.

उपाय:
हे अगदी सोपे आहे:

cat /sys/kernel/mm/transparent_hugepage/enabled

तुम्हाला असे काहीतरी मिळेल:

always [madvise] never

तुम्हाला उपलब्ध पर्यायांची सूची दिसेल (नेहमी, madvise, कधीही), आणि सध्या सक्रिय पर्याय कंसात बंद केला जाईल (डीफॉल्टनुसार madvise).

madvise याचा अर्थ transparent hugepages केवळ मेमरी क्षेत्रांसाठी सक्षम केले आहे जे वापरून मोठ्या पृष्ठांची स्पष्टपणे विनंती करतात madvise(2).

नेहमी याचा अर्थ 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

भाग 2: HugePages चे फायदे आणि तोटे

Hugepages वापरण्याचे फायदे, तोटे आणि संभाव्य तोटे आम्ही निवडकपणे स्पष्ट करण्याचा प्रयत्न करू. ह्युजपेजेस हा रामबाण उपाय असल्याच्या भ्रमात असलेल्या लोकांसाठी तांत्रिकदृष्ट्या गुंतागुंतीचा आणि पेडेंटिक लेख समजणे कठीण असल्याने, मी साधेपणासाठी अचूकतेचा त्याग करीन. हे लक्षात ठेवण्यासारखे आहे की बरेच विषय खरोखरच गुंतागुंतीचे आहेत आणि म्हणून ते मोठ्या प्रमाणात सरलीकृत आहेत.

कृपया लक्षात घ्या की आम्ही लिनक्स चालवणार्‍या 64-बिट x86 सिस्टमबद्दल बोलत आहोत आणि मी फक्त असे गृहीत धरत आहे की ही प्रणाली पारदर्शक विशालपृष्ठांना समर्थन देते (कारण हे काही गैर नाही की विशालपृष्ठे अधिलिखित होत नाहीत), जसे की जवळजवळ कोणत्याही आधुनिक लिनक्समध्ये आहे. वातावरण

मी खालील दुव्यांमध्ये अधिक तांत्रिक वर्णन संलग्न करेन.

आभासी स्मृती

तुम्ही C++ प्रोग्रामर असल्यास, तुम्हाला माहीत आहे की मेमरीमधील वस्तूंना विशिष्ट पत्ते (पॉइंटर व्हॅल्यू) असतात.

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

या पद्धतीचे बरेच फायदे आहेत, परंतु सर्वात महत्वाचे आहेत:

• कामगिरी (विविध कारणांमुळे);
• प्रोग्राम आयसोलेशन, म्हणजेच कोणताही प्रोग्राम दुसर्‍या प्रोग्रामच्या मेमरीमधून वाचू शकत नाही.

पृष्ठे काय आहेत?

व्हर्च्युअल मेमरी पृष्ठांमध्ये विभागली आहे. प्रत्येक वैयक्तिक पृष्ठ विशिष्ट भौतिक मेमरीकडे निर्देश करते, ते RAM मधील क्षेत्राकडे निर्देश करू शकते किंवा ते एखाद्या भौतिक उपकरणाला नियुक्त केलेल्या पत्त्याकडे निर्देश करू शकते, जसे की व्हिडिओ कार्ड.

तुम्ही डील केलेली बरीचशी पेज एकतर RAM कडे निर्देशित करतात किंवा स्वॅप केलेली असतात, म्हणजे ती तुमच्या हार्ड ड्राइव्ह किंवा SSD वर साठवलेली असतात. कर्नल प्रत्येक पृष्ठाचे भौतिक लेआउट व्यवस्थापित करते. फसवणूक केलेल्या पृष्ठावर प्रवेश केला असल्यास, कर्नल मेमरीमध्ये प्रवेश करण्याचा प्रयत्न करत असलेला थ्रेड थांबवतो, हार्ड ड्राइव्ह/एसएसडी वरून RAM मध्ये पृष्ठ वाचतो आणि नंतर थ्रेड कार्यान्वित करणे सुरू ठेवतो.

ही प्रक्रिया प्रवाह पारदर्शक आहे, याचा अर्थ ती HDD/SSD वरून थेट वाचली जात नाही. सामान्य पृष्ठांचा आकार 4096 बाइट्स आहे. प्रचंड पृष्ठांचा आकार 2 मेगाबाइट्स आहे.

ट्रान्सलेशन-असोसिएटिव्ह बफर (TLB)

जेव्हा एखादा प्रोग्राम मेमरीच्या पृष्ठावर प्रवेश करतो, तेव्हा CPU ला माहित असणे आवश्यक आहे की कोणत्या भौतिक पृष्ठावरून डेटा वाचायचा आहे (म्हणजे, एक आभासी पत्ता नकाशा आहे).

कर्नलमध्ये डेटा संरचना (पृष्ठ सारणी) असते ज्यामध्ये वापरल्या जाणार्‍या पृष्ठांबद्दल सर्व माहिती असते. या डेटा स्ट्रक्चरचा वापर करून, तुम्ही प्रत्यक्ष पत्त्यावर आभासी पत्ता मॅप करू शकता.

तथापि, पृष्ठ सारणी खूपच जटिल आणि हळू आहे, म्हणून प्रत्येक वेळी जेव्हा प्रक्रिया मेमरीमध्ये प्रवेश करते तेव्हा आम्ही संपूर्ण डेटा संरचनेचे विश्लेषण करू शकत नाही.

सुदैवाने, आमच्या प्रोसेसरमध्ये TLB आहे जो आभासी आणि भौतिक पत्त्यांमधील मॅपिंग कॅश करतो. याचा अर्थ असा की आम्हाला पहिल्या ऍक्सेसच्या प्रयत्नात पृष्ठ सारणीचे विश्लेषण करणे आवश्यक असले तरी, पृष्ठावरील त्यानंतरचे सर्व प्रवेश TLB मध्ये हाताळले जाऊ शकतात, ज्यामुळे जलद ऑपरेशनला अनुमती मिळते.

कारण ते भौतिक उपकरण म्हणून कार्यान्वित केले गेले आहे (ज्यामुळे ते प्रथम स्थानावर जलद होते), त्याची क्षमता मर्यादित आहे. त्यामुळे तुम्हाला अधिक पेजेस ऍक्सेस करायचे असल्यास, TLB त्या सर्वांसाठी मॅपिंग संचयित करू शकणार नाही, ज्यामुळे तुमचा प्रोग्राम खूपच हळू चालेल.

प्रचंड पृष्ठे बचावासाठी येतात

तर TLB ओव्हरफ्लो टाळण्यासाठी आपण काय करू शकतो? (आम्ही गृहीत धरतो की प्रोग्रामला अजूनही समान प्रमाणात मेमरी आवश्यक आहे).

इथेच Hugepages येतात. 4096 बाइट्स ऐवजी फक्त एक TLB एंट्री आवश्यक आहे, एक TLB एंट्री आता तब्बल 2 मेगाबाइट्स दर्शवू शकते. TLB मध्ये 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]); 

या प्रकरणात, कर्नलला हार्ड ड्राइव्ह/एसएसडी मधून 2 मेगाबाइट्स इतकी माहिती बदलणे (वाचणे) आवश्यक आहे फक्त एक बाइट वाचण्यासाठी. नियमित पृष्ठांसाठी, हार्ड ड्राइव्ह/एसएसडी वरून फक्त 4096 बाइट्स वाचणे आवश्यक आहे.

म्हणून, जर विशालपृष्ठ ओव्हरराइड केले असेल तर, जर तुम्हाला संपूर्ण पृष्ठावर प्रवेश करण्याची आवश्यकता असेल तरच ते वाचणे जलद होईल. याचा अर्थ असा की जर तुम्ही यादृच्छिकपणे मेमरीच्या वेगवेगळ्या भागांमध्ये प्रवेश करण्याचा प्रयत्न करत असाल आणि फक्त दोन किलोबाइट्स वाचत असाल, तर तुम्ही नियमित पृष्ठे वापरावीत आणि कशाचीही काळजी करू नये.

दुसरीकडे, जर तुम्हाला मेमरीच्या मोठ्या भागामध्ये अनुक्रमे प्रवेश करण्याची आवश्यकता असेल, तर विशाल पृष्ठे तुमचे कार्यप्रदर्शन सुधारतील. तथापि, तुम्हाला ते स्वतः तपासण्याची आवश्यकता आहे (अमूर्त सॉफ्टवेअरसह नाही) आणि काय जलद कार्य करते ते पहा.

मेमरी मध्ये वाटप

तुम्ही C लिहिल्यास, तुम्हाला माहीत आहे की तुम्ही या ढीगमधून अनियंत्रितपणे लहान (किंवा जवळजवळ अनियंत्रितपणे मोठ्या प्रमाणात) मेमरीची विनंती करू शकता. malloc(). समजा तुम्हाला 30 बाइट्स मेमरी आवश्यक आहे:

char* mymemory = malloc(30);

एखाद्या प्रोग्रामरला, असे दिसून येईल की तुम्ही ऑपरेटिंग सिस्टमकडून 30 बाइट्स मेमरीची "विनंती" करत आहात आणि काही व्हर्च्युअल मेमरीवर पॉइंटर परत करत आहात. पण प्रत्यक्षात malloc () हे फक्त एक C फंक्शन आहे जे फंक्शनमधून कॉल करते 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 बद्दल विकिपीडिया लेख
• पारदर्शक विशाल पृष्ठांवर लिनक्स कर्नल दस्तऐवजीकरण
• स्टॅकओव्हरफ्लो: प्रचंड पृष्ठे मेमरी फ्रॅगमेंटेशनसाठी प्रवण असतात
• व्हर्च्युअल मेमरी व्यवस्थापनावर मायक्रोसॉफ्ट लेख

एक प्रश्न आहे का? टिप्पण्यांमध्ये लिहा!

स्त्रोत: www.habr.com