अमूर्त : वर्तमान प्रदर्शन और सैद्धांतिक प्रदर्शन के बीच का अंतर; विलंबता और IOPS, डिस्क लोड स्वतंत्रता की अवधारणा; परीक्षण की तैयारी; विशिष्ट परीक्षण पैरामीटर; व्यावहारिक नकल।

चेतावनी: कई पत्र, लंबे समय से पढ़ा।

गीत

एक बहुत ही सामान्य समस्या यह समझने का प्रयास है कि "सर्वर कितना तेज है?" सभी परीक्षणों के बीच, डिस्क सबसिस्टम के प्रदर्शन का मूल्यांकन करने के लिए सबसे दयनीय प्रयास। यहाँ मैं अपने जीवन में देखी गई भयावहताएँ देख रहा हूँ:

एक वैज्ञानिक प्रकाशन जिसमें क्लस्टर एफएस गति का मूल्यांकन dd का उपयोग करके किया गया था (और फ़ाइल कैश सक्षम किया गया है, अर्थात, प्रत्यक्ष विकल्प के बिना)
bonnie ++ का उपयोग करना
iozone का उपयोग करना
रनटाइम माप के साथ सीपी बंडलों का उपयोग करना
64-बिट सिस्टम पर डायनेमो के साथ आयमीटर का उपयोग करना

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

bonnie ++ और iozone फ़ाइल सिस्टम स्पीड को मापते हैं। जो कैश पर निर्भर करता है, कर्नेल की विचारशीलता, डिस्क पर FS स्थान की सफलता आदि। अप्रत्यक्ष रूप से, आप कह सकते हैं कि यदि आपको iozone में अच्छे परिणाम मिले हैं, तो यह या तो एक अच्छा कैश है, या मापदंडों का एक बेवकूफ सेट है, या वास्तव में तेज़ डिस्क (आपको कौन सा विकल्प मिला है)। बोनी ++ आमतौर पर फ़ाइल ओपन / क्लोज ऑपरेशंस पर केंद्रित है। यानी वह विशेष रूप से डिस्क प्रदर्शन का परीक्षण नहीं करती है।

प्रत्यक्ष विकल्प के बिना dd केवल कैश गति दिखाता है - और नहीं। कुछ कॉन्फ़िगरेशन में, आप कैश के बिना कैश की तुलना में रैखिक गति प्राप्त कर सकते हैं। कुछ में आपको मेगाबाइट की इकाइयों में रैखिक प्रदर्शन के साथ प्रति सेकंड सैकड़ों मेगाबाइट प्राप्त होंगे।

प्रत्यक्ष विकल्प के साथ (iflag = Direct for reading, oflag = direct for writing) dd केवल रैखिक गति के लिए जाँच करता है। जो या तो अधिकतम गति के बराबर नहीं है (यदि हम कई डिस्क पर छापा मारते हैं, तो कई धाराओं में छापे एक से अधिक गति दे सकते हैं), या वास्तविक प्रदर्शन।

IOmeter सबसे अच्छा है, लेकिन इसमें लिनक्स पर काम करने में समस्याएं हैं। 64-बिट संस्करण लोड के प्रकार की सही गणना नहीं करता है और कम करके आंका गया परिणाम दिखाता है (उन लोगों के लिए जो विश्वास नहीं करते हैं, इसे रैमडिस्क पर चलाते हैं)।

स्पॉयलर: लिनक्स के लिए सही उपयोगिता फियो है। लेकिन इसके लिए परीक्षण की बहुत सोचनीय तैयारी और परिणामों का और भी अधिक विचारशील विश्लेषण की आवश्यकता है। यह सब नीचे है, केवल थियो के साथ काम करने पर सिद्धांत और व्यावहारिक नोट्स की तैयारी है।

समस्या का बयान

(वर्तमान वी.एस. अधिकतम प्रदर्शन)
अब और भी उबाऊ पत्र होंगे। अगर किसी को अपने पसंदीदा SSD'shka, लैपटॉप स्क्रू, आदि पर तोते की संख्या में दिलचस्पी है। - लेख के अंत में व्यंजनों को देखें।

