सर्वर लोड बढ़ने का कारण कैसे पता करें


12

मुझे अपने सर्वर के साथ लोड की समस्या हो रही है और भले ही मैं कुछ हद तक अनुभवी लिनक्स व्यवस्थापक हूं, मैं अभी विचारों से बाहर हूं।

समस्या बिना किसी स्पष्ट कारण के सर्वर पर धीरे-धीरे लेकिन लगातार बढ़ते लोड की है।

सर्वर 6 जीबी रैम के साथ एएमडी एथलॉन (टीएम) 64 एक्स 2 डुअल कोर प्रोसेसर 6000+ है। यह लिनक्स gir 2.6.26-2-amd64 # 1 एसएमपी बुध अगस्त 19 22:33:18 UTC 2009 x86_64 GNU / लिनक्स के साथ डेबियन स्टेबल चल रहा है।

सर्वर मूल रूप से लाइटटैप, कई FastCGI PHP प्रक्रियाओं और एक MySQL डेटाबेस चलाता है। विशिष्ट वेबसर्वर कार्य।

सीपीयू को कभी भी पूरी तरह से उपयोग नहीं किया जाता है और मेमोरी मुख्य रूप से बफ़र्स और कैश के लिए उपयोग की जाती है जो ठीक है। मैंने विभिन्न सेवाओं को फिर से शुरू करने की कोशिश की, यह देखने के लिए कि उनमें से एक फिर से लोड को कम करेगा, लेकिन भाग्य के बिना।

यहाँ ग्राफिक्स लोड, CPU और IOStat दिखा रहे हैं:

तो, सवाल यह है: क्या धीरे-धीरे लेकिन कभी बढ़ते लोड का कारण बन सकता है? और मुझे कैसे पता चलेगा कि क्या जिम्मेदार है?

अद्यतन: मैं उल्लेख करना भूल गया, जब मैं सर्वर को रिबूट करता हूं, तो लोड लगभग 0.3 से 0.6 तक कम हो जाएगा और अगले हफ्तों में धीरे-धीरे फिर से ऊपर चढ़ना शुरू कर देगा।


1
आपके द्वारा पोस्ट की गई छवियां अब मौजूद नहीं हैं। यदि आपके पास अभी भी प्रतियां हैं, तो कृपया उन्हें फिर से अपलोड करने के लिए स्वतंत्र महसूस करें।
माइकल हैम्पटन

जवाबों:


6

प्रत्येक ज़ोंबी प्रक्रिया लोड में 1.0 जोड़ता है। आप लाश का एक संचय देख रहे होंगे।


हाँ। " प्रक्रियाओं की संख्या " ग्राफ की जाँच करें ।
टेडी

यदि यह सही था, तो टाइपिंग for N in {1..100} ; do sleep 60 & done ; exec sleep 500एक उच्च भार का कारण बनने के लिए पर्याप्त होना चाहिए। लेकिन यह नहीं है। वह कमांड 100 लाश का उत्पादन करता है, लेकिन मेरे कंप्यूटर पर लोड 1. से नीचे है
कास्परड

5

मुझे एक अलग सवाल के जवाब में एक उत्कृष्ट संकेत मिला ।

राज्य 'डी' में प्रक्रियाओं की तलाश में चार PHP प्रक्रियाएं दिखाई देती हैं जो लोड वक्र में "चरण" के अनुरूप काफी समय तक लटका हुआ प्रतीत होता है:

#> ps aux | awk '$8 ~ /D/  { print $0 }'
wiki      6651  0.0  0.0      0     0 ?        D    Oct04   0:41 [php-cgi]
bugs      6731  0.0  0.0      0     0 ?        D    Oct27   0:14 [php-cgi]
manpages  7536  0.0  0.0      0     0 ?        D    Oct30   0:21 [php5-cgi]
wiki     23847  0.0  0.0      0     0 ?        D    Oct06   1:32 [php-cgi]

तो ये समस्या लगती हैं। मुझे अब यह पता लगाने की आवश्यकता है कि उन प्रक्रियाओं को कैसे लटका दिया जाए और इसे कैसे ठीक किया जाए। सभी को धन्यवाद।


इस जवाब ने मेरी समस्या हल कर दी। भार 0.5 से बढ़कर 350 हो गया और ऊपर जाता रहा। यह हटाए गए दूरस्थ फ़ोल्डर को पढ़ने की कोशिश करने वाली ज़ोंबी प्रक्रियाओं के कारण था।
फिलिप डेल्टिल

2

मेरा अनुमान है कि सर्वर IO भूखा है, हो सकता है कि आपको रेखांकन में iotop आँकड़े जोड़ना चाहिए

मुझे आश्चर्य है कि यदि आपके पास प्रति एप्लिकेशन io गतिविधि हो सकती है जो सर्वर लोड के लिए एक कारक भी है

http://rt.wiki.kernel.org/index.php/I/Otop_utility

अन्य उपकरण dstat है


मैंने IOStat के लिए भी ग्राफिक्स जोड़े। डिस्क IO लोड के रूप में नहीं बढ़ता है। क्या आप जो लक्ष्य कर रहे थे?
एंड्रियास गोहर

ओह और dstat उपयोगी लगता है। मुझे इसके बारे में थोड़ा और पढ़ना है।
एंड्रियास गोहर

2

यदि यह I / O होता, तो वह cpu रेखांकन पर iowait (गुलाबी) देखता।


0

इस तरह की समस्याएं अक्सर हार्डडिस्क से आती हैं जो MySQL डेटाबेस और HTTP सर्वर द्वारा आवश्यक डेटा की सेवा करने के लिए पर्याप्त तेज़ नहीं है। आपको iostat कमांड को देखना चाहिए


IO मुझे सामान्य लगता है। और यह नहीं बताएगा कि लोड धीरे-धीरे क्यों बढ़ रहा है।
एंड्रियास गोहर

-1

सामान्य तौर पर, उच्च सर्वर लोड होना कोई बुरी बात नहीं है; इसका मतलब है कि आप बेकार नहीं बैठे हैं और आपसे कम कर रहे हैं अन्यथा नहीं कर सकते। आपकी कुल क्षमता का 80% -90% भार (कुछ "फट" कमरे के साथ) है जो आमतौर पर मांग की जाती है। मैं mpstat और vmstat के आउटपुट की जाँच करने की सलाह देता हूँ। विशेष रूप से, vmstat से पहले 2 नंबर आपको रन कतार में प्रक्रियाओं के संदर्भ में "बैक अप" के बारे में अधिक सार्थक जानकारी दे सकते हैं। Vmstat आउटपुट का अंतिम कॉलम ("वा") आपको बता सकता है कि क्या है, और कितने समय के लिए, आप I / O पूर्णता की प्रतीक्षा कर रहे हैं। रन कतार आकार और I / O प्रतीक्षा समय अक्सर सहसंबद्ध होते हैं। इसके अलावा sar (sysstat पैकेज से) की जाँच करें: जो आपको एक विस्तृत दृष्टिकोण देता है कि समय के साथ क्या हो रहा है; मीट्रिक जो इसे रिकॉर्ड करता है वह बहुत गहन है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.