GlusterFS साठी लिनक्स कर्नल सेट करणे

लेखाचा अनुवाद अभ्यासक्रम सुरू होण्याच्या आदल्या दिवशी तयार केला होता "प्रशासक लिनक्स. व्यावसायिक".

वेळोवेळी, कर्नल कस्टमायझेशन संदर्भात ग्लुस्टरच्या शिफारसी आणि ते आवश्यक आहे की नाही याबद्दल येथे आणि तेथे प्रश्न उद्भवतात.

ही गरज क्वचितच उद्भवते. कोर बर्‍याच वर्कलोड अंतर्गत खूप चांगले कार्य करते. एक downside आहे तरी. ऐतिहासिकदृष्ट्या, कार्यप्रदर्शन सुधारण्याचे प्राथमिक साधन म्हणून कॅशिंगसह संधी दिल्यास लिनक्स कर्नल सहजपणे बरीच मेमरी वापरते.

बर्याच बाबतीत हे चांगले कार्य करते, परंतु जास्त भाराखाली यामुळे समस्या उद्भवू शकतात.

आमच्याकडे भरपूर मेमरी वापरणाऱ्या प्रणालींसह काम करण्याचा व्यापक अनुभव आहे, जसे की CAD, EDA आणि यासारख्या, ज्या उच्च भाराखाली कमी होऊ लागल्या. आणि कधीकधी आम्हाला ग्लुस्टरमध्ये समस्या आल्या. वापरलेली मेमरी आणि डिस्कची प्रतीक्षा वेळ एका दिवसापेक्षा जास्त काळ काळजीपूर्वक निरीक्षण केल्यावर, आम्हाला डिस्क ओव्हरलोड, प्रचंड आयओवेट, कर्नल एरर (कर्नल ओप्स), फ्रीझ इ.

हा लेख विविध परिस्थितींमध्ये केलेल्या अनेक पॅरामीटर ट्यूनिंग प्रयोगांचा परिणाम आहे. या पॅरामीटर्सबद्दल धन्यवाद, केवळ प्रतिसादात्मकता सुधारली नाही तर क्लस्टरचे ऑपरेशन देखील लक्षणीय स्थिर झाले.

जेव्हा मेमरी कॉन्फिगर करण्याचा विचार येतो, तेव्हा पहिले स्थान व्हर्च्युअल मेमरी सबसिस्टम (VM) आहे, ज्यामध्ये मोठ्या संख्येने पर्याय आहेत जे तुम्हाला गोंधळात टाकू शकतात.

vm.swappiness

पॅरामीटर vm.swappiness RAM च्या तुलनेत कर्नल स्वॅप किती वापरते हे ठरवते. स्त्रोत कोडमध्ये "मॅप केलेली मेमरी चोरण्याची प्रवृत्ती" म्हणून देखील परिभाषित केले आहे. उच्च स्वॅपीनेस व्हॅल्यू म्हणजे कर्नल मॅप केलेली पृष्ठे स्वॅप करण्यास अधिक प्रवण असेल. कमी स्वॅपीनेस व्हॅल्यूचा अर्थ उलट आहे: कर्नल मेमरी कमी पृष्ठे स्वॅप करेल. दुसऱ्या शब्दांत, मूल्य जितके जास्त असेल vm.swappiness, प्रणाली जितकी जास्त स्वॅप वापरेल.

स्वॅपिंगचा व्यापक वापर अवांछित आहे, कारण डेटाचे प्रचंड ब्लॉक्स RAM मध्ये लोड आणि अनलोड केले जातात. बरेच लोक असा युक्तिवाद करतात की स्वॅपीनेस व्हॅल्यू जास्त असली पाहिजे, परंतु माझ्या अनुभवानुसार, "0" वर सेट केल्याने चांगले कार्यप्रदर्शन होते.

आपण येथे अधिक वाचू शकता - lwn.net/Articles/100978

परंतु पुन्हा, या सेटिंग्ज सावधगिरीने वापरल्या पाहिजेत आणि विशिष्ट अनुप्रयोगाची चाचणी घेतल्यानंतरच. उच्च लोड केलेल्या स्ट्रीमिंग ऍप्लिकेशन्ससाठी, हे पॅरामीटर "0" वर सेट केले जावे. जेव्हा "0" मध्ये बदलले जाते, तेव्हा सिस्टम प्रतिसाद सुधारते.

vm.vfs_cache_pressure

ही सेटिंग डिरेक्टरी ऑब्जेक्ट्स आणि इनोड्स (डेंट्री आणि इनोड) कॅश करण्यासाठी कर्नलद्वारे वापरल्या जाणार्‍या मेमरी नियंत्रित करते.

