लिनक्स - वास्तविक दुनिया हार्डवेयर RAID नियंत्रक ट्यूनिंग (scsi और cciss)

Question

अधिकांश लिनक्स सिस्टम मैं फीचर हार्डवेयर RAID नियंत्रक (ज्यादातर एचपी स्मार्ट एरे ) का प्रबंधन करता है। वे सभी RHEL या CentOS चला रहे हैं।

मैं सेटअप के लिए प्रदर्शन को अनुकूलित करने में मदद करने के लिए वास्तविक-विश्व ट्यूनबल्स की तलाश कर रहा हूं जो एसएएस डिस्क (स्मार्ट एरे, पर्क, एलएसआई, आदि) और बैटरी-समर्थित या फ्लैश-समर्थित कैश के साथ हार्डवेयर RAID नियंत्रकों को शामिल करता है। RAID 1 + 0 और कई स्पिंडल (4+ डिस्क) मान लें।

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

ऐतिहासिक रूप से, मैंने अपने अनुप्रयोगों के भीतर प्रदर्शन में सुधार करने के लिए हाल ही में और शेड्यूलर्स का चयन करते हुए I / O शेड्यूलिंग एलेवेटर में बदलाव किए हैं । जैसा कि आरएचईएल संस्करण आगे बढ़ चुके हैं, मैंने यह भी देखा है कि एससीएसआई और सीसीआईएस ब्लॉक उपकरणों के लिए संकलित-इन डिफॉल्ट भी बदल गए हैं। समय के साथ अनुशंसित स्टोरेज सबसिस्टम सेटिंग्स पर इसका प्रभाव पड़ा है। हालाँकि, कुछ समय बाद मैंने स्पष्ट सिफारिशें देखीं। और मुझे पता है कि ओएस डिफॉल्ट इष्टतम नहीं हैं। उदाहरण के लिए, ऐसा लगता है कि सर्वर-क्लास हार्डवेयर पर तैनाती के लिए 128kb का डिफ़ॉल्ट रीड-फॉरवर्ड बफर बेहद छोटा है।deadlinenoop

निम्नलिखित लेख ब्लॉक कतारों पर रीड- फॉरवर्ड कैश और nr_requests मानों के प्रदर्शन प्रभाव का पता लगाते हैं।

http://zackreed.me/articles/54-hp-smart-array-p410-controller-tuning
http://www.overclock.net/t/515068/tuning-a-hp-smart-array -p400- with -लिनक्स-क्यों-ट्यूनिंग-वास्तव में मायने रखता है
http://yoshinorimatsunobu.blogspot.com/2009/04/linux-io-scheduler-queue-size-and.html

उदाहरण के लिए, ये HP स्मार्ट एरे RAID नियंत्रक के लिए सुझाए गए परिवर्तन हैं:

echo "noop" > /sys/block/cciss\!c0d0/queue/scheduler 
blockdev --setra 65536 /dev/cciss/c0d0
echo 512 > /sys/block/cciss\!c0d0/queue/nr_requests
echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb

भंडारण प्रदर्शन को बेहतर बनाने के लिए और क्या सुनिश्चित किया जा सकता है?
मैं विशेष रूप से उत्पादन परिदृश्यों में sysctl और sysfs विकल्पों की तलाश कर रहा हूं।

Answer 1

मैंने पाया है कि जब मुझे कम विलंबता बनाम थ्रूपुट के लिए ट्यून करना पड़ता है, तो मैंने nr_requests को डिफ़ॉल्ट (32 तक कम) के रूप में नीचे से ट्यून किया है। छोटे बैचों का विचार निम्न विलंबता के बराबर होता है।

इसके अलावा read_ahead_kb के लिए मैंने पाया है कि अनुक्रमिक पढ़ने / लिखने के लिए, इस मूल्य को बढ़ाने से बेहतर थ्रूपुट प्रदान करता है, लेकिन मैंने पाया है कि यह विकल्प वास्तव में आपके कार्यभार और IO पैटर्न पर निर्भर करता है। उदाहरण के लिए एक डेटाबेस सिस्टम पर जो मैंने हाल ही में ट्यून किया है, मैंने इस मान को एक db पेज के आकार से मिलान करने के लिए बदल दिया, जिससे रीड लेटेंसी को कम करने में मदद मिली। इस मूल्य से आगे बढ़ना या घटाना मेरे मामले में प्रदर्शन को चोट पहुंचाने वाला साबित हुआ।

ब्लॉक उपकरण कतारों के लिए अन्य विकल्पों या सेटिंग्स के लिए:

max_sectors_kb = मैंने यह मान मिलान करने के लिए सेट किया है कि हार्डवेयर एक हस्तांतरण के लिए क्या अनुमति देता है (sysfs में max_hw_sectors_kb (RO) फ़ाइल का मान देखें कि क्या अनुमति है)

