सर्वोत्तम अभ्यास: लिनक्स के 'टॉप' कमांड का उपयोग करके समस्या का निवारण

अब हम अपनी निगरानी सेवा की एक नई सुविधा पर काम कर रहे हैं ताकि न केवल सर्वर के बाहरी मापदंडों, बल्कि आंतरिक लोगों, जैसे सिस्टम लोड, हार्ड ड्राइव की स्थिति, रैम और अन्य की निगरानी कर सकें। विकास प्रक्रिया के दौरान, हम एक उपयोगी लेख के बारे में आए जो सिस्टम के मापदंडों के बारे में बात करता है जो शीर्ष सिस्टम कमांड का उपयोग करके प्राप्त किया जा सकता है, हम इस लेख का अनुवाद आपके ध्यान में प्रस्तुत करते हैं।



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

"शीर्ष" कमांड का आउटपुट

यदि आप लिनक्स सिस्टम कमांड लाइन में कमांड टॉप टाइप करते हैं, तो आपको निम्नलिखित हेडिंग के साथ एक प्लेट मिलेगी:







आइए प्रत्येक पंक्ति के अर्थ को देखें।



top – 17:15:19 up 32 days, 18:24, 6 users





कमांड और वर्तमान सिस्टम का समय यहां दिखाया गया है; "अपटाइम", हमारे मामले में, यह 32 दिन, 18 घंटे और 24 मिनट है; अंत में, सिस्टम में पंजीकृत उपयोगकर्ताओं की संख्या इंगित की गई है; इस उदाहरण में, 6 उपयोगकर्ता सिस्टम में पंजीकृत हैं। वे एसएसएच के माध्यम से जुड़े हो सकते हैं, स्थानीय रूप से निष्क्रिय हो सकते हैं, आदि।



load average: 0,00, 0,01, 0,05





यह हिस्सा औसत भार दिखाता है; यह भ्रामक हो सकता है, विशेष रूप से वर्चुअल मशीन पर / क्लाउड में।

पहला अंक "अंतिम मिनट", या "वर्तमान" औसत लोड का औसत लोड दर्शाता है; दूसरा अंक "5 मिनट में औसत लोड", अंतिम अंक "15 मिनट में औसत लोड" दिखाता है।

औसत लोड प्रोसेसर पर किसी भी कार्रवाई करने के लिए लाइन में प्रतीक्षा की जाने वाली प्रक्रियाओं की औसत संख्या का एक उपाय है। जैसा कि सुपरमार्केट में, आपको लाइन में खड़ा होना होगा, कैशियर की प्रतीक्षा में आपको उसका सारा ध्यान देना होगा। औसत लोड बढ़ रहा है इसका कारण यह है कि इस रेखा के नीचे के आंकड़े और काउंटर बाकी हैं, इसलिए, यदि आप औसत लोड मानों पर सख्ती से ध्यान केंद्रित करते हैं, तो आप पूरी तस्वीर को पूरी तरह से नहीं देख सकते हैं।

यहाँ एक उदाहरण distcc नोड से लिया गया है:

यह सर्वर स्क्रिप्ट्स और क्लाउड कमांड लाइन टूल्स की मेजबानी के लिए एक मध्यवर्ती प्रसंस्करण वातावरण होने के अलावा, हमारे नेटवर्क पर स्थित विभिन्न मशीनों को वितरित सी कंपाइलर सेवा भी प्रदान करता है, क्योंकि इसमें 8 प्रोसेसर, 32 जीबी रैम और एक टन छद्म डिस्क स्थान है। सामान्य भार के तहत, इसका औसत मूल्य अपेक्षाकृत कम रहता है; जावा स्क्रिप्ट निष्पादित करते समय, लोड दो या अधिक बार बढ़ सकता है। हालाँकि, जब कंपाइलर सेवा पूर्ण लोड पर चल रही होती है (प्रोसेसर लोड 95% या अधिक होने पर 10 चलने वाली प्रक्रियाएं), तो औसत भार 0.75 होता है ... यह कैसे होता है? आइए इसे जानने की कोशिश करें

कार्य स्ट्रिंग

