वा (शीर्ष कमांड से प्रतीक्षा कर रहा है I / O)

27

मेरे पास बहुत से आगंतुकों के साथ एक मंच है, कुछ दिनों में संख्या विस्टोर्स की वृद्धि के बिना लोड 40 तक पहुंच जाता है। जैसा कि आप नीचे दिए गए आउटपुट से देख सकते हैं, प्रतीक्षा समय अधिक है (57%)। मैं उसका कारण कैसे खोजूं?
सर्वर सॉफ्टवेयर Apache, MySQL और PHP है।

root@server:~# top
top - 13:22:08 up 283 days, 22:06,  1 user,  load average: 13.84, 24.75, 22.79
Tasks: 333 total,   1 running, 331 sleeping,   0 stopped,   1 zombie
Cpu(s): 20.6%us,  7.9%sy,  0.0%ni, 13.4%id, 57.1%wa,  0.1%hi,  0.9%si,  0.0%st
Mem:   4053180k total,  3868680k used,   184500k free,   136380k buffers
Swap:  9936160k total,    12144k used,  9924016k free,  2166552k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   90  3.1   4449:04 mysqld
17422 www-data  20   0  223m  20m  10m S    2  0.5   0:00.21 apache2
17555 www-data  20   0  222m  19m 9968 S    2  0.5   0:00.13 apache2
17264 www-data  20   0  225m  19m 8972 S    1  0.5   0:00.17 apache2
17251 www-data  20   0  220m  12m 4912 S    1  0.3   0:00.12 apache2

।

root@server:~# top
top - 13:39:59 up 283 days, 22:24,  1 user,  load average: 6.66, 10.39, 13.95
Tasks: 318 total,   1 running, 317 sleeping,   0 stopped,   0 zombie
Cpu(s): 13.6%us,  4.2%sy,  0.0%ni, 40.5%id, 40.6%wa,  0.2%hi,  0.8%si,  0.0%st
Mem:   4053180k total,  4010992k used,    42188k free,   119544k buffers
Swap:  9936160k total,    12160k used,  9924000k free,  2290716k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   44  3.1   4457:30 mysqld
19946 www-data  20   0  223m  21m  10m S    5  0.6   0:00.77 apache2
17316 www-data  20   0  226m  23m  11m S    1  0.6   0:01.76 apache2
17333 www-data  20   0  222m  21m  11m S    1  0.5   0:01.55 apache2
18212 www-data  20   0  225m  22m  11m S    1  0.6   0:01.58 apache2
19528 www-data  20   0  220m  13m 5480 S    1  0.3   0:00.63 apache2
19600 www-data  20   0  224m  20m  11m S    1  0.5   0:00.73 apache2
19942 www-data  20   0  225m  21m  10m S    1  0.5   0:00.82 apache2
20232 www-data  20   0  222m  16m 8760 S    1  0.4   0:00.65 apache2
20243 www-data  20   0  223m  21m  11m S    1  0.5   0:00.57 apache2
20299 www-data  20   0  225m  20m   9m S    1  0.5   0:00.67 apache2
20441 www-data  20   0  225m  21m  10m S    1  0.5   0:00.57 apache2
21201 www-data  20   0  220m  12m 5148 S    1  0.3   0:00.19 apache2
21362 www-data  20   0  220m  12m 5032 S    1  0.3   0:00.17 apache2
21364 www-data  20   0  220m  12m 4916 S    1  0.3   0:00.14 apache2
21366 www-data  20   0  220m  12m 5124 S    1  0.3   0:00.22 apache2
21373 www-data  20   0  222m  14m 7060 S    1  0.4   0:00.26 apache2

linux top

— usef_ksa
स्रोत

2

क्या यह एक भौतिक सर्वर (समर्पित), या VPS या साझा होस्टिंग सर्वर है? इससे बड़े पैमाने पर फर्क पड़ता है।

— टॉम ओ'कॉनर

1

यह समर्पित है। यह समस्या हल हो गई है। सर्वर में छवियों के लिए बहुत अधिक पढ़ने का अनुरोध था।

— usef_ksa

33

डिस्क गतिविधि को खोजने के लिए यहां कुछ उपकरण दिए गए हैं:

iotop
vmstat 1
iostat 1
lsof
strace -e trace=open <application>
strace -e trace=open -p <pid>

में ps auxfआप यह भी देखेंगे जो प्रक्रियाएं हैं uninterpretable डिस्क नींद में हैं ( D) वे आई / ओ के लिए इंतजार कर रहे हैं क्योंकि।

कुछ दिनों में संख्या अभिप्रेरकों की वृद्धि के बिना लोड 40 तक पहुंच जाता है।

आप एक बैकअप भी बनाना चाहते हैं, और देखें कि क्या हार्डड्राइव धीरे-धीरे विफल हो रहा है। एक हार्डड्राइव आम तौर पर कम होने से पहले धीमा होने लगता है। यह उच्च भार को भी समझा सकता है।

— vdboor
स्रोत

4

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

