VMware पर चलने वाले वर्चुअलाइज्ड SQL सर्वर पर CPU प्रदर्शन समस्याओं का निवारण करते समय, सबसे पहले मैं यह सत्यापित करता हूं कि वर्चुअल मशीन कॉन्फ़िगरेशन प्रदर्शन समस्या के लिए एक योगदान कारक नहीं है। जहां एक भौतिक सर्वर के पास ओएस को समर्पित 100% उपलब्ध संसाधन हैं, एक वर्चुअल मशीन नहीं है, इसलिए कुछ बुनियादी वस्तुओं को सामने से देखने से गलत समस्या का निवारण और समय बर्बाद हो जाता है। अतीत में मैंने डीबीए के महत्व के बारे में ब्लॉग किया है जिसमें प्रदर्शन समस्याओं की बुनियादी समस्या निवारण के लिए वीएमवेयर के लिए वर्चुअल सेंटर तक केवल पढ़ने के लिए पहुंच है। हालांकि, वर्चुअल सेंटर तक पहुंच के बिना भी, विंडोज के अंदर कुछ बुनियादी जानकारी का पता लगाना अभी भी संभव है, जिससे संभावित होस्ट स्तर की समस्याएं हो सकती हैं जो प्रदर्शन को प्रभावित कर रही हैं।
प्रत्येक VMware वर्चुअल मशीन में विंडोज़ में दो प्रदर्शन काउंटर समूह होते हैं जो अतिथि में VMware उपकरण स्थापित होने पर जोड़े जाते हैं; वीएम प्रोसेसर और वीएम मेमोरी। जब भी मैं VMware पर वर्चुअल मशीन के साथ काम कर रहा होता हूं, तो ये प्रदर्शन काउंटर पहली चीजों में से एक हैं, क्योंकि वे आपको एक नज़र डालते हैं कि VM को हाइपरवाइजर से कौन से संसाधन प्राप्त हो रहे हैं। VM प्रोसेसर समूह में निम्नलिखित काउंटर हैं:
- % प्रोसेसर समय
- मेगाहर्ट्ज में प्रभावी वीएम स्पीड
- मेगाहर्ट्ज में होस्ट प्रोसेसर की गति
- मेगाहर्ट्ज में सीमा
- मेगाहर्ट्ज में आरक्षण
- शेयर
एक वीएम अतिथि पर जो टास्क मैनेजर या परफमन में एक उच्च प्रोसेसर\% प्रोसेसर समय दिखा रहा है, वीएम प्रोसेसर काउंटरों की जांच करने से वीएम अतिथि को प्राप्त होने वाले वास्तविक संसाधन आवंटन का सटीक खाता मिल जाएगा। यदि मेगाहर्ट्ज में होस्ट प्रोसेसर की गति 3000 है और अतिथि के पास 8 वर्चुअल सीपीयू हैं, तो वीएम के लिए अधिकतम प्रभावी गति 24000 मेगाहर्ट्ज है और मेगाहर्ट्ज काउंटर में प्रभावी वीएम स्पीड यह दर्शाएगी कि क्या वीएम वास्तव में संसाधन प्राप्त कर रहा है। मेज़बान। आमतौर पर जब ऐसा होता है, तो आपको समस्या के मूल कारण का निदान करने के लिए मेजबान स्तर की जानकारी को देखना शुरू करना होगा। लेकिन हाल ही में एक क्लाइंट एंगेजमेंट में, ऐसा नहीं हुआ।
इस मामले में क्लाइंट वीएम ऊपर वर्णित कॉन्फ़िगरेशन से मेल खाता है और इसकी अधिकतम प्रभावी गति 24000 मेगाहर्ट्ज है लेकिन मेगाहर्ट्ज काउंटर में प्रभावी वीएम स्पीड केवल 6900 मेगाहर्ट्ज के आसपास औसत थी, वीएम विंडोज प्रतिशत प्रोसेसर समय लगभग 100% आंकी गई थी। मेगाहर्ट्ज काउंटर में प्रभावी वीएम स्पीड के ठीक नीचे देखने से समस्या का कारण पता चला:मेगाहर्ट्ज में सीमा 7000 थी, जिसका अर्थ है कि वीएम के पास ईएसएक्स में 7000 मेगाहर्ट्ज पर सीपीयू उपयोग की एक कॉन्फ़िगर की गई टोपी थी, इसलिए इसे हाइपरवाइजर द्वारा लगातार थ्रॉटल किया जा रहा था। भार।
इसके लिए स्पष्टीकरण यह था कि इस विशेष VM का उपयोग अवधारणा के प्रमाण में परीक्षण उद्देश्यों के लिए किया गया था और मूल रूप से एक व्यस्त VM होस्ट पर सह-स्थित था; VM व्यवस्थापक उस होस्ट पर प्रदर्शन समस्याओं के कारण अज्ञात कार्यभार नहीं चाहते थे। इसलिए, यह सुनिश्चित करने के लिए कि यह पीओसी के दौरान मेजबान पर वास्तविक उत्पादन कार्यभार को नकारात्मक रूप से प्रभावित नहीं करेगा, यह केवल 7000 मेगाहर्ट्ज सीपीयू या मेजबान पर 2 1/3 भौतिक कोर के बराबर की अनुमति देने के लिए सीमित था। अंततः, ESX में VM CPU लिमिट को हटाने से विंडोज़ के भीतर उच्च CPU समस्याएँ समाप्त हो गईं, और क्लाइंट द्वारा अनुभव की जा रही प्रदर्शन समस्याएँ दूर हो गईं।
VM मेमोरी काउंटर समूह SQL सर्वर के लिए संभावित प्रदर्शन समस्याओं की पहचान करने के लिए VM प्रोसेसर समूह जितना ही महत्वपूर्ण है। VM मेमोरी काउंटर समूह में निम्नलिखित काउंटर होते हैं:
<उल स्टाइल ="फ्लोट:लेफ्ट">- एमबी में साझा की गई मेमोरी
- मेमोरी साझा एमबी में सहेजी गई
- मेमोरी शेयर
- मेमोरी एमबी में बदली गई
- एमबी में प्रयुक्त मेमोरी
इन काउंटरों में से, जिन काउंटरों को मैं विशेष रूप से देखता हूं वे हैं एमबी में मेमोरी बैलूनेड और एमबी में मेमोरी स्वैप्ड, दोनों ही SQL सर्वर वर्कलोड के लिए शून्य होना चाहिए। एमबी काउंटर में मेमोरी बैलूनड बताता है कि होस्ट पर मेमोरी ओवरकमिट के कारण बैलून ड्राइवर द्वारा अतिथि वीएम से कितनी मेमोरी को पुनः प्राप्त किया गया है, जिससे SQL सर्वर मेमोरी के उपयोग को कम करने के लिए विंडोज में बैलून ड्राइवर के कारण होने वाले मेमोरी प्रेशर का जवाब देगा। मेमोरी को VM से दूर ले जाने के लिए फुलाते हुए। एमबी काउंटर में मेमोरी की अदला-बदली यह ट्रैक कर रही है कि होस्ट पर मेमोरी ओवरकमिट के कारण होस्ट हाइपरवाइजर द्वारा डिस्क पर कितनी मेमोरी को पेज किया गया था जिसे बैलून ड्राइवर के साथ वीएम मेहमानों को बैलून करके हल नहीं किया जा सकता था। SQL सर्वर के लिए VMware की सर्वोत्तम अभ्यास मार्गदर्शिका यह सुनिश्चित करने के लिए आरक्षण का उपयोग करने की अनुशंसा करती है कि SQL सर्वर प्रदर्शन कारणों से गुब्बारा या पेज आउट नहीं होता है, लेकिन कई VM व्यवस्थापक स्थिर आरक्षण सेट करने में संकोच करते हैं क्योंकि यह पर्यावरणीय लचीलेपन को कम करता है।
SentryOne V Sentry जैसे मॉनिटरिंग टूल भी मदद कर सकते हैं। उस मामले पर विचार करें जहां आपके पास vCenter तक सीधी पहुंच नहीं हो सकती है, लेकिन कोई आपकी ओर से इसके खिलाफ निगरानी स्थापित कर सकता है। अब आप अतिथि और मेजबान दोनों स्तरों पर सीपीयू, मेमोरी, और यहां तक कि डिस्क मुद्दों में शानदार विज़ुअलाइज़ेशन और अंतर्दृष्टि प्राप्त कर सकते हैं - और इसके साथ आने वाले सभी इतिहास भी। नीचे डैशबोर्ड पर, आप बाईं ओर होस्ट मेट्रिक (सह-स्टॉप और रेडी टाइम के लिए CPU ब्रेकडाउन सहित) और दाईं ओर गेस्ट मेट्रिक देख सकते हैं:
SentryOne से इसे और अन्य कार्यक्षमता को आज़माने के लिए, आप एक निःशुल्क परीक्षण डाउनलोड कर सकते हैं।
निष्कर्ष
VMware पर वर्चुअलाइज्ड SQL सर्वर पर प्रदर्शन समस्याओं का निवारण करते समय, केवल सीमित जानकारी का उपयोग करके "घुटने-झटका" समस्या निवारण करने के बजाय समस्या को समग्र दृष्टिकोण से देखना महत्वपूर्ण है। प्रदर्शन मॉनिटर में VMware-विशिष्ट काउंटर समस्या के निवारण के लिए आगे कदम उठाने से पहले, यह सत्यापित करने का एक शानदार तरीका हो सकता है कि VM को होस्ट से मूल संसाधन आवंटन मिल रहा है।
