आदि के लिए उपयुक्त भंडारण गति? आइए फियो से पूछें

फियो और आदि के बारे में एक छोटी कहानी

क्लस्टर प्रदर्शन इत्यादि यह काफी हद तक इसके भंडारण के प्रदर्शन पर निर्भर करता है। आदि कुछ मेट्रिक्स निर्यात करता है प्रोमिथेउसवांछित भंडारण प्रदर्शन जानकारी प्रदान करने के लिए। उदाहरण के लिए, wal_fsync_duration_thirds मीट्रिक। आदि के लिए दस्तावेज़ कहता है: भंडारण को पर्याप्त तेज़ मानने के लिए, इस मीट्रिक का 99वाँ प्रतिशत 10ms से कम होना चाहिए। यदि आप लिनक्स मशीनों पर एक आदि क्लस्टर चलाने की योजना बना रहे हैं और यह मूल्यांकन करना चाहते हैं कि क्या आपका स्टोरेज पर्याप्त तेज़ है (उदाहरण के लिए एसएसडी), तो आप इसका उपयोग कर सकते हैं FiO I/O संचालन के परीक्षण के लिए एक लोकप्रिय उपकरण है। निम्नलिखित कमांड चलाएँ, जहाँ टेस्ट-डेटा स्टोरेज माउंट पॉइंट के अंतर्गत निर्देशिका है:

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

आपको बस परिणामों को देखना होगा और जांचना होगा कि अवधि का 99वां प्रतिशत है fdatasync 10 एमएस से कम. यदि हां, तो आपके पास यथोचित तेज़ भंडारण है। यहां परिणामों का एक उदाहरण दिया गया है:

  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

नोट्स

• हमने अपने विशेष परिदृश्य के लिए --size और --bs विकल्पों को अनुकूलित किया है। फ़ियो से उपयोगी परिणाम प्राप्त करने के लिए, अपने स्वयं के मान प्रदान करें। उन्हें कहाँ से प्राप्त करें? पढ़ना हमने fio को कॉन्फ़िगर करना कैसे सीखा.
• परीक्षण के दौरान, सारा I/O लोड fio से आता है। वास्तविक जीवन के परिदृश्य में, wal_fsync_duration_thirds से संबंधित अनुरोधों के अलावा स्टोरेज में अन्य लेखन अनुरोध आने की संभावना होगी। अतिरिक्त भार से wal_fsync_duration_thirds का मान बढ़ जाएगा। इसलिए यदि 99वाँ प्रतिशतक 10 एमएस के करीब है, तो आपका भंडारण गति से बाहर चल रहा है।
• संस्करण लें FiO 3.5 से कम नहीं (पिछले वाले fdatasync अवधि प्रतिशत नहीं दिखाते हैं)।
• ऊपर फियो से प्राप्त परिणामों का एक अंश मात्र है।

फियो और आदि के बारे में लंबी कहानी

आदि में वाल क्या है?

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

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

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

दुर्भाग्य से, लगातार भंडारण पर लिखना तुरंत नहीं होता है। यदि fdatasync कॉल धीमी है, तो आदि सिस्टम का प्रदर्शन प्रभावित होगा। आदि के लिए दस्तावेज़ कहता हैयदि 99वें प्रतिशतक में, fdatasync कॉल को WAL फ़ाइल में लिखने में 10ms से कम समय लगता है, तो स्टोरेज को काफी तेज़ माना जाता है। भंडारण के लिए अन्य उपयोगी मीट्रिक हैं, लेकिन इस पोस्ट में हम केवल इस मीट्रिक के बारे में बात कर रहे हैं।

फियो के साथ भंडारण का अनुमान लगाना

यदि आपको यह मूल्यांकन करने की आवश्यकता है कि आपका भंडारण आदि के लिए उपयुक्त है या नहीं, तो एक बहुत लोकप्रिय I/O लोड परीक्षण उपकरण, fio का उपयोग करें। यह याद रखना चाहिए कि डिस्क संचालन बहुत भिन्न हो सकते हैं: सिंक्रोनस और एसिंक्रोनस, सिस्टम कॉल के कई वर्ग आदि। परिणामस्वरूप, फियो का उपयोग करना काफी कठिन है। इसके कई पैरामीटर हैं, और उनके मूल्यों के विभिन्न संयोजन बहुत अलग I/O कार्यभार उत्पन्न करते हैं। आदि के लिए पर्याप्त आंकड़े प्राप्त करने के लिए, आपको यह सुनिश्चित करना चाहिए कि वाल फ़ाइलें लिखते समय फियो से परीक्षण लेखन लोड आदि से वास्तविक लोड के जितना संभव हो उतना करीब हो।