रैमडिस्क को छोड़कर सभी आधुनिक मीडिया में यादृच्छिक लेखन कार्यों के लिए बहुत नकारात्मक रवैया है। एचडीडी के लिए लिखने या पढ़ने के बीच कोई अंतर नहीं है, यह महत्वपूर्ण है कि सिर डिस्क पर ड्राइव करें। SSD के लिए, हालाँकि, बकवास पढ़ने का यादृच्छिक संचालन, लेकिन एक छोटे से ब्लॉक के साथ लिखने से कॉपी-ऑन-राइट हो जाता है। न्यूनतम रिकॉर्डिंग आकार 1-2 एमबी है, वे 4kb लिखते हैं। आपको 2 एमबी पढ़ने की ज़रूरत है, उन्हें 4KB से बदल दें और वापस लिखें। नतीजतन, उदाहरण के लिए, एसएसडी के 4kb लिखने के लिए प्रति सेकंड 400 अनुरोध जो 800 एमबी / एस (!!!!) पढ़ने और उन्हें वापस लिखने में बदल जाते हैं। (रैमडिस्क के लिए, इस तरह की समस्या समान हो सकती है, लेकिन साज़िश यह है कि डीडीआर के लिए "न्यूनतम ब्लॉक" का आकार लगभग 128 बाइट्स है, और परीक्षणों में ब्लॉक आमतौर पर 4 केबी हैं, इसलिए रैम डिस्क प्रदर्शन के परीक्षणों में डीडीआर की ग्रैन्युलैरिटी महत्वपूर्ण नहीं है) ।

यह पोस्ट विभिन्न मीडिया की बारीकियों के बारे में नहीं है, इसलिए सामान्य समस्या पर वापस जाएं।

हम Mb / s में प्रविष्टि को माप नहीं सकते। महत्वपूर्ण बात यह है कि कितने हेड मूवमेंट थे, और कितने यादृच्छिक ब्लॉक हमने एसएसडी पर परेशान किए। यानी खाता IO परिचालनों की संख्या तक जाता है, और IO / s का मान IOPS कहलाता है। इस प्रकार, जब हम एक यादृच्छिक भार को मापते हैं, तो हम IOPS के बारे में बात कर रहे हैं (कभी-कभी लिखने और पढ़ने के लिए wIOPS, rIOPS, क्रमशः)। बड़ी प्रणालियों में, वे kIOPS मान का उपयोग करते हैं, (ध्यान, हमेशा और हर जगह, कोई 1024) 1kIOPS = 1000 IOPS।

और यहाँ, कई पहले प्रकार के जाल में गिर जाते हैं। वे जानना चाहते हैं कि ड्राइव कितने IOPS को दे रहा है। या एक डिस्क शेल्फ। या 200 सर्वर अलमारियाँ कवर के नीचे डिस्क के साथ भरवां।

प्रदर्शन किए गए संचालन की संख्या के बीच अंतर करना महत्वपूर्ण है (यह दर्ज किया गया है कि 12:00:15 से 12:00:16 तक 245790 डिस्क संचालन किया गया था - अर्थात, लोड 245kIOPS था) और सिस्टम अधिकतम संचालन कैसे कर सकता है।

प्रदर्शन किए गए ऑपरेशनों की संख्या हमेशा ज्ञात होती है और मापना आसान होता है। लेकिन जब हम डिस्क ऑपरेशन के बारे में बात करते हैं, तो हम भविष्य के तनाव के बारे में बात करते हैं। "सिस्टम कितने ऑपरेशन कर सकता है?" - "क्या संचालन?" अलग-अलग ऑपरेशन स्टोरेज सिस्टम पर अलग लोड देते हैं। उदाहरण के लिए, यदि कोई 1 एमबी के यादृच्छिक ब्लॉक में लिखता है, तो उसे 4 केबी के ब्लॉक में क्रमिक रूप से पढ़ने की तुलना में बहुत कम आईपीएस प्राप्त होगा।

और अगर लोड के मामले में हम कितने अनुरोधों के बारे में बात कर रहे हैं "जो आए, उन्होंने सेवा की," तो नियोजन के मामले में, हम जानना चाहते हैं कि कौन सा आईओपीएस होगा।

नाटक यह है कि किसी को नहीं पता कि किस तरह के अनुरोध आएंगे। छोटे वाले? बड़े वाले? अनुबंध? असहमति में? क्या वे कैश से पढ़े जाएंगे या आपको सबसे धीमी जगह पर जाना होगा और डिस्क के विभिन्न हिस्सों से बाइट्स को चुनना होगा?

मैं नाटक को आगे नहीं बढ़ाऊंगा, मैं कहूंगा कि एक सरल उत्तर है:

सर्वश्रेष्ठ मामले के लिए डिस्क परीक्षण (भंडारण / सरणी) (हिट कैश, अनुक्रमिक संचालन)
सबसे खराब स्थिति के लिए डिस्क परीक्षण। अधिकतर, डिस्क डिवाइस के ज्ञान के साथ ऐसे परीक्षणों की योजना बनाई जाती है। "क्या यह 64MB कैश है?" यदि मैं परीक्षण क्षेत्र 2GB का आकार बनाऊँ तो क्या होगा? " क्या हार्ड ड्राइव ड्राइव के बाहर से तेजी से पढ़ता है? और अगर मैं परीक्षण क्षेत्र को अंदरूनी (स्पिंडल के सबसे करीब) क्षेत्र पर रखता हूं, तो सिर के द्वारा यात्रा की जाने वाली राह अधिक है? क्या उसने आगे की भविष्यवाणी पढ़ी है? और अगर मैं रिवर्स ऑर्डर में पढ़ूं? आदि

