🙍🏻 🙌🏻 🖥️ हम "क्लाउड" डिस्क के प्रदर्शन को मापते हैं

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

समस्या यह है कि एक आभासी मशीन के अंदर से एक हार्ड हार्ड डिस्क की "गति" को मापना आसान नहीं है, क्योंकि यह स्पष्ट नहीं है कि पहली जगह में क्या मापना है, क्या और क्यों। और वर्चुअल कॉन्फ़िगरेशन व्यवस्थापकों को यह समझाने के लिए आपको यह करने की आवश्यकता है कि समस्या एप्लिकेशन और MySQL सेटिंग्स में नहीं है। और यह आवश्यक था, जैसा कि वे कहते हैं, स्टोर में मैनुअल पढ़ने से पहले सिर्फ "अपने हाथ धोने" के लिए ।

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

सिद्धांत

नरक करने के लिए! बहुत सारे आयाम और अक्षर - क्रमिक पढ़ना / लिखना, यादृच्छिक पढ़ना / लिखना, ओवरराइट करना, कर्नेल फ़ाइल कैश का प्रभाव, क्वेरी कतार ऑप्टिमाइज़ेशन, विकल्प और फ़ाइल सिस्टम आर्किटेक्चर के लिए विकल्प ... हम इसे आसान करेंगे - MySQL सर्वर द्वारा बनाए गए वर्चुअल डिस्क के समान बहु-थ्रेड लोड लोड का अनुकरण करें। आइए देखें कि नेटवर्क पर डिस्क, या इसके पीछे क्या छिपा है, कैसे सांस लेता है।

और इसलिए उबाऊ नहीं है, gnu.org पर थोड़ा रोमांस जोड़ें :-)

MySQL एक डिस्क को कैसे लोड करता है

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

समय-समय पर, रैम से बफर पूल को डिस्क - रैंडम रिकॉर्डिंग में फ्लश किया जाएगा। हम वर्चुअल स्टोरेज में राइट कैश और "बैटरी" की अनुपस्थिति को तुरंत समाप्त कर देते हैं - यह होना चाहिए, अन्यथा ACID मोड में MySQL (innodb-flush-log-at-trx-प्रतिबद्ध = 1) केवल अफसोस से मर जाएगा।

यहां यह समझना महत्वपूर्ण है कि MySQL क्लाइंट अनुरोध समानांतर थ्रेड्स में निष्पादित किए जाते हैं - और डिस्क को क्रमशः लोड किया जाएगा, साथ में कई थ्रेड्स एक साथ।

एक लोड बनाएँ

आइए एक साधारण अमेज़ॅन ईबीएस ड्राइव से शुरू करें। हम वर्चुअल डिस्क को sysbench टूल के साथ लोड करेंगे (CentOS में यह पैकेज में उपलब्ध है, सोर्स से इकट्ठा करना आसान है):

yum install sysbench mkdir -p /mount/disk_ebs/mysql/test_folder cd /mount/disk_ebs/mysql/test_folder sysbench --test=fileio --file-total-size=16G prepare

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

अब हम ~ एन डीबीएमएस सर्वर क्लाइंट का अनुकरण करते हुए एन थ्रेड्स का एक लोड बनाते हैं, जो अनुरोधों को निष्पादित करते हैं (हां, मुझे पता है कि डीबीएमएस के अंदर कई सेवा प्रवाह हैं, लेकिन हमने इसे अभी तक जटिल नहीं किया है)। मान लीजिए, यह उम्मीद है कि 10 Apaches डेटाबेस के साथ मिलकर काम करेंगे:

 sysbench --num-threads=10 --test=fileio --file-test-mode=rndrw --max-time=180 --file-rw-ratio='2' --file-total-size=16G --max-requests=1000000 run

हम क्या माप रहे हैं?

अब मजा हिस्सा है। हमें इस बात में कोई दिलचस्पी नहीं है कि sysbench क्या परिणाम दिखाएगा - यह केवल हमारे लिए एक भार बनाता है। हम देखते हैं कि वर्चुअल डिस्क लोड के तहत कैसा महसूस करती है:

 iostat –xm 10 Device: rrqm/s wrqm/sr/sw/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util xvdm 0.00 0.00 120.50 0.00 2.05 0.00 34.79 10.50 87.47 8.30 100.00

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