nomerges = इससे आप io अनुरोधों को मर्ज करने के लिए लुकअप लॉजिक को अक्षम या समायोजित कर सकते हैं। (इसे बंद करने से आप कुछ सीपीयू चक्रों को बचा सकते हैं, लेकिन मैंने अपने सिस्टम के लिए इसे बदलते समय कोई लाभ नहीं देखा है, इसलिए मैंने इसे छोड़ दिया है।

rq_affinity = मैंने अभी तक इसकी कोशिश नहीं की है, लेकिन यहाँ कर्नेल डॉक्स से इसके पीछे का स्पष्टीकरण दिया गया है

यदि यह विकल्प '1' है, तो ब्लॉक लेयर मूल रूप से अनुरोध सबमिट करने वाले सीपीयू "समूह" के लिए अनुरोधों को पूरा कर देगी। कुछ वर्कलोड के लिए यह कैशिंग प्रभाव के कारण सीपीयू चक्रों में एक महत्वपूर्ण कमी प्रदान करता है।
भंडारण कॉन्फ़िगरेशन के लिए जिसे पूरा करने के लिए '2' विकल्प को पूरा करने की प्रक्रिया को पूरा करने की आवश्यकता है, यह अनुरोध सीपीयू ("समूह" एकत्रीकरण तर्क को दरकिनार) पर चलाने के लिए पूरा करता है।

अनुसूचक = आपने कहा कि आपने समय सीमा और शून्य की कोशिश की। मैंने noop और deadline दोनों का परीक्षण किया है, लेकिन मैंने डेटाबेस सर्वर के लिए हाल ही में जो परीक्षण किया है, उसके लिए समय-सीमा की जीत पाई है।

NOOP ने अच्छा प्रदर्शन किया, लेकिन हमारे डेटाबेस सर्वर के लिए मैं अभी भी समय सीमा अनुसूचक को समायोजित करते हुए बेहतर प्रदर्शन प्राप्त करने में सक्षम था।

/ Sys / block / {sd, cciss, dm -} * / कतार / iosched / के तहत स्थित समय सीमा अनुसूचक के लिए विकल्प:

पंद्रह_बैच = nr_requests की तरह, लेकिन अनुसूचक के लिए विशिष्ट। अंगूठे का नियम कम विलंबता के लिए या थ्रूपुट के लिए इसे नीचे ट्यून कर रहा है। पढ़ने और लिखने के अनुरोधों के बैच आकार को नियंत्रित करता है।

write_expire = सेट करने का समय समाप्त होता है लिखने के लिए मूलभूत डिफ़ॉल्ट 5000ms है। एक बार फिर से इस मूल्य में कमी करने से आपके लिखने की अवधि कम हो जाती है जबकि मूल्य वृद्धि थ्रूपुट बढ़ जाती है।

read_expire = सेट के लिए समय समाप्त हो जाता है पढ़ने बैच डिफ़ॉल्ट 500ms है। वही नियम यहाँ लागू होते हैं।

front_merges = मैं इसे बंद करना चाहता हूं, और यह डिफ़ॉल्ट रूप से चालू है। IO अनुरोधों को सामने लाने के प्रयास में cpu को बर्बाद करने के लिए मुझे अनुसूचक की आवश्यकता नहीं दिखती है।

write_starved = चूँकि समय सीमा तय की गई है इसलिए डिफ़ॉल्ट को यहाँ लिखा हुआ बैच लिखने से पहले 2 रीड बैचों को प्रोसेस करना है। मैंने अपने कार्यभार के लिए 2 का डिफ़ॉल्ट पाया।

Comments

... और यह है कि आप किसी साइट पर अपना पहला उत्तर कैसे पोस्ट करते हैं। बहुत बढ़िया!

— जेफ फेरलैंड

यह एक अच्छी शुरुआत है और नियंत्रित परिस्थितियों में बार-बार परीक्षण चलाने से मुझे आवेदन प्रदर्शन को थोड़ा और बेहतर बनाने में मदद मिली है। यह देखने के लिए भी उपयोगी है कि मैं सामान्य वर्कलोड रुझानों के लिए भंडारण को कैसे ट्यून कर सकता हूं।

— इविहित

Answer 2

किसी भी चीज़ से अधिक, सब कुछ आपके कार्यभार पर निर्भर करता है।

read_ahead_kbअगर यह वास्तव में समय से पहले किसी फ़ाइल से बहुत सारे डेटा को पढ़ने के लिए मददगार है, तो यह आपकी मदद कर सकता है, जैसे वीडियो स्ट्रीमिंग करते समय। कभी-कभी यह आपको बुरी तरह से चोट पहुंचा सकता है। हां, डिफ़ॉल्ट 128 केबी छोटे की तरह ध्वनि कर सकता है, लेकिन पर्याप्त संगामिति के साथ यह बड़ा लगता है! दूसरी ओर, एक सर्वर जैसे कि वीडियो एन्कोडिंग सर्वर जो केवल एक प्रारूप से दूसरे में वीडियो परिवर्तित करता है, जो धुन करने के लिए बहुत अच्छा विचार हो सकता है।

nr_requests, जब overtuned, आसानी से अपने RAID नियंत्रक को बाढ़ सकता है, जो फिर से प्रदर्शन को नुकसान पहुंचाता है।

वास्तविक दुनिया में, आपको विलंबता देखने की आवश्यकता है । यदि आप सैन से जुड़े हैं, तो एक नज़र डालें iostat, sarया आप जो भी उपयोग करना चाहते हैं, और देखें कि क्या मैं / ओ अनुरोध सेवा समय छत के माध्यम से कर रहे हैं। बेशक, यह स्थानीय डिस्क के साथ भी मदद करता है: यदि विलंबता बहुत बड़ी है, तो अपने I / O लिफ्ट सेटिंग्स को max_requests और अन्य सेटिंग्स को अपग्रेड करके नीचे ट्यूनिंग पर विचार करें।

Comments

कौन सी अन्य सेटिंग्स?

— इविहित

Answer 3

FYI करें read_ahead_kbऔर blockdev --setraबस कर रहे हैं विभिन्न इकाइयों का उपयोग कर एक ही सेटिंग सेट करने के लिए अलग अलग तरीकों (kB क्षेत्रों बनाम):

foo:~# blockdev --setra 65536 /dev/cciss/c0d0
foo:~# blockdev --getra /dev/cciss/c0d0
65536
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
32768
foo:~# echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
2048
foo:~# blockdev --getra /dev/cciss/c0d0
4096

ऐसा

blockdev --setra 65536 /dev/cciss/c0d0

आपके उदाहरण में कोई प्रभाव नहीं है।