परिणामस्वरूप, हमें नंबर मिलते हैं, जिनमें से प्रत्येक गलत है। उदाहरण के लिए: 15kIOPS और 150 IOPS।

वास्तविक प्रणाली का प्रदर्शन क्या होगा? यह केवल इस बात से निर्धारित होता है कि लोड कितना अच्छा और बुरा अंत होगा। (अर्थात्, "जीवन दिखाएगा" भोज)।

अक्सर वे निम्नलिखित संकेतकों पर ध्यान केंद्रित करते हैं:

यह सबसे अच्छा मामला अभी भी सबसे अच्छा है। क्योंकि आप इस तरह का अनुकूलन कर सकते हैं कि सबसे खराब से सबसे अच्छा मामला शायद ही अलग होगा। यह बुरा है (अच्छी तरह से, या हमारे पास इतना भयानक सबसे खराब है)।
सबसे खराब पर। इसके पास, हम कह सकते हैं कि प्राप्त आंकड़ों की तुलना में भंडारण प्रणाली तेजी से काम करेगी। यानी यदि हमें 3000 IOPS मिले हैं, तो हम "2000 तक" लोड में सिस्टम / डिस्क का सुरक्षित रूप से उपयोग कर सकते हैं।

खैर, ब्लॉक आकार के बारे में। परंपरागत रूप से, परीक्षण 4k के ब्लॉक आकार के साथ आता है। क्यों? क्योंकि यह फ़ाइल को सहेजते समय ओएस द्वारा उपयोग किया जाने वाला मानक ब्लॉक आकार है। यह मेमोरी पेज का आकार है और सामान्य तौर पर, वेरी राउंड कंप्यूटर नंबर।

आपको यह समझने की आवश्यकता है कि यदि सिस्टम 4k ब्लॉक (सबसे खराब) के साथ 100 IOPS को संसाधित करता है, तो यह 8k ब्लॉक (कम से कम 50 IOPS, सबसे अधिक संभावना 70-80 के आसपास) के साथ कम प्रक्रिया करेगा। खैर, 1 एमबी ब्लॉक पर हम पूरी तरह से अलग संख्या देखेंगे।

क्या वह सब है? नहीं, यह सिर्फ एक परिचय था। जो कुछ ऊपर लिखा गया है वह कमोबेश सर्वविदित है। गैर-तुच्छ चीजें नीचे से शुरू होती हैं।

सबसे पहले, हम "आश्रित IOPSs" की अवधारणा को देखेंगे। कल्पना कीजिए कि हमारा आवेदन इस तरह काम करता है:

रिकॉर्ड पढ़ें
रिकॉर्ड बदलें
वापस लिखो

सुविधा के लिए, हम मानते हैं कि प्रसंस्करण समय शून्य है। यदि प्रत्येक पढ़ने और लिखने का अनुरोध 1ms के लिए सेवित किया जाएगा, तो प्रति सेकंड कितने रिकॉर्ड आवेदन प्रक्रिया कर सकते हैं? यह सही है, 500. और यदि हम आवेदन की दूसरी प्रति के बगल में लॉन्च करते हैं? किसी भी सभ्य प्रणाली में, हम 1000 प्राप्त करते हैं। यदि हम 1000 से काफी कम प्राप्त करते हैं, तो हम सिस्टम प्रदर्शन की सीमा तक पहुंच गए हैं। यदि नहीं, तो इसका मतलब है कि आश्रित आईओपीएस के साथ एक आवेदन का प्रदर्शन स्टोरेज प्रदर्शन द्वारा सीमित नहीं है, लेकिन दो मापदंडों द्वारा: विलंबता और आईओपीएस निर्भरता का स्तर।

चलो विलंबता के साथ शुरू करते हैं। विलंबता - निष्पादन का समय, प्रतिक्रिया से पहले विलंब। आमतौर पर मूल्य का उपयोग करें, "औसत देरी।" अधिक उन्नत व्यक्ति एक निश्चित अंतराल (ज्यादातर 1s के लिए) के लिए सभी कार्यों के बीच माध्यिका का उपयोग करते हैं। लेटेंसी को मापना बहुत मुश्किल है। यह इस तथ्य के कारण है कि किसी भी भंडारण प्रणाली पर, अनुरोधों का हिस्सा जल्दी से निष्पादित होता है, भाग धीमा होता है, और कुछ बेहद अप्रिय स्थिति में पहुंच सकते हैं और बाकी की तुलना में लंबे समय तक दसियों बार सेवित हो सकते हैं।