इसलिए, फियो को, कम से कम, फ़ाइल में अनुक्रमिक लेखन की एक श्रृंखला का लोड बनाना चाहिए, प्रत्येक लेखन में एक सिस्टम कॉल शामिल होगा लिखनाइसके बाद fdatasync सिस्टम कॉल आती है। फ़ियो को अनुक्रमिक लिखने के लिए --rw=write विकल्प की आवश्यकता होती है। फियो के लिए लेखन प्रणाली का उपयोग करने के बजाय लिखते समय कॉल करें लिखना, आपको --ioengine=sync पैरामीटर निर्दिष्ट करना चाहिए। अंत में, प्रत्येक लेखन के बाद fdatasync को कॉल करने के लिए, आपको --fdatasync=1 पैरामीटर जोड़ना होगा। इस उदाहरण में अन्य दो विकल्प (--आकार और -बीएस) स्क्रिप्ट-विशिष्ट हैं। अगले भाग में, हम आपको दिखाएंगे कि उन्हें कैसे सेट अप करें।

फ़ियो क्यों और हमने इसे सेट करना कैसे सीखा

इस पोस्ट में, हम एक वास्तविक मामले का वर्णन करते हैं। हमारे पास एक क्लस्टर है Kubernetes v1.13 जिसकी हमने प्रोमेथियस के साथ निगरानी की। इत्यादि v3.2.24 को SSD पर होस्ट किया गया था। Etcd मेट्रिक्स ने fdatasync विलंबता को बहुत अधिक दिखाया, तब भी जब क्लस्टर कुछ नहीं कर रहा था। मेट्रिक्स अजीब थे और हम वास्तव में नहीं जानते थे कि उनका क्या मतलब है। क्लस्टर में वर्चुअल मशीनें शामिल थीं, यह समझना आवश्यक था कि समस्या क्या थी: भौतिक एसएसडी में या वर्चुअलाइजेशन परत में। इसके अलावा, हम अक्सर हार्डवेयर और सॉफ्टवेयर कॉन्फ़िगरेशन में बदलाव करते थे, और हमें उनके परिणामों का मूल्यांकन करने के लिए एक तरीके की आवश्यकता होती थी। हम हर कॉन्फ़िगरेशन में आदि चला सकते हैं और प्रोमेथियस मेट्रिक्स को देख सकते हैं, लेकिन यह बहुत परेशानी भरा है। हम किसी विशिष्ट कॉन्फ़िगरेशन का मूल्यांकन करने के लिए एक काफी सरल तरीका ढूंढ रहे थे। हम यह जांचना चाहते थे कि क्या हम आदि से प्रोमेथियस मेट्रिक्स को सही ढंग से समझते हैं।

लेकिन इसके लिए दो समस्याओं का समाधान करना होगा. सबसे पहले, वाल को लिखते समय आदि जो I/O लोड बनता है वह कैसा दिखता है? कौन से सिस्टम कॉल का उपयोग किया जाता है? रिकॉर्ड का आकार क्या है? दूसरा, यदि हम इन प्रश्नों का उत्तर देते हैं, तो हम फियो के साथ समान कार्यभार को कैसे पुन: उत्पन्न करते हैं? यह मत भूलिए कि फियो कई विकल्पों वाला एक बहुत ही लचीला उपकरण है। हमने दोनों समस्याओं को एक ही दृष्टिकोण से हल किया - आदेशों का उपयोग करके एलसोफे и स्ट्रेस. lsof प्रक्रिया द्वारा उपयोग किए गए सभी फ़ाइल डिस्क्रिप्टर और उनकी संबंधित फ़ाइलों को सूचीबद्ध करता है। और स्ट्रेस के साथ, आप पहले से चल रही प्रक्रिया की जांच कर सकते हैं, या एक प्रक्रिया शुरू कर सकते हैं और उसकी जांच कर सकते हैं। स्ट्रेस जांच की जा रही प्रक्रिया (और इसकी चाइल्ड प्रक्रियाओं) से सभी सिस्टम कॉल को प्रिंट करता है। उत्तरार्द्ध बहुत महत्वपूर्ण है, क्योंकि इत्यादि एक समान दृष्टिकोण अपना रहा है।

