GlusterFS के लिए Linux कर्नेल की स्थापना

पाठ्यक्रम की शुरुआत की पूर्व संध्या पर लेख का अनुवाद तैयार किया गया था व्यवस्थापक लिनक्स। पेशेवर".

समय-समय पर, यहाँ और वहाँ, कर्नेल ट्यूनिंग के बारे में ग्लस्टर की सिफारिशों के बारे में प्रश्न उठते हैं और क्या इसकी आवश्यकता है।

ऐसी आवश्यकता विरले ही उत्पन्न होती है। अधिकांश कार्यभार पर, कर्नेल बहुत अच्छा प्रदर्शन करता है। हालांकि एक नकारात्मक पहलू है। ऐतिहासिक रूप से, लिनक्स कर्नेल प्रदर्शन में सुधार के मुख्य तरीके के रूप में कैशिंग सहित अवसर दिए जाने पर बहुत अधिक मेमोरी का उपभोग करने के लिए तैयार रहा है।

ज्यादातर मामलों में, यह ठीक काम करता है, लेकिन भारी भार के तहत यह समस्या पैदा कर सकता है।

हमारे पास CAD, EDA और इसी तरह की मेमोरी इंटेंसिव सिस्टम के साथ बहुत अनुभव है, जो भारी भार के तहत धीमा होने लगा। और कभी-कभी हमें ग्लस्टर में समस्याएँ आईं। कई दिनों तक मेमोरी उपयोग और डिस्क विलंबता को ध्यान से देखने के बाद, हमें उनका अधिभार, विशाल आयवेट, कर्नेल त्रुटियाँ (कर्नेल उफ़), फ़्रीज़, आदि मिलीं।

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

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

वी.एम.स्वैपीनेस

प्राचल vm.swappiness यह निर्धारित करता है कि RAM की तुलना में कर्नेल स्वैप (स्वैप, पेजिंग) का कितना उपयोग करता है। इसे सोर्स कोड में "मैप्ड मेमोरी चुराने की प्रवृत्ति" के रूप में भी परिभाषित किया गया है। एक उच्च स्वैपीनेस का अर्थ है कि कर्नेल मैप किए गए पृष्ठों को स्वैप करने के लिए अधिक इच्छुक होगा। एक कम स्वैपीनेस मान का अर्थ विपरीत है: कर्नेल स्मृति से पृष्ठ कम करेगा। दूसरे शब्दों में, उच्च मूल्य vm.swappiness, जितना अधिक सिस्टम स्वैप का उपयोग करेगा।

अदला-बदली का एक बड़ा उपयोग अवांछनीय है, क्योंकि डेटा के विशाल ब्लॉक रैम में लोड और अनलोड किए जाते हैं। बहुत से लोग तर्क देते हैं कि स्वेपनेस वैल्यू बड़ी होनी चाहिए, लेकिन मेरे अनुभव में, इसे "0" पर सेट करने से बेहतर प्रदर्शन होता है।

आप यहां और अधिक पढ़ सकते हैं - lwn.net/Articles/100978

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

vm.vfs_cache_press

यह सेटिंग कैशिंग डायरेक्टरी और इनोड ऑब्जेक्ट्स (डेंट्री और इनोड) के लिए कर्नेल द्वारा उपयोग की जाने वाली मेमोरी को नियंत्रित करती है।

100 के डिफ़ॉल्ट मान के साथ, कर्नेल डेंट्री और इनोड कैश को "निष्पक्ष" आधार पर पेजकैश और स्वैपकैच से मुक्त करने का प्रयास करेगा। vfs_cache_दबाव को कम करने से कर्नेल को डेंट्री और इनोड कैश रखने का कारण बनता है। जब मान "0" होता है, तो मेमोरी प्रेशर के कारण कर्नेल कभी भी डेंट्री और इनोड कैश को फ्लश नहीं करेगा, और यह आसानी से आउट-ऑफ-मेमोरी त्रुटि का कारण बन सकता है। vfs_cache_दबाव को 100 से ऊपर बढ़ाने से कर्नेल डेंट्री और इनोड फ्लशिंग को प्राथमिकता देता है।

GlusterFS का उपयोग करते समय, बड़ी मात्रा में डेटा और कई छोटी फ़ाइलों वाले कई उपयोगकर्ता इनोड/डेंट्री कैशिंग के कारण सर्वर पर बड़ी मात्रा में रैम का आसानी से उपयोग कर सकते हैं, जिससे प्रदर्शन में गिरावट आ सकती है क्योंकि कर्नेल को सिस्टम पर डेटा संरचनाओं को संसाधित करना पड़ता है। 40 जीबी मेमोरी के साथ। इस मान को 100 से ऊपर सेट करने से कई उपयोगकर्ताओं को बेहतर कैशिंग और बेहतर कर्नेल जवाबदेही प्राप्त करने में मदद मिली है।

vm.dirty_background_ratio और vm.dirty_ratio

पहला पैरामीटर (vm.dirty_background_ratio) गंदे पृष्ठों के साथ मेमोरी का प्रतिशत निर्धारित करता है, जिस पर पहुंचने के बाद पृष्ठभूमि में गंदे पृष्ठों को डिस्क में फ्लश करना शुरू करना आवश्यक है। जब तक यह प्रतिशत पूरा नहीं हो जाता, तब तक डिस्क में कोई पृष्ठ नहीं फ़्लश किया जाता है। और जब रीसेट शुरू होता है, तो यह चल रही प्रक्रियाओं को बाधित किए बिना पृष्ठभूमि में चलता है।