साज़िश को अनुरोधों की एक कतार की उपस्थिति से प्रबलित किया जाता है, जिसके भीतर अनुरोधों की पुनरावृत्ति और उनके समानांतर निष्पादन को अंजाम दिया जा सकता है। एक नियमित SATA ड्राइव में कतार की गहराई (NCQ) 31 है, और शक्तिशाली भंडारण प्रणाली कई हजार तक पहुंच सकती है। (ध्यान दें कि कतार की वास्तविक लंबाई (पूर्ण होने की प्रतीक्षा कर रहे अनुरोधों की संख्या) एक नकारात्मक पैरामीटर है, अगर कतार में बहुत सारे अनुरोध हैं, तो वे लंबे समय तक प्रतीक्षा करते हैं, अर्थात् धीमी गति से। सुपरमार्केट में भीड़ घंटे में खड़े किसी भी व्यक्ति को सहमत होगा कि अब। कतार, सेवा कम है।

विलंबता सीधे धारावाहिक अनुप्रयोग के प्रदर्शन को प्रभावित करती है, जिसका एक उदाहरण ऊपर दिया गया है। उच्च विलंबता - निचला प्रदर्शन। 5ms पर, अनुरोधों की अधिकतम संख्या 200ms / s है, 20ms - 50 पर। इसके अलावा, यदि हमारे पास 1ms में 100 अनुरोध संसाधित हैं, और 100ms में 9 अनुरोध हैं, तो एक सेकंड में हमें 1ms और औसत के औसत के साथ केवल 109 IOPS मिलते हैं। (औसत) 10ms पर।

इसलिए निष्कर्ष समझना मुश्किल है: प्रदर्शन पर लोड का प्रकार न केवल "अनुक्रमिक" या "यादृच्छिक" है, बल्कि यह भी प्रभावित करता है कि डिस्क का उपयोग करने वाले एप्लिकेशन कैसे व्यवस्थित होते हैं।

उदाहरण: एक एप्लिकेशन (विशिष्ट डेस्कटॉप कार्य) लॉन्च करना लगभग 100% अनुक्रमिक है। हम आवेदन को पढ़ते हैं, आवश्यक पुस्तकालयों की सूची पढ़ते हैं, प्रत्येक पुस्तकालय को बारी-बारी से पढ़ते हैं ... यही कारण है कि डेस्कटॉप पर वे इतने भावुक रूप से एसएसडी से प्यार करते हैं - उनके पास पढ़ने के लिए एक सूक्ष्म देरी (माइक्रोसेकंड) है - बेशक, आपका पसंदीदा फोटोशॉप या ब्लेंडर एक सेकंड के दसवें हिस्से में शुरू होता है।

लेकिन, उदाहरण के लिए, लोड किए गए वेब सर्वर का काम लगभग समानांतर है - प्रत्येक बाद के क्लाइंट को पड़ोसी एक के स्वतंत्र रूप से परोसा जाता है, अर्थात। विलंबता केवल प्रत्येक ग्राहक के सेवा समय को प्रभावित करता है, लेकिन "ग्राहकों की अधिकतम संख्या" को नहीं। और, हम मानते हैं कि 1ms, 10ms - वैसे भी वेब सर्वर के लिए। (लेकिन यह "सभी समान" नहीं है कि 10ms के ऐसे कितने समानांतर अनुरोध भेजे जा सकते हैं)

थ्रेशिंग । मुझे लगता है कि डेस्कटॉप उपयोगकर्ता sysadmins की तुलना में इस घटना से अधिक परिचित हैं। हार्ड ड्राइव का एक भयानक गड्ढा, अकथनीय ब्रेक, "कुछ भी काम नहीं करता है और सब कुछ धीमा हो जाता है।"

जैसा कि हम डिस्क कतार (या भंडारण, मैं दोहराते हैं, लेख के संदर्भ में उनके बीच कोई अंतर नहीं है) को रोकना शुरू करते हैं, विलंबता तेजी से बढ़ने लगती है। डिस्क सीमा तक चलती है, लेकिन उनकी सेवा की गति से अधिक आवक कॉल हैं। विलंबता तेजी से बढ़ने लगती है, कुछ सेकंड की भयावह संख्या तक पहुंच जाती है (और इस तथ्य के बावजूद कि आवेदन, उदाहरण के लिए, काम को पूरा करने के लिए 100 ऑपरेशन करने की आवश्यकता है, जो 5 एमएस की विलंबता का मतलब था एक आधे-सेकंड की देरी ...)। इस स्थिति को थ्रशिंग कहा जाता है।

आप आश्चर्यचकित होंगे, लेकिन कोई भी ड्राइव या स्टोरेज सामान्य लोडिंग की तुलना में थ्रॉशिंग स्थिति में अधिक आईओपीएस दिखाने में सक्षम है। कारण सरल है: यदि सामान्य मोड में कतार सबसे अधिक बार खाली होती है ~~और कैशियर ग्राहकों की प्रतीक्षा में ऊब जाता है~~ , तो ट्रशिंग स्थिति में निरंतर सेवा होती है। (वैसे, यहां इस बात का स्पष्टीकरण है कि सुपरमार्केट क्यू की व्यवस्था करना क्यों पसंद करते हैं - इस मामले में, कैशियर की उत्पादकता अधिकतम है)। सच है, ग्राहकों को यह ज्यादा पसंद नहीं है। और अच्छे ~~सुपरमार्केट में वे~~ इस तरह के शासन से बचने की कोशिश करते हैं। यदि आप कतार की गहराई को जारी रखना चाहते हैं, तो कतार पूर्ण होने के कारण उत्पादकता गिरना शुरू हो जाएगी और कतार में खड़े होने का अनुरोध करेंगे (हां, और हाथ पर बॉलपॉइंट पेन के साथ सीरियल नंबर)।

और यहां हम डिस्क प्रदर्शन को मापने वाले लोगों की अगली बार (और खंडन करने के लिए बहुत मुश्किल) की प्रतीक्षा कर रहे हैं।

परीक्षण के दौरान विलंबता नियंत्रण

वे कहते हैं, "मेरी डिस्क 180 IOPS का उत्पादन करती है, इसलिए यदि आप 10 डिस्क लेते हैं, तो यह 1800 IOPS जितना होगा।" (यह वास्तव में क्या बुरा सुपरमार्केट लगता है, आवश्यक से कम कैशियर रोपण)। उसी समय, विलंबता पारलौकिक हो जाती है - और "कोई भी उस तरह नहीं रह सकता है।"

एक वास्तविक प्रदर्शन परीक्षण के लिए विलंबता नियंत्रण की आवश्यकता होती है, अर्थात ऐसे परीक्षण मापदंडों का चयन ताकि विलंबता सहमत सीमा से नीचे रहे।

और यहां हमें एक दूसरी समस्या का सामना करना पड़ रहा है: सीमा क्या है? सिद्धांत इस प्रश्न का उत्तर नहीं दे सकता है - यह संकेतक सेवा की गुणवत्ता का संकेतक है। दूसरे शब्दों में, हर कोई अपने लिए चुनता है।

व्यक्तिगत रूप से, मैं अपने लिए परीक्षण करता हूं ताकि विलंबता 10ms से अधिक न रहे। मैं इस सूचक को भंडारण प्रदर्शन की छत मानता हूं। (उसी समय, मेरे दिमाग में, मैं खुद के लिए सोचता हूं कि जिसके बाद लैग्स महसूस होने की सीमा 20ms है, लेकिन याद रखें, 900 से 1ms और 10 से 100ms से ऊपर के उदाहरण के बारे में, जिसके लिए avg 10ms बन गया? तो, इसके लिए मैं आरक्षित हूं?) अपने आप को (यादृच्छिक फटने के लिए 10ms)।

समानता

हम आश्रित और स्वतंत्र IOPS के मुद्दे पर पहले ही चर्चा कर चुके हैं। आश्रित इप्स के प्रदर्शन को विलंबता द्वारा नियंत्रित किया जाता है, और हम पहले ही इस मुद्दे पर चर्चा कर चुके हैं। लेकिन स्वतंत्र आईओपीएस में प्रदर्शन (यानी समानांतर भार के साथ), यह किस पर निर्भर करता है?

इसका उत्तर उस व्यक्ति की कल्पना से है जिसने डिस्क का आविष्कार किया है या भंडारण को डिज़ाइन किया है। हम SSD में प्रमुखों, स्पिंडल और समानांतर लेखन कतारों के बारे में बात कर सकते हैं, लेकिन यह सब अटकलें हैं। व्यावहारिक उपयोग के दृष्टिकोण से, हम एक प्रश्न में रुचि रखते हैं: HOW MUCH? हम समानांतर लोड धाराओं को कितना चला सकते हैं? (विलंबता के बारे में मत भूलना, क्योंकि अगर हम स्वर्ग में विलंबता भेजने की अनुमति देते हैं, तो समानांतर धागे की संख्या वहां जाएगी, हालांकि, उस गति से नहीं)। तो सवाल यह है कि हम किसी दिए गए दहलीज के नीचे कितने समानांतर धागे निष्पादित कर सकते हैं? टेस्ट को इस सवाल का जवाब देना चाहिए।

सैन और एनएएस

अलग-अलग, हमें उस स्थिति के बारे में बात करने की ज़रूरत है जब भंडारण टीसीपी का उपयोग कर नेटवर्क के माध्यम से होस्ट से जुड़ा हो। टीसीपी के बारे में आपको फिर से लिखना, लिखना, लिखना और लिखना होगा। यह कहने के लिए पर्याप्त है कि लिनक्स में नेटवर्क के लिए 12 विभिन्न भीड़ नियंत्रण एल्गोरिदम हैं जो विभिन्न स्थितियों के लिए डिज़ाइन किए गए हैं। और लगभग 20 कर्नेल पैरामीटर हैं, जिनमें से प्रत्येक आउटपुट तोते (क्षमा करें, परीक्षा परिणाम) को मौलिक रूप से प्रभावित कर सकता है।

प्रदर्शन मूल्यांकन के दृष्टिकोण से, हमें बस इस नियम को स्वीकार करना चाहिए: नेटवर्क संलग्न भंडारण के लिए, समानांतर में कई मेजबानों (सर्वर) से परीक्षण किया जाना चाहिए। एक सर्वर से टेस्ट स्टोरेज टेस्ट नहीं होगा, बल्कि नेटवर्क, स्टोरेज और सर्वर की सही सेटिंग्स का एक एकीकृत परीक्षण होगा।

बस संतृप्ति

अंतिम प्रश्न टायर को शेड करने का मुद्दा है। आप किस बारे में बात कर रहे हैं? यदि हमारे पास 400 एमबी / एस देने में सक्षम एसएसडी है, और हम इसे एसएटीए / 300 के माध्यम से जोड़ते हैं, तो यह स्पष्ट है कि हम सभी प्रदर्शन नहीं देखेंगे। इसके अलावा, विलंबता के दृष्टिकोण से, समस्या 300 एमबी / एस के करीब पहुंचने से पहले दिखाई देने लगेगी, क्योंकि प्रत्येक अनुरोध (और इसका जवाब) को एसएटीए केबल के टोंटी के माध्यम से खिसकने के लिए लाइन में इंतजार करना होगा।

लेकिन वहाँ स्थितियों और अधिक मजेदार हैं। उदाहरण के लिए, यदि आपके पास एसएएस / 300x4 (यानी प्रत्येक 4 एमबी 300 एमबी की 4 लाइनों) के माध्यम से ड्राइव का एक शेल्फ है। बहुत कुछ होने लगता है। और अगर एक शेल्फ में 24 डिस्क हैं? 24 * 100 = 2400 एमबी / एस, और हमारे पास केवल 1200 (300x4) है।

इसके अलावा, कुछ पर परीक्षण (सर्वर!) मदरबोर्ड ने दिखाया कि अंतर्निहित SATA नियंत्रक अक्सर PCIx4 के माध्यम से जुड़े होते हैं, जो सभी 6 SATA कनेक्टर के लिए अधिकतम संभव गति नहीं देता है।

मैं दोहराता हूं, बस संतृप्ति में मुख्य समस्या पट्टी की "छत के नीचे" नहीं खा रही है, लेकिन बस के भार के रूप में विलंबता बढ़ रही है।

स्टंट निर्माताओं

खैर, व्यावहारिक सलाह से पहले, मैं उन प्रसिद्ध ट्रिक्स के बारे में कहूंगा जो औद्योगिक भंडारण में पाए जा सकते हैं। सबसे पहले, यदि आप एक खाली डिस्क पढ़ते हैं, तो आप इसे "कहीं से भी बाहर" पढ़ेंगे। सिस्टम आपके द्वारा लिखी गई ड्राइव के क्षेत्रों से आपको शून्य खिलाने के लिए पर्याप्त स्मार्ट हैं।

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

तीसरा, कैश। यदि हम सबसे खराब स्थिति का परीक्षण कर रहे हैं, तो हमें यह जानना होगा कि जब कैश मदद नहीं करेगा तो सिस्टम कैसे व्यवहार करेगा। ऐसा करने के लिए, आपको ऐसे परीक्षण आकार लेने की आवश्यकता है ताकि हम "पिछले कैश" को पढ़ने / लिखने की गारंटी दें, अर्थात कैश से बाहर निकलें।

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

निर्णय - न्यूनतम x10 कैश (स्पष्ट रूप से, संख्या छत से ली गई है, मेरे पास सटीक गणना तंत्र नहीं है)।

ओएस स्थानीय कैश

बेशक, परीक्षण स्थानीय ओएस कैश की भागीदारी के बिना होना चाहिए, अर्थात, हमें एक ऐसे मोड में परीक्षण चलाने की आवश्यकता है जो कैशिंग का उपयोग नहीं करेगा। लिनक्स में, यह एक फ़ाइल (या डिस्क) खोलते समय एक O_DIRECT विकल्प है।

टेस्ट विवरण

कुल:
1) हम सबसे खराब स्थिति का परीक्षण कर रहे हैं - डिस्क आकार का 100%, जो भंडारण पर अनुमानित कैश आकार से कई गुना बड़ा है। डेस्कटॉप के लिए, यह केवल "संपूर्ण डिस्क" है, औद्योगिक भंडारण के लिए - 1TB या उससे अधिक का LUN या वर्चुअल मशीन डिस्क आकार। (हेहे, अगर आपको लगता है कि 64 जीबी रैम कैश बहुत है ...)।
2) हम 4kb साइज में टेस्ट ब्लॉक लेते हैं।
3) हम संचालन की समानता की गहराई का चयन करते हैं ताकि विलंबता उचित सीमा के भीतर बनी रहे।