100 च्या डीफॉल्ट मूल्यासह, कर्नल पेजकॅशे आणि स्वॅपकॅशेमध्ये योग्य पद्धतीने डेंट्री आणि इनोड कॅशे मुक्त करण्याचा प्रयत्न करेल. vfs_cache_pressure कमी केल्याने कर्नल डेन्ट्री आणि इनोड कॅशे जतन करतो. जेव्हा व्हॅल्यू "0" असते, तेव्हा कर्नल मेमरी प्रेशरमुळे डेन्ट्री आणि इनोड कॅशे कधीही फ्लश करणार नाही आणि यामुळे मेमरीबाहेरची त्रुटी सहज होऊ शकते. 100 च्या वर vfs_cache_pressure वाढवण्यामुळे कर्नल डेन्ट्री आणि इनोड पेजआउट्सना प्राधान्य देतो.

ग्लुस्टरएफएस वापरताना, आयनोड/डेंट्री कॅशिंगमुळे मोठ्या प्रमाणात डेटा आणि अनेक लहान फाइल्स असलेले बरेच वापरकर्ते सहजपणे सर्व्हरवर लक्षणीय प्रमाणात RAM वापरू शकतात, ज्यामुळे कर्नलला सिस्टमवर डेटा स्ट्रक्चर्स हाताळावे लागत असल्याने खराब कामगिरी होऊ शकते. 40 GB मेमरीसह. हे पॅरामीटर 100 पेक्षा जास्त सेट केल्याने बर्‍याच वापरकर्त्यांना अधिक योग्य कॅशिंग आणि कर्नल प्रतिसाद सुधारण्यास मदत झाली आहे.

vm.dirty_background_ratio आणि vm.dirty_ratio

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

दुसरा पॅरामीटर (vm.dirty_ratio) सक्तीचा फ्लॅश सुरू होण्यापूर्वी गलिच्छ पृष्ठांनी व्यापलेली मेमरीची टक्केवारी निर्धारित करते. एकदा ही थ्रेशोल्ड गाठली की, सर्व प्रक्रिया समकालिक (अवरोधित) होतात आणि त्यांनी विनंती केलेले I/O ऑपरेशन प्रत्यक्षात पूर्ण होईपर्यंत आणि डेटा डिस्कवर येईपर्यंत त्यांना चालू ठेवण्याची परवानगी नसते. उच्च I/O लोडसह, यामुळे समस्या उद्भवते कारण डेटा कॅशिंग नाही आणि I/O करत असलेल्या सर्व प्रक्रिया I/O ची वाट पाहत अवरोधित आहेत. यामुळे मोठ्या प्रमाणात हँग प्रक्रिया, उच्च भार, सिस्टम अस्थिरता आणि खराब कार्यप्रदर्शन होते.

या पॅरामीटर्सची मूल्ये कमी केल्याने डेटा डिस्कवर अधिक वेळा फ्लश केला जातो आणि RAM मध्ये संग्रहित केला जात नाही. हे मेमरी-हेवी सिस्टमला मदत करू शकते जिथे 45-90GB पृष्ठ कॅशे डिस्कवर फ्लश करणे सामान्य आहे, परिणामी फ्रंट-एंड ऍप्लिकेशन्ससाठी प्रचंड विलंब होतो, एकूण प्रतिसाद आणि संवादात्मकता कमी होते.

"1" > /proc/sys/vm/pagecache

पृष्ठ कॅशे ही एक कॅशे आहे जी फायली आणि एक्झिक्युटेबल प्रोग्राममधील डेटा संग्रहित करते, म्हणजेच ही फायली किंवा ब्लॉक डिव्हाइसेसची वास्तविक सामग्री असलेली पृष्ठे आहेत. या कॅशेचा वापर डिस्क रीडची संख्या कमी करण्यासाठी केला जातो. "1" चे मूल्य म्हणजे कॅशे RAM च्या 1% वापरते आणि RAM पेक्षा डिस्कवरून अधिक वाचन केले जाईल. हे सेटिंग बदलणे आवश्यक नाही, परंतु आपण पृष्ठ कॅशे नियंत्रित करण्याबद्दल पागल असल्यास, आपण ते वापरू शकता.

"डेडलाइन" > /sys/block/sdc/queue/scheduler