Tasks: 119 total, 1 running, 118 sleeping, 0 stopped, 0 zombie





कार्य: जब आप टाइप करते हैं तो प्रक्रियाओं की संख्या को दर्शाता है, उदाहरण के लिए, "ps aux"।

• कुल आउट-ऑफ-कंट्रोल अपाचे सर्वर या पोस्टग्रैस्कल उदाहरण की पहचान करने के लिए कार्यों की कुल संख्या जानना उपयोगी है, लेकिन यह आमतौर पर काफी स्थिर रहता है।

• रनिंग प्रक्रियाओं की संख्या आपको दिखाती है कि वर्तमान में आपके प्रोसेसर का उपयोग कैसे किया जा रहा है। ऐसे अनुप्रयोग जिनमें एक समय में मल्टीथ्रेडिंग नहीं होता है, एक नियम के रूप में, 1 प्रोसेसर का उपयोग कर सकते हैं, इसलिए सामान्य स्थिति तब होती है जब 1 प्रक्रिया क्वाड-कोर सर्वर के प्रोसेसर का 25% का उपयोग करती है, जिसमें ~ 1 का औसत लोड होता है।

• सो रही है प्रतीक्षा प्रक्रियाओं की संख्या इंगित करती है कि कौन सी प्रक्रिया चल रही है, लेकिन सक्रिय नहीं हैं; ये आमतौर पर बैकग्राउंड टास्क, सिस्टम सॉफ्टवेयर, प्रिंटर ड्राइवर आदि होते हैं।

• रोक दी गई प्रक्रियाओं की संख्या आमतौर पर 0 होनी चाहिए जब तक कि आपने समस्या निवारण के लिए SIGSTOP या किल -STOP प्रक्रिया को नहीं भेजा। यदि यह संख्या 0 से भिन्न है, तो उत्पादन सर्वरों के मामले में, यह चिंता का कारण हो सकता है।

• ज़ोंबी हैंगिंग प्रोसेस। इसका मतलब यह है कि एक बहु-थ्रेडेड एप्लिकेशन ने एक बच्चे की प्रक्रिया शुरू की और फिर उसे मार दिया गया या अप्रत्याशित रूप से समाप्त कर दिया गया, जिससे एक झूलने वाली प्रक्रिया को एक ज़ोंबी प्रक्रिया के रूप में जाना गया। अपाचे ऐसी प्रक्रियाओं का एक पूरा गुच्छा पैदा कर सकता है जब मामले में कुछ सामान्य होता है। आमतौर पर, उनकी संख्या भी 0 होनी चाहिए।

स्ट्रिंग सीपीयू

मैं इस जानकारी को दो भागों में तोड़ दूंगा, इनमें वे आँकड़े हैं जो हमारे उपयोग के लिए महत्वपूर्ण हैं।



Cpu(s): 0.0%us, 0.0%sy, 0.0%ni, 99.9%id,





यहां दिए गए पहले चार मूल्य लिनक्स के साथ सभी सर्वरों पर मौजूद हैं, और वे ज्यादातर लोगों से परिचित हैं।

• % हमें 100% की अधिकतम कीमत तक एक अलग प्रोसेसर (जैसे अपाचे, mysql, आदि जैसे उपयोगकर्ता प्रक्रियाओं द्वारा) का उपयोग दिखाता है। इस प्रकार, यदि कोई प्रक्रिया क्वाड-कोर प्रोसेसर 1 में 100% सीपीयू का उपयोग करती है, तो यह हमें 25% का मूल्य प्रदान करेगा। 8-कोर प्रोसेसर के लिए 12.5% ​​के मूल्य का मतलब है कि एक कोर व्यस्त है।

• % sy का मतलब है कि CPU सिस्टम का उपयोग कर रहा है। आमतौर पर यह मान अधिक नहीं होता है, इसके उच्च मान कर्नेल कॉन्फ़िगरेशन, ड्राइवर की समस्या या कई अन्य चीज़ों के साथ समस्या का संकेत दे सकते हैं।

