GlusterFS को लागि लिनक्स कर्नेल सेटअप गर्दै

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

समय समयमा, यहाँ र त्यहाँ कर्नेल अनुकूलन सम्बन्धमा Gluster सिफारिसहरू र यो आवश्यक छ कि छैन भन्ने बारे प्रश्नहरू उठ्छन्।

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

धेरै जसो अवस्थामा यसले राम्रो काम गर्दछ, तर भारी भार अन्तर्गत यसले समस्या निम्त्याउन सक्छ।

हामीसँग धेरै मेमोरी खपत गर्ने प्रणालीहरूसँग काम गर्ने व्यापक अनुभव छ, जस्तै CAD, EDA र यस्तै, जसले उच्च भारमा ढिलो हुन थाल्यो। र कहिलेकाहीँ हामीले Gluster मा समस्याहरूको सामना गर्यौं। प्रयोग गरिएको मेमोरी र डिस्क प्रतिक्षा समयलाई एक दिन भन्दा बढी ध्यानपूर्वक अनुगमन गरेपछि, हामीले डिस्क ओभरलोड, विशाल आयोवेट, कर्नेल त्रुटिहरू (कर्नेल ओप्स), फ्रिजहरू, आदि पायौं।

यो लेख विभिन्न परिस्थितिहरूमा प्रदर्शन गरिएका धेरै प्यारामिटर ट्युनिङ प्रयोगहरूको परिणाम हो। यी प्यारामिटरहरूको लागि धन्यवाद, सामान्य रूपमा प्रतिक्रियाशीलता मात्र सुधारिएको छैन, तर क्लस्टरको सञ्चालन पनि महत्त्वपूर्ण रूपमा स्थिर भएको थियो।

जब यो मेमोरी कन्फिगर गर्ने कुरा आउँछ, हेर्नको लागि पहिलो स्थान भर्चुअल मेमोरी सबसिस्टम (VM) हो, जसमा धेरै संख्यामा विकल्पहरू छन् जसले तपाईंलाई भ्रमित गर्न सक्छ।

vm.swappiness

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

अदलाबदलीको व्यापक प्रयोग अवांछनीय छ, किनकि डेटाको विशाल ब्लकहरू RAM मा लोड र अनलोड हुन्छन्। धेरै मानिसहरू तर्क गर्छन् कि swapiness मूल्य उच्च हुनुपर्छ, तर मेरो अनुभवमा, यसलाई "0" मा सेट गर्दा राम्रो प्रदर्शनमा परिणामहरू छन्।

तपाईं यहाँ थप पढ्न सक्नुहुन्छ - lwn.net/Articles/100978

तर फेरि, यी सेटिङहरू सावधानीपूर्वक प्रयोग गर्नुपर्छ र केवल विशिष्ट अनुप्रयोग परीक्षण पछि। अत्यधिक लोड गरिएका स्ट्रिमिङ अनुप्रयोगहरूको लागि, यो प्यारामिटर "०" मा सेट गरिनुपर्छ। "0" मा परिवर्तन गर्दा, प्रणाली प्रतिक्रिया सुधार हुन्छ।

vm.vfs_cache_pressure

यो सेटिङले डाइरेक्टरी वस्तुहरू र इनोडहरू (डेन्ट्री र आइनोड) क्यासिङका लागि कर्नेलले खपत गरेको मेमोरीलाई नियन्त्रण गर्छ।

100 को पूर्वनिर्धारित मानको साथ, कर्नेलले डेन्ट्री र इनोड क्यासहरूलाई पृष्ठक्यास र स्वैपक्यासमा उचित तरिकाले मुक्त गर्ने प्रयास गर्नेछ। घट्दो vfs_cache_pressure ले कर्नेललाई डेन्ट्री र इनोड क्यासहरू जोगाउँछ। जब मान "0" हुन्छ, कर्नेलले मेमोरी दबाबको कारणले डेन्ट्री र इनोड क्यासलाई कहिल्यै फ्लश गर्दैन, र यसले सजिलैसँग मेमोरी बाहिर त्रुटि निम्त्याउन सक्छ। vfs_cache_pressure 100 माथि बढाउँदा कर्नेलले डेन्ट्री र इनोड पेजआउटहरूलाई प्राथमिकता दिन्छ।