I / O एक डेटाबेस सर्वर पर प्रतीक्षा कर रहा है - विशेष रूप से लोड स्पाइक्स पर - यह एक सुराग है कि आपका DBMS डिस्क बाउंड हो सकता है (यानी आपको तेज़ डिस्क सबसिस्टम की आवश्यकता है) या इसमें ट्यूनिंग समस्या हो सकती है। आपको संभवतः अपने डेटाबेस सर्वर की रूपरेखा भी देखनी चाहिए - यानी यह पता लगाना चाहिए कि यह क्या कर रहा है और समय क्या ले रहा है।

डेटाबेस ट्यूनिंग मुद्दों के निदान के लिए कुछ स्टार्टर पॉइंट: -

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

ध्यान दें कि कुछ MySQL स्टोरेज इंजन लॉग का उपयोग नहीं करते हैं इसलिए यह आपके मामले में समस्या नहीं हो सकती है।

फुटनोट: कतार प्रणाली

क्यूटिंग सिस्टम (थ्रूपुट के लिए एक सांख्यिकीय मॉडल) हाइपरबोनिक रूप से धीमा हो जाता है क्योंकि सिस्टम संतृप्ति तक पहुंचता है। उच्च स्तरीय सन्निकटन के लिए, एक प्रणाली जो ५०% संतृप्त होती है, उसकी औसत कतार की लंबाई २ होती है। एक प्रणाली जो ९ ०% संतृप्त होती है, उसकी कतार की लंबाई १० होती है, एक प्रणाली जो ९९% संतृप्त होती है, की कतार की लंबाई १०० होती है।

इस प्रकार, एक प्रणाली जो संतृप्ति के करीब है, लोड में छोटे बदलावों से समय का इंतजार करने के लिए बड़े परिवर्तन हो सकते हैं, इस मामले में प्रकट समय के रूप में I / O पर प्रतीक्षा करने में समय लगता है। यदि आपकी डिस्क सबसिस्टम की I / O क्षमता लगभग संतृप्त है, तो लोड में छोटे परिवर्तन के परिणामस्वरूप प्रतिक्रिया समय में महत्वपूर्ण परिवर्तन हो सकते हैं।

— ConcernedOfTunbridgeWells
स्रोत

2

भागो iotop, या atop -dD, यह देखने के लिए कि क्या प्रक्रियाएं io कर रही हैं। straceअगर आपको नज़दीकी नज़र की ज़रूरत हो तो इस्तेमाल करें ।

— टोबू
स्रोत

1

दोनों स्क्रीन में निश्चित रूप से "mysqld" जिम्मेदार है।

आपको यह देखने की ज़रूरत है कि डेमन क्या कर रहा है ... कौन से प्रश्न चल रहे हैं।

— फ्लिप
स्रोत

1

कुछ दिनों में संख्या अभिप्रेरकों की वृद्धि के बिना लोड 40 तक पहुंच जाता है।

उपयोगकर्ता जो कर रहे हैं वह उस संख्या के रूप में महत्वपूर्ण हो सकता है जो वास्तव में वहां हैं। फ़ोरम की खोज जैसे कार्य केवल व्यक्तिगत थ्रेड्स या थ्रेड्स की सूची को लोड करने और देखने की तुलना में अधिक मांग होंगे।

भी: आप एक समर्पित सर्वर या एक VPS पर चल रहे हैं? यदि आपकी सेवा एक समर्पित सर्वर पर नहीं है, तो उसी होस्ट पर चलने वाले ऐप्स की क्रियाओं पर प्रभाव पड़ेगा, क्योंकि आपके VM द्वारा होस्ट किया गया शेयर I / O संसाधन के हिस्से के लिए प्रतिस्पर्धा करेगा।

जैसा कि अन्य लोगों ने बताया है, जैसे उपकरण iotopआपको यह देखने में मदद करेंगे कि कौन से कार्य I / O प्रतिक्रियाओं के इंतजार में बैठे हैं और वे उस समय किन फ़ाइलों तक पहुँच रहे हैं।

— डेविड स्पिलेट
स्रोत

2

यह समर्पित सर्वर है। मैं MySQL को अलग सर्वर पर चलाने का निर्णय लेता हूं। सर्वर लोड अब ठीक है, मैं भविष्य में समस्या का पता लगाने के लिए iotop जैसे उपकरणों का उपयोग करूंगा। आप सभी लोगों का बहुत बहुत धन्यवाद।

— usef_ksa

0

जैसा कि फ्लिप कहता है, ऐसा लगता है कि समस्या यह है कि माईस्कल क्या कर रहा है।

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

मैं केवल सीपीयू / डिस्क का उपयोग उस तरह से देखता हूं, जब सवाल चल रहा हो जो लाखों पंक्तियों को अपडेट करता हो।

उच्च भार औसत I / O का प्रत्यक्ष परिणाम है।

अपने mysql लॉगिंग को यह देखने के लिए क्रैंक करें कि क्या वहां कोई बुरा कोड है / बदलते इंडेक्स में मदद मिलेगी। अपनी तालिकाओं का विश्लेषण करने में मदद मिल सकती है (लेकिन शायद ज्यादा नहीं)।

सी।

— symcbean
स्रोत