दूसरा पैरामीटर (vm.dirty_ratio) उस मेमोरी के प्रतिशत को परिभाषित करता है जिसे जबरन फ्लैश शुरू होने से पहले गंदे पेजों द्वारा कब्जा किया जा सकता है। एक बार जब यह सीमा समाप्त हो जाती है, तो सभी प्रक्रियाएँ समकालिक (अवरुद्ध) हो जाती हैं और उन्हें तब तक जारी रखने की अनुमति नहीं दी जाती है जब तक कि उनके द्वारा अनुरोधित I/O वास्तव में पूरा नहीं हो जाता है और डेटा डिस्क पर होता है। भारी I/O के साथ, यह एक समस्या का कारण बनता है क्योंकि कोई डेटा कैशिंग नहीं है और I/O करने वाली सभी प्रक्रियाएँ I/O की प्रतीक्षा में अवरुद्ध हैं। यह बड़ी संख्या में त्रिशंकु प्रक्रियाओं, उच्च भार, सिस्टम अस्थिरता और खराब प्रदर्शन की ओर जाता है।

इन सेटिंग्स को कम करने से डेटा को डिस्क में अधिक बार फ़्लश किया जाता है और रैम में संग्रहीत नहीं किया जाता है। यह मेमोरी-हैवी सिस्टम की मदद कर सकता है जहां 45-90 जीबी पेज कैश को डिस्क में फ्लश करना सामान्य है, जिसके परिणामस्वरूप फ्रंट-एंड एप्लिकेशन के लिए भारी विलंबता होती है, जिससे समग्र जवाबदेही और अन्तरक्रियाशीलता कम हो जाती है।

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

एक पृष्ठ कैश एक कैश है जो फ़ाइलों और निष्पादन योग्य प्रोग्रामों के डेटा को संग्रहीत करता है, अर्थात ये फ़ाइलों या ब्लॉक उपकरणों की वास्तविक सामग्री वाले पृष्ठ हैं। डिस्क रीड की संख्या को कम करने के लिए इस कैश का उपयोग किया जाता है। "1" के मान का अर्थ है कि 1% RAM का उपयोग कैश के लिए किया जाता है और RAM की तुलना में डिस्क से अधिक रीड होंगे। इस सेटिंग को बदलना आवश्यक नहीं है, लेकिन यदि आप पेज कैश को नियंत्रित करने के बारे में पागल हैं, तो आप इसका उपयोग कर सकते हैं।

"समय सीमा"> /sys/block/sdc/queue/scheduler

I/O अनुसूचक एक लिनक्स कर्नेल घटक है जो पढ़ने और लिखने की कतारों को संभालता है। सिद्धांत रूप में, स्मार्ट RAID नियंत्रक के लिए "नोप" का उपयोग करना बेहतर है, क्योंकि लिनक्स डिस्क की भौतिक ज्यामिति के बारे में कुछ नहीं जानता है, इसलिए नियंत्रक को जाने देना अधिक कुशल है, जो डिस्क ज्यामिति को अच्छी तरह से जानता है, अनुरोध को जितनी जल्दी हो सके संसाधित करें। संभव। लेकिन ऐसा लगता है कि "समय सीमा" प्रदर्शन में सुधार करती है। आप Linux कर्नेल स्रोत कोड प्रलेखन में अनुसूचकों के बारे में अधिक पढ़ सकते हैं: linux/Documentation/block/*osched.txt. और मैंने मिश्रित संचालन (कई लिखने के संचालन) के दौरान रीड थ्रूपुट में भी वृद्धि देखी है।

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

शेड्यूलर को भेजे जाने से पहले बफर में I/O अनुरोधों की संख्या। कुछ नियंत्रकों की आंतरिक कतार का आकार (कतार_गहराई) I/O अनुसूचक के nr_requests से बड़ा है, इसलिए I/O अनुसूचक के पास अनुरोधों को ठीक से प्राथमिकता देने और विलय करने की बहुत कम संभावना है। समय सीमा और CFQ अनुसूचकों के लिए, यह बेहतर है जब nr_requests नियंत्रक की आंतरिक कतार से 2 गुना अधिक हो। विलय और पुन: व्यवस्थित करने के अनुरोधों से अनुसूचक को भारी भार के तहत अधिक उत्तरदायी होने में मदद मिलती है।

इको "16" > /proc/sys/vm/page-cluster

पेज-क्लस्टर पैरामीटर उन पेजों की संख्या को नियंत्रित करता है जो एक बार में स्वैप के लिए लिखे जाते हैं। उपरोक्त उदाहरण में, 16 KB के RAID स्ट्राइप आकार के अनुसार मान "64" पर सेट है। यह स्वैपीनेस = 0 के साथ समझ में नहीं आता है, लेकिन यदि आप स्वैपनेस को 10 या 20 पर सेट करते हैं तो इस मान का उपयोग करने से आपको मदद मिलेगी जब RAID स्ट्राइप का आकार 64K है।

ब्लॉकदेव --सेटरा 4096 / देव /<देवनाम> (-एसडीबी, एचडीसी या dev_mapper)

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

फ़ाइल सिस्टम स्तर पर नीचे कुछ और सुझाव दिए गए हैं। लेकिन अभी तक उनका परीक्षण नहीं किया गया है। सुनिश्चित करें कि आपका फाइल सिस्टम पट्टी के आकार और सरणी में डिस्क की संख्या जानता है। उदाहरण के लिए, यह छह डिस्क की 5K धारी RAID64 सरणी है (वास्तव में पांच, क्योंकि एक डिस्क का उपयोग समता के लिए किया जाता है)। ये सिफारिशें सैद्धांतिक मान्यताओं पर आधारित हैं और 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-अनुसूचक
• 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