I/O शेड्युलर हा लिनक्स कर्नलचा एक घटक आहे जो वाचन आणि लेखन रांग हाताळतो. सिद्धांतानुसार, स्मार्ट RAID कंट्रोलरसाठी "नूप" वापरणे चांगले आहे, कारण लिनक्सला डिस्कच्या भौतिक भूमितीबद्दल काहीही माहिती नाही, म्हणून डिस्कची भूमिती चांगल्या प्रकारे जाणणाऱ्या कंट्रोलरला विनंतीवर प्रक्रिया करू देणे अधिक कार्यक्षम आहे. शक्य तितक्या लवकर. परंतु असे दिसते की "डेडलाइन" कामगिरी सुधारते. शेड्यूलर्सबद्दल अधिक माहिती लिनक्स कर्नल स्त्रोत कोडसाठी दस्तऐवजीकरणामध्ये आढळू शकते: linux/Documentation/block/*osched.txt. आणि मी मिश्र ऑपरेशन्स दरम्यान वाचन थ्रूपुटमध्ये वाढ देखील पाहिली (बरेच लेखन).

"256" > /sys/block/sdc/queue/nr_requests

शेड्युलरला पाठवण्यापूर्वी बफरमधील I/O विनंत्यांची संख्या. काही नियंत्रकांचा अंतर्गत रांगेचा आकार (queue_depth) I/O शेड्युलरच्या nr_requests पेक्षा मोठा असतो, त्यामुळे I/O शेड्युलरला विनंत्या योग्यरित्या प्राधान्य आणि विलीन करण्याची शक्यता कमी असते. डेडलाइन आणि CFQ शेड्युलरसाठी, जेव्हा nr_requests कंट्रोलरच्या अंतर्गत रांगेपेक्षा 2 पट मोठी असते तेव्हा ते चांगले असते. क्वेरी विलीन करणे आणि पुनर्क्रमित करणे शेड्युलरला जास्त भाराखाली अधिक प्रतिसाद देण्यास मदत करते.

echo "16" > /proc/sys/vm/page-cluster

पृष्ठ-क्लस्टर पॅरामीटर एका वेळी स्वॅपमध्ये लिहिलेल्या पृष्ठांची संख्या नियंत्रित करते. वरील उदाहरणामध्ये, मूल्य 16 KB च्या RAID पट्टी आकाराशी जुळण्यासाठी "64" वर सेट केले आहे. जेव्हा swappiness = 0 असेल तेव्हा याचा अर्थ नाही, परंतु जर तुम्ही swappiness 10 किंवा 20 वर सेट केला, तर RAID पट्टीचा आकार 64 KB असेल तेव्हा हे मूल्य वापरणे तुम्हाला मदत करेल.

blockdev --setra 4096 /dev/<देवनाव> (-sdb, hdc किंवा dev_mapper)

अनेक RAID कंट्रोलर्ससाठी डिफॉल्ट ब्लॉक डिव्हाइस सेटिंग्ज अनेकदा भयानक कार्यप्रदर्शनास कारणीभूत ठरतात. वरील पर्याय जोडल्याने 4096*512 बाइट सेक्टरसाठी रीड-अहेड कॉन्फिगर होईल. कमीत कमी स्ट्रीमिंग ऑपरेशन्ससाठी, कर्नल I/O तयार करण्यासाठी वापरते त्या कालावधीत ऑन-चिप डिस्क कॅशे रीड-अहेडद्वारे भरून गती वाढवली जाते. कॅशेमध्ये डेटा असू शकतो जो पुढील वाचनादरम्यान विनंती केला जाईल. खूप जास्त वाचन-पुढे मोठ्या फायलींसाठी यादृच्छिक I/O नष्ट करू शकतात जर ते संभाव्य उपयुक्त डिस्क वेळ वापरत असेल किंवा कॅशेच्या बाहेर डेटा लोड करत असेल.

खाली फाइल सिस्टम स्तरावर आणखी काही शिफारसी आहेत. परंतु त्यांची अद्याप चाचणी झालेली नाही. तुमच्या फाइल सिस्टीमला पट्टीचा आकार आणि अॅरेमधील डिस्कची संख्या माहीत असल्याची खात्री करा. उदाहरणार्थ, हा raid5 अ‍ॅरे आहे ज्याचा आकार 64K सहा डिस्कचा आहे (वास्तविकपणे पाच, कारण एक डिस्क पॅरिटीसाठी वापरली जाते). या शिफारशी सैद्धांतिक गृहितकांवर आधारित आहेत आणि RAID तज्ञांद्वारे विविध ब्लॉग/लेखांमधून एकत्रित केल्या आहेत.

-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))

मोठ्या फाइल्ससाठी, तुम्ही वरील पट्टी आकार वाढविण्याचा विचार करू शकता.

सावधगिरी बाळगा! वर वर्णन केलेली प्रत्येक गोष्ट काही प्रकारच्या अनुप्रयोगांसाठी अत्यंत व्यक्तिनिष्ठ आहे. हा लेख वापरकर्त्याद्वारे संबंधित अनुप्रयोगांची प्रथम चाचणी केल्याशिवाय कोणत्याही सुधारणांची हमी देत ​​नाही. संपूर्ण प्रणाली प्रतिसाद सुधारण्याची आवश्यकता असल्यास किंवा वर्तमान समस्या सोडवल्यासच ते वापरावे.

अतिरिक्त साहित्य:

• dom.as/2008/02/05/linux-io-schedulers
• www.nextre.it/oracledocs/oraclemyths.html
• lkml.org/lkml/2006/11/15/40
• misterd77.blogspot.com/2007/11/3ware-hardware-raid-vs-linux-software.html

पुढे वाचा

• Red Hat Enterprise Linux 8 वर nftables वापरणे

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