एकल svctm अनुरोध के लिए औसत प्रसंस्करण समय 8.3 एमएस है। बहुत अधिक, लेकिन अमेज़ॅन ड्राइव के लिए सामान्य। कुछ भी आपराधिक नहीं है - साधारण भौतिकी।

एक अनुरोध "प्रतीक्षा" के प्रसंस्करण के लिए औसत प्रतीक्षा समय 87.47 एमएस है और "एवग्क्-एसज़" डिस्क चालक में अनुरोध कतार की औसत लंबाई 10.5 है। यह एक बहुत है, एक अनुरोध को संसाधित करने के लिए लगभग 100 एमएस प्रतीक्षा करें! जाहिर है, यह मूल्य कैसे प्राप्त किया जाता है - लगभग एक अनुरोध (svctm) के प्रसंस्करण समय से कतार (avgqu-sz) का आकार गुणा किया जाता है।

इसलिए, हम देखते हैं कि मनमाने ढंग से पढ़ने / लिखने के लिए केवल 10 प्रतिस्पर्धी अनुरोध (चाबियाँ --file-test-mode = rndrw और --file-rw-ratio = '2') वर्चुअल हार्ड डिस्क के साथ काम करने में मंदी की ओर ले जाते हैं।

हां, ताकि आपको लगभग 100 एमएस के लिए एक अनुरोध का इंतजार करना पड़े। और अगर कोई वेब पेज 200 डिस्क अनुरोध बनाता है, तो इसे बनाने में कितना समय लगेगा? 20 सेकंड

दिलचस्प बात यह है कि अमेज़ॅन डिस्क कितने थ्रेड के लिए कतार को जमा करना शुरू नहीं करता है और कम से कम 50 एमएस (बेहतर, आम तौर पर 20 एमएस से कम - विषयगत) की तुलना में तेजी से अनुरोधों की सेवा करता है? हम देखते हैं कि 5 धागे के साथ। बेशक, यह एक कमजोर संकेतक है, आप एक सॉफ्टवेयर छापे के बिना नहीं कर सकते ...

 Device: rrqm/s wrqm/sr/sw/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util xvdm 0.00 0.00 127.50 0.00 2.05 0.00 32.88 5.10 39.78 7.84 100.00

हम देखते हैं कि कतार का आकार 5.1 है और एक अनुरोध का निष्पादन समय 39.78 है।

अमेज़ॅन के "तेज़" वर्चुअल डिस्क का परीक्षण करना

अपेक्षाकृत हाल ही में, अमेज़ॅन ने IOPS (IOPS सिद्धांत - Google की गारंटी वाली संख्या के साथ "तेज़" डिस्क की घोषणा की, जैसा कि हमारे देश में व्यापक है, en.wikipedia.org/wiki/IOPS पर जाएं )। हम जानते हैं कि साधारण नश्वर SATA डिस्क 100 से अधिक IOPS (एक साथ पढ़ने और लिखने) के लिए नहीं है, और, दुर्भाग्य से, नश्वर 15k SAS डिस्क भी ~ 200 IOPS से अधिक नहीं है। यह भी ज्ञात है कि अन्य तकनीकों पर SSD और SAN सैकड़ों पर हावी हो सकते हैं, और हजारों IOPS से भी - यह स्पष्ट है कि वे बहुत अधिक महंगे हैं।

तो, आइए देखते हैं कि एक साथ कितने अमेज़ॅन के "फास्ट" वर्चुअल डिस्क एक कतार में ब्लंट और एकत्रित अनुरोधों को शुरू करते हैं। बकरी के बाएं पैर को तोड़ो!

1000 IOPS के साथ EBS डिस्क

एक धागा:

 Device: rrqm/s wrqm/sr/sw/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util xvdk 0.00 0.00 1084.50 0.00 27.33 0.00 51.61 3.72 3.43 0.91 99.20

