उच्च IO प्रतीक्षा - मूल कारण कैसे निर्धारित करें?

Question

मेरे पास दो समर्पित सर्वरों पर MySQL का उदाहरण है। उत्पादन के लिए एक, परीक्षण मंच के लिए अन्य।

2 सर्वर बहुत समान हैं, केवल अंतर RAID नियंत्रक और वर्चुअल वॉल्यूम (HD समान हैं) है। उत्पादन पर, एक समर्पित HW RAID नियंत्रक और एक RAID 10 मात्रा है। दूसरे पर, RAID नियंत्रक सॉफ़्टवेयर (Lenovo ThinkServer RAID 110i) लगता है और वॉल्यूम RAID 5 है।

हमने देखा कि MySQL के दौरान, हमारे पास उच्च आयोवाइट है:

while true; do date; ps auxf | awk '{if($8=="D") print $0;}'; sleep 1; done
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:37 CEST 2015
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:38 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:39 CEST 2015
Thu Jun 18 13:49:40 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root      1478  0.0  0.0      0     0 ?        D    Jun04   0:03  \_ [jbd2/dm-7-8]
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]

डीएम-10-8 और डीएम-14-8 डेटाबेस विभाजन से संबंधित हैं।

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  3 240904 809656 572624 7114416    0    0    59  1681 2002 5141  3  1 67 30  0
 0  4 240880 809656 572632 7114604    0    0   139  2069 2090 4985  3  1 67 29  0
 1  2 240880 809284 572636 7114676    0    0    27  2159 2253 4247  2  1 72 25  0
 5  2 240880 809408 572656 7114820    0    0    27  2404 2254 5350  3  1 69 27  0

मुझे छापे नियंत्रक पर संदेह है, मैं कैसे सुनिश्चित कर सकता हूं?

Comments

शायद विषय से बाहर: लेकिन एक डेटाबेस पर RAID5 क्यों? लेखन अंतराल के कारण बुरा विचार। BBU के साथ HW कुछ हद तक इसे कम करता है, लेकिन RAID 5 मूल रूप से पढ़ने के लिए अच्छा है, छोटे लेनदेन लिखने के लिए नहीं।

— हेन्नेस

क्योंकि मेरे पास कोई विकल्प नहीं था ... RAID 10 इस RAID नियंत्रक (आरएचईएल के मेरे संस्करण के साथ) पर समर्थित नहीं था ...

— बॉब सॉवेज

@BusSauvage किसी भी प्रगति?

— ह्यूजेंस

बस स्पष्ट होने के लिए: क्या io- प्रतीक्षा में बड़े पैमाने पर भंडारण द्वारा प्रदान नहीं किए गए फ़ाइल विवरणों पर प्रतीक्षा भी शामिल है? सॉकेट की तरह ...

— मास्सिमो

Answer 1

मेरे उत्तर में 2 भाग थे: ब्लॉक डिवाइस ड्राइवर की जांच; और अनुकूलन आपके उपयोग के मामले को देखने के लायक है। लेकिन मैंने पिछले भाग को हटा दिया क्योंकि यह बताया गया था कि इससे डेटा हानि हो सकती है। टिप्पणी देखो।

हार्डवेयर की जांच

मैं समझ गया कि एक ही आवेदन के लिए लेकिन हार्डवेयर के 2 अलग-अलग सेटों पर प्रदर्शन बहुत अलग है और आप यह समझना चाहेंगे कि क्यों। इसलिए मैं "क्यों" के लिए एक उत्तर खोजने में आपकी सहायता करने के लिए पहले एक साधन प्रस्तावित करता हूं।

प्रदर्शन के लिए, मैं अक्सर अपने ब्लॉग पर ब्रेंडन ग्रेग द्वारा प्रदान किए गए लिनक्स प्रदर्शन मानचित्र को संदर्भित करता हूं । एक व्यक्ति यह देख सकता है कि निम्न स्तर (हार्डवेयर के सबसे करीब) के लिए एक उपकरण blktraceसही होगा।

वास्तव में इस उपकरण को जानने के बाद, मैंने आसपास खोज की और मार्क ब्रूकर द्वारा ब्लक्ट्रेस के बारे में यह दिलचस्प लेख पाया । मूल रूप से यह निम्नलिखित सुझाव देता है: I / O ट्रेस का उपयोग करके प्रदर्शन करना blktrace; इस ट्रेस से जानकारी निकालने के लिए btt टूल का उपयोग करना । यह कुछ इस तरह होगा (30 s ट्रेस के लिए):

# blktrace -w 30 -d /dev/dm-10-8 -o dm-10-8
# blkparse -d blkmerged.out dm-10-8*
# btt -i blkmerged.out | less

आउटपुट काफी लंबा हो सकता है, लेकिन D2C प्रविष्टियों के लिए देखें। यह आपको उस समय का अंदाजा लगाएगा, जब डिवाइस ड्राइवर को एक I / O डिलीवर होने में लगने वाला समय इस ड्राइवर द्वारा पूरा किया जाएगा।

उदाहरण आउटपुट ( dnf upgradeमेरे व्यस्त लैपटॉप पर वर्चुअलबॉक्स वीएम पर चल रहा है):

            ALL           MIN           AVG           MAX           N
--------------- ------------- ------------- ------------- -----------

...
D2C               0.000046515   0.045781696   3.940577359       11713
...

यह सबसे खराब स्थिति के लिए 3,94 सेकेंड तक I / O के साथ 45 एमएस प्रति निराशाजनक औसत दिखाता है !!

इस जांच को करने के लिए ब्लॉट्रेस का उपयोग करने के अधिक तरीकों के लिए, बहुत ही शिक्षाप्रद मार्क ब्रूकर के लेख को पढ़ें।

Comments

पेरकोना ब्लॉग पोस्ट ने उत्तर में बताया कि निर्दोष प्रदर्शन को बेहतर बनाने के लिए इसे अपडेट किया गया है: अपडेट: ऐसा न करें, यह भ्रष्ट डेटा साबित हो गया है!

— vkats

@vkats बहुत बहुत धन्यवाद। मैंने सुझाव और लेख को हटाने के उत्तर को अपडेट कर दिया है।

— ह्यूजेंस

Answer 2

jbd2 प्रक्रिया ext4 जर्नलिंग के लिए है। यह तर्कसंगत है कि mysql के दौरान फाइल सिस्टम को जर्नल में लिखने की आवश्यकता है, यह किसी भी चिंता का कारण नहीं होना चाहिए। Jbd के कारण लोड की मात्रा dm-10-8 और dm-14-8 विभाजन के लिए आपके माउंट मापदंडों से प्रभावित होती है। संभवतः डेटाबेस विभाजन पर बहुत रूढ़िवादी पत्रिकाओं का प्रकाशन करना वांछनीय है ताकि यह सुनिश्चित हो सके कि आपके डेटाबेस में कुछ घटित न हो और आपका सर्वर गलती से रिबूट न ​​हो जाए। आप तुलना के लिए परीक्षण वातावरण में एक और जर्नलिंग माउंट विकल्प चुन सकते हैं।

Comments

मेरे jbd2 / dm-2-8 को iotop पर हर समय 8.5% लगता है, लेकिन .. मुझे नहीं लगता कि कोई समस्या नहीं है क्योंकि कोई डिस्क पढ़ा नहीं है, और 1 डिस्क के बाद कुल डिस्क लिखना 35mb है। btw, पर / देव वहाँ सबसे dm-2 पर है (कि -8 मुझे पता नहीं है कि यह कहाँ से है ..)

— कुंभ राशि शक्ति