आउटपुट पर, हम मापदंडों में रुचि रखते हैं: IOPS की संख्या, विलंबता, कतार की गहराई। यदि परीक्षण कई मेजबानों पर चलाया गया था, तो संकेतक संक्षेप में प्रस्तुत किए जाते हैं (आईओपीएस और कतार की गहराई), और विलंबता के लिए या तो सभी मेजबान के लिए संकेतक से औसत या अधिकतम लिया जाता है।

fio

यहां हम व्यावहारिक हिस्से की ओर बढ़ते हैं। एक उपयोगिता फियो है जो हमें उस परिणाम को प्राप्त करने की अनुमति देती है जिसकी हमें आवश्यकता है।

सामान्य फियो मोड में तथाकथित का उपयोग शामिल है नौकरी फ़ाइल, अर्थात् एक विन्यास जो बताता है कि परीक्षण कैसा दिखता है। नौकरी फ़ाइलों के उदाहरण नीचे दिए गए हैं, लेकिन अब हम चर्चा करते हैं कि फियो कैसे काम करता है।

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

और हमें "प्रचार" करने के लिए फियो को बताना होगा। (निर्माताओं की चाल के बारे में ऊपर देखें)। अगला, हम ब्लॉक आकार (4k) को ठीक करते हैं।

एक अन्य पैरामीटर डिस्क एक्सेस विधि है। सबसे तेज़ लाइबियो है, जिसका हम उपयोग करेंगे।