वर्चुअल डिस्क द्वारा अनुरोध के लघु प्रसंस्करण समय पर ध्यान दें - 0.91 एमएस। जाहिरा तौर पर सरणी SSD ;-) पर है। कतार का आकार ~ 4 है, और एक अनुरोध के लिए औसत समय 3.43 एमएस है।

20 धागे:

 Device: rrqm/s wrqm/sr/sw/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util xvdk 0.00 0.00 1059.50 0.00 26.37 0.00 50.98 55.39 51.97 0.94 100.00

हम देखते हैं कि 20 थ्रेड्स के साथ अनुरोध 55 अनुरोधों की कतार के कारण ~ 50 एमएस इंतजार करना होगा।

2000 IOPS के साथ EBS डिस्क

20 धागे:

 Device: rrqm/s wrqm/sr/sw/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util xvdl 0.00 0.00 1542.50 0.00 36.29 0.00 48.18 33.20 21.29 0.65 100.00

50 धागे:

 Device: rrqm/s wrqm/sr/sw/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util xvdl 0.00 0.00 1498.50 0.00 36.63 0.00 50.06 86.17 57.05 0.67 100.00

माप के परिणाम

हम देखते हैं कि 2000 IOPS के साथ एक EBS डिस्क 50 धाराओं पर लगभग 50 धाराओं पर एक समान विलंबता (~ 50ms) दिखाता है, 20 धाराओं पर 1000 IOPS और 6-7 धाराओं पर एक नियमित EBS डिस्क (जाहिरा तौर पर नियमित EBS OOPS डिस्क 200 के भीतर है) -300)।

और क्या हो रहा है

आभासी हार्ड ड्राइव अक्सर आश्चर्यचकित करते हैं। कभी-कभी वे बस कॉन्फ़िगर नहीं होते हैं, क्योंकि आदमी को पढ़ने का समय नहीं मिला ...

हाल ही में मैं एक ऐसे ही मामले में आया था, जब एक खाली MySQL सर्वर पर एक बहु-थ्रेडेड टेस्ट लोड बनाते हुए, रात में 0.5 से 1 एमएस और रात में ~ 10 से 100 एमएस से svctm (svctm) "बड़ी-महंगी-फास्ट-नेटवर्क" वर्चुअल डिस्क से कूद गया मैं पूर्णिमा पर कोशिश करना चाहता था, इंतजार नहीं किया)। MySQL बेशक - धीमा हो गया। कारण नेटवर्क स्टोरेज और एक-दूसरे प्रोजेक्ट्स से अनजान होने के कारण समानांतर में था, न कि MySQL सेटिंग्स, जिसे उन्होंने दोषी बनाने की कोशिश की;;

सारांश

उपलब्ध उपकरणों का उपयोग करते हुए, हमने जल्दी से प्रतिस्पर्धी बहु-थ्रेडेड लोड सीमा निर्धारित की, जिस पर वर्चुअल डिस्क एक कतार जमा करना शुरू कर देता है और 50 मिसे या उससे अधिक के लिए विशिष्ट MySQL प्रश्नों की सेवा करता है। अब हम अनुमान लगा सकते हैं कि विलंबता सुनिश्चित करने के लिए छापे में कितने डिस्क इकट्ठा करने हैं, उदाहरण के लिए, किसी दिए गए ग्राहकों की संख्या के लिए 10-20 एमएस में। यह स्पष्ट है कि ये अनुमानित डेटा हैं, लेकिन वे निश्चित रूप से आगे बढ़ने में मदद करेंगे, खासकर यदि आप एक वास्तविक हार्ड ड्राइव / छापे के प्रदर्शन को मापते हैं और इन तुलनात्मक डेटा और शैंपेन की एक बोतल के साथ क्लाउड होस्टिंग में आते हैं;;

अंत में, मैं सभी को पिछली छुट्टी की बधाई देता हूं, मैं आपको तेजी से आभासी डिस्क, विश्वसनीय सर्वर और सटीक माप की कामना करता हूं! हमें Bitrix24 पर जाएँ । सौभाग्य है

हम "क्लाउड" डिस्क के प्रदर्शन को मापते हैं - हम MySQL को बचाते हैं