GlusterFS प्रयोग गर्दा, धेरै मात्रामा डाटा र धेरै साना फाइलहरू भएका धेरै प्रयोगकर्ताहरूले सजिलैसँग सर्भरमा इनोड/डेन्ट्री क्यासिङको कारणले महत्त्वपूर्ण मात्रामा RAM प्रयोग गर्न सक्छन्, जसले गर्दा कर्नेलले प्रणालीमा डाटा संरचनाहरू ह्यान्डल गर्नुपर्ने हुनाले खराब प्रदर्शन हुन सक्छ। 40 GB मेमोरी संग। यो प्यारामिटरलाई १०० भन्दा बढीमा सेट गर्नाले धेरै प्रयोगकर्ताहरूलाई राम्रो क्यासिङ र सुधारिएको कर्नेल प्रतिक्रिया प्राप्त गर्न मद्दत गरेको छ।

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 नियन्त्रकको लागि "noop" प्रयोग गर्नु राम्रो हुन्छ, किनभने लिनक्सलाई डिस्कको भौतिक ज्यामितिको बारेमा केही थाहा छैन, त्यसैले डिस्क ज्यामिति राम्ररी जान्ने नियन्त्रकलाई अनुरोधलाई प्रशोधन गर्न दिनु अझ प्रभावकारी हुन्छ। सकेसम्म चाँडो। तर यस्तो देखिन्छ कि "डेडलाइन" ले प्रदर्शन सुधार गर्दछ। अनुसूचकहरूको बारेमा थप जानकारी लिनक्स कर्नेल स्रोत कोडको लागि कागजातमा फेला पार्न सकिन्छ: 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 नियन्त्रकको आन्तरिक लाम भन्दा २ गुणा ठूलो हुन्छ। प्रश्नहरू मर्ज र पुन: क्रमबद्ध गर्नाले अनुसूचकलाई भारी भार अन्तर्गत थप उत्तरदायी हुन मद्दत गर्दछ।

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

पृष्ठ-क्लस्टर प्यारामिटरले एक पटकमा स्वैपमा लेखिएका पृष्ठहरूको संख्या नियन्त्रण गर्दछ। माथिको उदाहरणमा, ६४ KB को RAID स्ट्रिप साइजसँग मेल खाने मान "16" मा सेट गरिएको छ। swappiness = 64 हुँदा यसले कुनै अर्थ राख्दैन, तर यदि तपाईंले 0 वा 10 मा swappiness सेट गर्नुभयो भने, RAID स्ट्रिप साइज 20 KB हुँदा यो मान प्रयोग गर्नाले तपाईंलाई मद्दत गर्नेछ।

blockdev --setra 4096 /dev/<devname> (-sdb, hdc वा 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))

ठूला फाइलहरूको लागि, तपाईंले माथिको पट्टी आकारहरू बढाउने विचार गर्न सक्नुहुन्छ।

ATTENTION! माथि वर्णन गरिएको सबै केहि प्रकारका अनुप्रयोगहरूको लागि अत्यन्त व्यक्तिपरक छ। यस लेखले प्रयोगकर्ताद्वारा सम्बन्धित अनुप्रयोगहरूको परीक्षण नगरी कुनै पनि सुधारको ग्यारेन्टी गर्दैन। यो मात्र प्रयोग गरिनु पर्छ यदि त्यहाँ समग्र प्रणाली प्रतिक्रियाशीलता सुधार गर्न आवश्यक छ वा यदि यसले वर्तमान समस्याहरू समाधान गर्दछ।

थप सामग्रीहरू:

• 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