व्यावहारिक व्यंजनों

फियो स्थापित करें: apt-get install फियो (डेबियन / ubntu)। अगर कुछ भी, squeze अभी तक नहीं है।
उपयोगिता बहुत ही चालाकी से छिपी हुई है, इसलिए इसमें केवल "होम पेज" नहीं है, केवल एक गिट रिपॉजिटरी है। यहाँ एक दर्पण है: freecode.com/projects/fio

डिस्क का परीक्षण करते समय, आपको इसे रूट से चलाने की आवश्यकता होती है।

परीक्षण पढ़ना

लॉन्च: fio read.ini
कंटेंट read.ini

[Readtest]
blockize = 4k
फ़ाइल नाम = / देव / एसडीए
rw = randread
प्रत्यक्ष = १
शौकीन = ०
ioengine = लाइबियो
आयोडपथ = 32

कार्य इस तरह के आयोडेथ को चुनना है, ताकि एवीगेटेंसी 10ms से कम हो।

रिकॉर्डिंग परीक्षण

(ध्यान! गलत ड्राइव अक्षर - आप डेटा के बिना छोड़ दिया जाएगा)

[Writetest]
blockize = 4k
फ़ाइल नाम = / देव / sdz
rw = randwrite
प्रत्यक्ष = १
शौकीन = ०
ioengine = लाइबियो
आयोडपथ = 32