• % ni का अर्थ है सीपीयू का प्रतिशत जो उपयोगकर्ता की प्रक्रियाओं द्वारा उपयोग किया जाता है जो अच्छे या त्याग आदेशों से प्रभावित होता है, अर्थात। अनिवार्य रूप से, उनकी प्राथमिकता को शेड्यूलर द्वारा उच्च या निम्न को सौंपी गई डिफ़ॉल्ट प्राथमिकता से बदल दिया गया है। जब एक अच्छी कमान एक प्रक्रिया को सौंपी जाती है, तो एक सकारात्मक संख्या का मतलब कम प्राथमिकता (सामान्य से 1 = 1 कदम नीचे) होता है, और नकारात्मक संख्या का मतलब उच्च प्राथमिकता होता है। 0 डिफ़ॉल्ट मान है, जिसका अर्थ है कि अनुसूचक प्राथमिकता पर निर्णय लेता है। आप यह निर्धारित कर सकते हैं कि आपके सिस्टम द्वारा किस शेड्यूलर का उपयोग किया गया है, लेकिन यह निम्नलिखित लेखों के लिए अधिक जटिल विषय है। इसके अलावा, इस लेख में दिए गए किसी भी प्रतिशत का मूल्य उस% मान के साथ ओवरलैप नहीं होता है, जो केवल उपयोगकर्ता प्रक्रियाओं को अनिर्धारित प्राथमिकता से दिखाता है।

• % आईडी - 100.0% से तीन पिछले मानों को घटाकर और "बेकार" कंप्यूटिंग शक्ति को मापने के द्वारा प्राप्त किया गया परिणाम।



0.0%wa, 0.0%hi, 0.0%si, 0.0%st





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



• % वा - आयोवाइट, समय का प्रतिशत (चक्र, सेकंड) जिसके दौरान प्रोसेसर निष्क्रिय था, I / O ऑपरेशन के पूरा होने की प्रतीक्षा कर रहा था। जब कोई प्रक्रिया या प्रोग्राम डेटा का अनुरोध करता है, तो यह पहले प्रोसेसर के कैश (इसमें 2 या 3 कैश) की जांच करता है, फिर मेमोरी की जांच करता है और अंत में डिस्क पर पहुंचता है। डिस्क तक पहुंचने के बाद, प्रक्रिया या कार्यक्रम को आमतौर पर तब तक इंतजार करना पड़ता है जब तक कि इनपुट-आउटपुट स्ट्रीम रैम पर सूचना स्थानांतरित करने से पहले फिर से काम करने में सक्षम होने से पहले। धीमी डिस्क, प्रत्येक प्रक्रिया के लिए IO प्रतीक्षा% मान जितना अधिक होगा। यह डिस्क के लेखन के साथ भी होता है यदि सिस्टम बफर भरा हुआ है और कर्नेल के साथ साफ करने की आवश्यकता है - यह आमतौर पर उच्च लोड वाले डेटाबेस सर्वर पर देखा जाता है। यदि IO प्रतीक्षा का मान {100 / (CPU की संख्या * प्रक्रियाओं की संख्या)}% से अधिक है, तो इसका मतलब है कि भंडारण की समस्या हो सकती है जिससे निपटने की आवश्यकता है। यदि आप एक उच्च औसत लोड का निरीक्षण करते हैं, तो पहले इस पैरामीटर की जाँच करें। यदि यह उच्च है, तो डिस्क पर जमा होने वाली प्रक्रियाओं में अड़चन है, और किसी और चीज में नहीं।