जब क्लस्टर पर कोई लोड नहीं था तो हमने कुबेरनेट्स के लिए आदि सर्वर का पता लगाने के लिए पहली बार स्ट्रेस का उपयोग किया था। हमने देखा कि लगभग सभी वाल रिकॉर्ड एक ही आकार के थे: 2200-2400 बाइट्स। इसलिए, पोस्ट की शुरुआत में कमांड में, हमने पैरामीटर -bs=2300 निर्दिष्ट किया (bs का मतलब प्रत्येक fio प्रविष्टि के लिए बाइट्स में आकार है)। ध्यान दें कि आदि प्रविष्टि का आकार आदि संस्करण, वितरण, पैरामीटर मान आदि पर निर्भर करता है, और fdatasync अवधि को प्रभावित करता है। यदि आपके पास भी ऐसा ही परिदृश्य है, तो सटीक संख्याओं का पता लगाने के लिए स्ट्रेस के साथ अपनी आदि प्रक्रियाओं की जांच करें।

फिर, आदि फ़ाइल सिस्टम क्या कर रहा है इसका एक अच्छा विचार प्राप्त करने के लिए, हमने इसे स्ट्रेस और -ffttT विकल्पों के साथ शुरू किया। इसलिए हमने चाइल्ड प्रक्रियाओं की जांच करने और उनमें से प्रत्येक के आउटपुट को एक अलग फ़ाइल में रिकॉर्ड करने का प्रयास किया, और प्रत्येक सिस्टम कॉल की शुरुआत और अवधि के बारे में विस्तृत रिपोर्ट भी प्राप्त की। हमने स्ट्रेस आउटपुट के अपने विश्लेषण की पुष्टि करने और यह देखने के लिए lsof का उपयोग किया कि किस फ़ाइल डिस्क्रिप्टर का उपयोग किस उद्देश्य के लिए किया जा रहा था। तो स्ट्रेस की मदद से ऊपर दिखाए गए परिणाम प्राप्त किए गए। सिंक्रोनाइज़ेशन समय के आँकड़ों ने पुष्टि की है कि आदि से wal_fsync_duration_thirds, WAL फ़ाइल डिस्क्रिप्टर के साथ fdatasync कॉल के अनुरूप है।

हमने फियो के लिए दस्तावेज़ों का अध्ययन किया और अपनी स्क्रिप्ट के लिए विकल्प चुने ताकि फियो आदि के समान लोड उत्पन्न कर सके। हमने आदि के समान स्ट्रेस से फियो चलाकर सिस्टम कॉल और उनकी अवधि की भी जाँच की।

हमने फियो से संपूर्ण I/O लोड को दर्शाने के लिए --size पैरामीटर का मान सावधानीपूर्वक चुना है। हमारे मामले में, यह स्टोरेज में लिखे गए बाइट्स की कुल संख्या है। यह लिखने (और fdatasync) सिस्टम कॉल की संख्या के सीधे आनुपातिक साबित हुआ। बीएस के एक निश्चित मान के लिए, एफडेटासिंक कॉल की संख्या = आकार/बीएस। चूँकि हम प्रतिशतक में रुचि रखते थे, इसलिए हमारे पास सुनिश्चित करने के लिए पर्याप्त नमूने होने चाहिए थे, और हमने गणना की कि 10^4 हमारे लिए पर्याप्त होगा (यह 22 मेबीबाइट है)। यदि --आकार छोटा है, तो आउटलेर्स हो सकते हैं (उदाहरण के लिए, कई fdatasync कॉल सामान्य से अधिक समय लेती हैं और 99वें प्रतिशतक को प्रभावित करती हैं)।

इसे स्वयं आज़माएं

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

स्रोत: www.habr.com