हाइब्रिड परीक्षण

सबसे स्वादिष्ट हिस्सा:
(ध्यान दें! गलती से ड्राइव अक्षर - आपको डेटा के बिना छोड़ दिया जाएगा)

[Readtest]
blockize = 4k
फ़ाइल नाम = / देव / sdz
rw = randread
प्रत्यक्ष = १
शौकीन = ०
ioengine = लाइबियो
आयोडपथ = 32
[Writetest]
blockize = 4k
फ़ाइल नाम = / देव / sdz
rw = randwrite
प्रत्यक्ष = १
शौकीन = ०
ioengine = लाइबियो
आयोडपथ = 32

आउटपुट विश्लेषण

परीक्षण के दौरान, हम कुछ इस तरह देखते हैं:

नौकरियां: 2 (f = 2): [rw] [2.8% किया गया] [13312K / 11001K / s] [3250/2686 iops] [eta 05m: 12s]

वर्ग कोष्ठक में IOPS की संख्या होती है। लेकिन यह आनन्दित होने के लिए बहुत जल्दी है - क्योंकि हम विलंबता में रुचि रखते हैं।

आउटपुट पर (Ctrl-C, या अंत में) हमें ऐसा कुछ मिलता है:

^ सी
fio: सिग्नल 2 पर समाप्त हो रहा है