• लौह स्तर पर % हाय का अर्थ है रुकावट; एक सर्किट बोर्ड पर, इलेक्ट्रॉनों एक अनुमानित तरीके से चिप्स में यात्रा करते हैं। उदाहरण के लिए, जब एक नेटवर्क कार्ड एक पैकेट प्राप्त करता है, तो कोर के माध्यम से पैकेट में निहित जानकारी को प्रोसेसर में स्थानांतरित करने से पहले, यह मदरबोर्ड के इंटरप्ट चैनल में एक बाधा का अनुरोध करेगा। प्रोसेसर कर्नेल को बताता है कि नेटवर्क कार्ड में इसके लिए जानकारी है, और कर्नेल में यह तय करने की क्षमता है कि क्या करना है। लोहे के स्तर पर समय बिताए प्रसंस्करण समय का उच्च मूल्य एक आभासी मशीन में काफी दुर्लभ है, लेकिन जैसा कि हाइपरविजर अधिक से अधिक हार्डवेयर वर्चुअल मशीनों के लिए उपलब्ध कराते हैं, यह स्थिति बदल सकती है। अत्यधिक उच्च नेटवर्क बैंडविड्थ, यूएसबी का उपयोग, जीपीयू पर कंप्यूटिंग - यह सब इस पैरामीटर में कई प्रतिशत से अधिक राशि की वृद्धि का कारण बन सकता है।

• % सी - सॉफ्टवेयर स्तर पर रुकावट; लिनक्स संस्करण 2.4 कर्नेल सॉफ्टवेयर (अनुप्रयोगों) द्वारा रुकावट का अनुरोध करने की क्षमता को लागू करता है, और हार्डवेयर तत्व या डिवाइस (ड्राइवर) द्वारा मदरबोर्ड इंटरप्ट चैनल में रुकावट का अनुरोध नहीं करता है; अनुरोध कर्नेल द्वारा उसके इंटरप्ट हैंडलर के माध्यम से दिया जाता है। इसका मतलब है कि एप्लिकेशन प्राथमिकता स्थिति का अनुरोध कर सकता है, कर्नेल कमांड की प्राप्ति की पुष्टि कर सकता है, और सॉफ्टवेयर धैर्यपूर्वक तब तक इंतजार करेगा जब तक कि बाधा उत्पन्न न हो जाए। यदि हम उच्च ट्रैफ़िक वाले गीगाबिट चैनल में tcpdump उपयोगिता को लागू करते हैं, तो मान लगभग 10% बदल सकता है, - क्योंकि आवंटित tcpdump मेमोरी पूर्ण हो जाती है, उपयोगिता स्टैक से डिस्क, स्क्रीन, या कहीं और डेटा स्थानांतरित करने के लिए एक बस भेजती है।

• % st सूची से सबसे महत्वपूर्ण पैरामीटर है, मेरी राय में, यह IOSteal% है। एक वर्चुअलाइज्ड वातावरण में, कई लॉजिकल सर्वर एक ही वास्तविक हाइपरवाइजर के तहत चल सकते हैं। प्रत्येक वर्चुअल मशीन (वीएम) हम 4-8 "वर्चुअल" सीपीयू प्रदान करते हैं; हालांकि हाइपरविजर्स में स्वयं (वीएम की संख्या प्रति वर्चुअल सीपीयू की संख्या) नहीं हो सकती है। इसका कारण यह है कि हम अपनी आभासी मशीनों का उपयोग करके सीपीयू को अधिभार नहीं देते हैं, इसलिए यदि हम एक या दो वीएम को कभी-कभी 8 प्रोसेसर का उपयोग करने की अनुमति देते हैं, तो यह पूरे पूल को नकारात्मक रूप से प्रभावित नहीं करेगा। हालांकि, यदि वर्चुअल वीएम प्रोसेसर द्वारा उपयोग किए जाने वाले सीपीयू की संख्या भौतिक (या तार्किक, एक्सॉन हाइपर-थ्रेडेड प्रोसेसर के मामले में) से अधिक है, तो आईओस्टाइल मूल्य में वृद्धि होगी।



iosteal% - हाइपरविज़र कार्यभार का माप; किसी भी पूल में वर्चुअल मशीन की मौजूदगी जो कि iosteal% पैरामीटर के लगातार उच्च मूल्य (15% से अधिक) को प्रदर्शित करती है, पूल के दूसरे भाग में कुछ VMs को स्थानांतरित करने की आवश्यकता का संकेत दे सकती है।