पढ़ें: (समूहीकृत = 0, नौकरी = 1): गलत = 0: pid = 11048
  पढ़ें: io = 126480KB, bw = 14107KB / s, iops = 3526, runt = 1466msec
    slat (usec): मिनट = 3, अधिकतम = 432, avg = 6.19, stdev = 6.72
    clat (usec): न्यूनतम = 387, अधिकतम = 208677, avg = 9063.18, stdev = 22736.45
    bw (KB / s): न्यूनतम = 10416, अधिकतम = 18176, प्रति = 98.74%, औसत = 13928.29, stdev = 2414.65
  cpu: usr = 1.56%, sys = 3.17%, ctx = 15636, majf = 0, minf = 57
  IO की गहराई: 1 = 0.1%, 2 = 0.1%, 4 = 0.1%, 8 = 0.1%, 16 = 0.1%, 32 = 99.9%,> = 64 = 0.0%
     सबमिट करें: 0 = 0.0%, 4 = 100.0%, 8 = 0.0%, 16 = 0.0%, 32 = 0.0%, 64 = 0.0%,> = 64 = 0.0%
     पूरा: 0 = 0.0%, 4 = 100.0%, 8 = 0.0%, 16 = 0.0%, 32 = 0.1%, 64 = 0.0%,> = 64 = 0.0%
     जारी r / w: कुल = 31620/0, लघु = 0/0
     lat (usec): 500 = 0.07%, 750 = 0.99%, 1000 = 2.76%
     lat (msec): 2 = 16.55%, 4 = 35.21%, 10 = 35.47%, 20 = 3.68%, 50 = 0.76%
     lat (मिसेक): 100 = 0.08%, 250 = 4.43%
write: (groupid=0, jobs=1): err= 0: pid=11050
  write: io=95280KB, bw=10630KB/s, iops=2657, runt= 8963msec
    slat (usec): min=3, max=907, avg= 7.60, stdev=11.68
    clat (usec): min=589, max=162693, avg=12028.23, stdev=25166.31
    bw (KB/s) : min= 6666, max=14304, per=100.47%, avg=10679.50, stdev=2141.46
  cpu : usr=0.49%, sys=3.57%, ctx=12075, majf=0, minf=25
  IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=64=0.0%
     submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued r/w: total=0/23820, short=0/0
     lat (usec): 750=0.03%, 1000=0.37%
     lat (msec): 2=9.04%, 4=24.53%, 10=49.72%, 20=9.56%, 50=0.82%
     lat (msec): 100=0.07%, 250=5.87%

( ) :
read: iops=3526 clat=9063.18 (usec), 9.
write: iops=2657 clat=12028.23

slat clat. slat — (.. ), clat — complete latency, latency, . , , .

iodepth 16/16 :

read 6548 iops, 2432.79usec = 2.4ms
write 5301 iops, 3005.13usec = 3ms

, 64 (32+32) , , . 32 .

बेशक, हर कोई पहले से ही पीआई को उजागर कर रहा है ... तोते। मैं उन मूल्यों को देता हूं जो मैंने देखे थे:

RAMDISK (rbd) - ~ 200kIOPS / 0.1ms (iodepth = 2)
SSD (इंटेल 320 वीं श्रृंखला) - 40k IOPS पढ़ा (0.8ms); प्रति रिकॉर्ड लगभग 800 IOPS (एक लंबे परीक्षण के बाद)
एसएएस डिस्क (15k RPM) - 180 IOPS, 9ms
एसएटीए ड्राइव (7.2, डब्ल्यूडी आरई) - 100 आईओपीएस, 12ms
SATA WD Raptor - 140 IOPS, 12mc
SATA WD ग्रीन - 40 IOPS, और मैं iodepth = 1 के साथ भी विलंबता <20 प्राप्त करने में सक्षम नहीं था

चेतावनी: यदि आप इसे आभासी मशीनों पर चलाते हैं, तो
a) यदि आप IOPS के लिए शुल्क लेते हैं, तो यह बहुत ही ठोस धन होगा।
b) यदि होस्टर के पास खराब भंडारण है, जो केवल कई दस गीगाबाइट्स के कैश पर निर्भर करता है, तो एक बड़ी डिस्क (> 1 टीबी) के साथ परीक्षण करने से ... होस्टर और आपके होस्टिंग पड़ोसियों के लिए समस्याएं पैदा होंगी। कुछ मेजबान नाराज हो सकते हैं और आपसे पूछ सकते हैं।
ग) परीक्षण से पहले डिस्क को शून्य करने के लिए मत भूलना (यानी dd if = / dev / zero of = / dev / sdz bs = 2M oflag = direct)

डिस्क प्रदर्शन को ठीक से कैसे मापें

गीत