iowait% डिस्क प्रदर्शन का एक उपाय है। NetApp द्वारा समर्थित स्टोरेज सिस्टम में, हम वॉल्यूम को कम-उपयोग किए गए, या अन्य NetApp ड्राइव पर ले जाए बिना प्रदर्शन की समस्या को हल करने में सक्षम नहीं हो सकते हैं। एक स्थानीय डिस्क (एसएसडी या एसएएस) के मामले में, इसका मतलब यह हो सकता है कि हाइपरविजर में बहुत सारे वीएम हैं जो डिस्क संसाधनों का गहनता से उपयोग कर रहे हैं, और आपको इन वीएम में से कुछ को पूल के दूसरे हिस्से में स्थानांतरित करने की आवश्यकता हो सकती है।

संक्षेप में:

• औसत भार, वास्तव में, कुछ भी मतलब नहीं है।

• औसत लोड के लिए पैरामीटर % यूजरलैंड (% us) महत्वपूर्ण है क्योंकि यह इंगित करता है कि गणना की जा रही है। उदाहरण के लिए, mysql केवल एक धागा लेगा, इसलिए यह इसे पूर्ण लोड (वीएम द्वारा सौंपे गए वर्चुअल सीपीयू की संख्या) पर उपयोग करेगा। Postgresql बहु-थ्रेडेड है, और यदि वे आवंटित किए गए हैं तो अधिक प्रोसेसर का उपयोग कर सकते हैं - इसे रोकने के लिए एक हाइपरविजर में वर्चुअल मशीन बनाते समय इसे ध्यान में रखें:

• % st - आयोस्टल% - हाइपरविजर वर्कलोड का संकेतक। एक व्यवसायिक दृष्टिकोण से 4 पोस्टग्रैक्स्ल और 6 टॉमकैट सर्वर का एक स्टैक बनाना उचित हो सकता है, लेकिन आपको हर समय सीपीयू समय के लिए प्रतिस्पर्धा करनी होगी।

• % वा - आयोवाइट% - अपनी प्रक्रियाओं को अविश्वसनीय रूप से धीमी डिस्क पर भेजने के लिए जितना समय लगता है, उसका एक संकेतक, कोई फर्क नहीं पड़ता कि आप किस भंडारण समाधान का उपयोग करते हैं। ड्राइव, यहां तक ​​कि SSDs, अपेक्षाकृत धीमी हैं। कर्नेल बफर को बढ़ाने के लिए RAM जोड़ने से समस्या थोड़ी कम हो सकती है। रैम एक डिस्क की तुलना में सस्ता है, यह देखते हुए कि इसकी तुलना में यह कितना तेज़ है।

अतिरिक्त टीमें

iostat





यदि आप iowait या iosteal मापदंडों के उच्च मूल्यों का सामना करते हैं, तो आप सही ढंग से ट्रैक कर सकते हैं कि iostit कमांड का उपयोग करके कौन सा ड्राइव इसका कारण है। यह इस तरह से शुरू होता है:







अधिक विवरण के लिए iostat मैनुअल देखें। ब्रेकडाउन ने हर सेकंड को प्रदर्शित किया, जिसमें से पढ़ने और लिखने के लिए डिस्क, साथ ही इन डिस्क्स के उपयोग से जुड़े सभी iosteal या iowait मान शामिल हैं।



htop





सीपीयू और लिनक्स सिस्टम पर प्रक्रियाओं के उपयोग पर टीम। यह आभासी आंकड़े नहीं दिखाता है, लेकिन प्रक्रियाओं के एक पेड़ को प्रदर्शित करता है, साथ ही सिस्टम में प्रत्येक प्रोसेसर के टूटने, इसके उपयोग; इसके अलावा, यह अप्रिय मेमोरी लीक को ट्रैक करने के लिए स्वैप और मेमोरी के आंकड़े दिखाता है, यह सभी को सुंदर रंगों के साथ रंग देता है। मेरी राय में, यह पैकेज सभी वीएम के लिए अनिवार्य होना चाहिए।



एक छोटा सा विज्ञापन। जैसा कि हमने शुरुआत में कहा था, अब हम सक्रिय रूप से आंतरिक सर्वर मापदंडों की निगरानी का परीक्षण कर रहे हैं, यदि आप बंद बीटा परीक्षण में भाग लेना चाहते हैं, तो हमें ht2support@host-tracker.com पर लिखें।