SQL सर्वर पर VMware CPU हॉट प्लग vNUMA प्रभाव

जब विंडोज सर्वर 2012 में ईएसएक्स 5 और हाइपर-वी ने वीएम आकारों के लिए पहले से मौजूद सीमाओं को जारी किया और बदल दिया, तो मुझे लगभग तुरंत पता चल गया कि हम अधिक बड़े पैमाने पर SQL सर्वर वर्कलोड को वर्चुअलाइज्ड करना शुरू कर देंगे। मैंने पिछले वर्ष में कई ग्राहकों के साथ काम किया है जो विभिन्न कारणों से 16-32 कोर SQL सर्वर का वर्चुअलाइजेशन कर रहे थे, सरलीकृत आपदा रिकवरी रणनीतियों से, जो कि शेष व्यवसाय से मेल खाती थी, समेकन और नए हार्डवेयर पर स्वामित्व की कुल लागत को कम करने के लिए। मंच। ESX 5+ के साथ मापनीयता परिवर्तन के कारणों में से एक व्यापक मेहमानों के लिए वर्चुअल NUMA (vNUMA) का परिचय था जो एक व्यक्तिगत हार्डवेयर NUMA नोड के आकार से अधिक था। VNUMA के साथ, अतिथि VM को हार्डवेयर NUMA टोपोलॉजी से मेल खाने के लिए अनुकूलित किया गया है, जिससे अतिथि ऑपरेटिंग सिस्टम और किसी भी NUMA जागरूक एप्लिकेशन, जैसे SQL सर्वर, जो NUMA प्रदर्शन अनुकूलन का लाभ लेने के लिए VM पर चल रहे हैं, जैसे कि वे थे भौतिक सर्वर पर चल रहा है।

VMware के भीतर, एक vNUMA टोपोलॉजी हार्डवेयर संस्करण 8 या उच्चतर पर उपलब्ध है, और यदि अतिथि के लिए vCPU की संख्या आठ से अधिक है, तो डिफ़ॉल्ट रूप से कॉन्फ़िगर हो जाती है। उन्नत कॉन्फ़िगरेशन विकल्पों का उपयोग करके VM के लिए vNUMA टोपोलॉजी को मैन्युअल रूप से कॉन्फ़िगर करना भी संभव है, जो VMs के लिए उपयोगी हो सकता है जिनके पास भौतिक NUMA नोड की तुलना में उन्हें अधिक मेमोरी आवंटित की जा सकती है, लेकिन फिर भी आठ या उससे कम vCPU का उपयोग करता है। अधिकांश भाग के लिए, डिफ़ॉल्ट कॉन्फ़िगरेशन सेटिंग्स अधिकांश VMs के लिए काम करती हैं जिन्हें मैंने पिछले कुछ वर्षों में देखा है, लेकिन कुछ ऐसे परिदृश्य हैं जहाँ डिफ़ॉल्ट vNUMA टोपोलॉजी आदर्श नहीं है और मैन्युअल कॉन्फ़िगरेशन कुछ लाभ प्रदान कर सकता है। हाल ही में मैं एक क्लाइंट के साथ काम कर रहा था जिसमें 32 वीसीपीयू एसक्यूएल सर्वर वीएम 512 जीबी रैम के साथ कुछ प्रदर्शन ट्यूनिंग कर रहे थे, जहां वीएनयूएमए टोपोलॉजी उम्मीद के मुताबिक कुछ भी नहीं थी।

इस वातावरण में VM होस्ट सर्वर चार सॉकेट E5-4650 आठ कोर प्रोसेसर और 1TB RAM थे, प्रत्येक विशिष्ट संचालन के तहत एक एकल SQL सर्वर VM को समर्पित था, लेकिन एक विफलता परिदृश्य में दो VMs को बनाए रखने की उपलब्ध क्षमता के साथ। इस हार्डवेयर लेआउट के साथ, चार NUMA नोड्स हैं, एक प्रति सॉकेट, और अपेक्षित VM कॉन्फ़िगरेशन में 32 vCPU कॉन्फ़िगरेशन के लिए 4 vNUMA नोड्स भी होंगे। हालाँकि, SQL सर्वर में DMV को देखते हुए मैंने जो पाया वह यह था कि ऐसा नहीं था:

चित्र 1 - गलत vNUMA कॉन्फ़िगरेशन

जैसा कि आप शायद छवि में देख सकते हैं, इस सर्वर पर NUMA कॉन्फ़िगरेशन में वास्तव में कुछ गड़बड़ है। SQLOS में चार मेमोरी नोड होते हैं और केवल एक CPU नोड होता है, जिसमें सभी vCPU आवंटित होते हैं। पूरी तरह से ईमानदार होने के लिए, जब मैंने इसे देखा तो इसने मेरे दिमाग को उड़ा दिया क्योंकि यह सब कुछ के खिलाफ था जो मुझे पता था कि SQLOS ने स्टार्टअप पर आंतरिक संरचनाओं को कैसे कॉन्फ़िगर किया। एररलॉग फाइलों, परफॉर्मेंस मॉनिटर और विंडोज टास्क मैनेजर में थोड़ा सा खोदने के बाद, मैंने SysInternals से CoreInfo की एक कॉपी डाउनलोड की, और विंडोज को रिपोर्ट किए जा रहे NUMA लेआउट पर एक नज़र डाली।

NUMA नोड मैप के लिए लॉजिकल प्रोसेसर:
******************************** NUMA नोड 0

CoreInfo आउटपुट ने पुष्टि की कि VM 32 vCPU को 4 अलग-अलग सॉकेट के रूप में प्रस्तुत करता है, लेकिन फिर सभी 32 vCPU को NUMA नोड 0 में समूहीकृत किया। VM पर Windows Server 2012 के प्रदर्शन काउंटर को देखते हुए मैं NUMA नोड मेमोरी काउंटर समूह से देख सकता था, कि 4 NUMA मेमोरी नोड्स को OS में प्रस्तुत किया गया था, जिसमें मेमोरी समान रूप से नोड्स में वितरित की गई थी। यह सब SQLOS में जो मैं देख रहा था, उसके साथ पंक्तिबद्ध था, और मैं स्टार्टअप ERRORLOG प्रविष्टियों से यह भी बता सकता था कि नोड के लिए सीपीयू मास्क सभी उपलब्ध सीपीयू को सीपीयू नोड 0 में मास्क कर रहा था, लेकिन चार बड़े पृष्ठ आवंटक बनाए जा रहे थे, एक के लिए प्रत्येक मेमोरी नोड।

इस बिंदु पर मुझे यकीन था कि यह VM कॉन्फ़िगरेशन से संबंधित कुछ था, लेकिन मैं यह नहीं पहचान सका कि विशेष रूप से समस्या क्या थी क्योंकि मैंने इस व्यवहार को अन्य व्यापक SQL सर्वर VMs पर कभी नहीं देखा था कि मैं VMware ESX 5+ पर ग्राहकों की सहायता करता था। पिछले। उपलब्ध परीक्षण VM सर्वर में कुछ कॉन्फ़िगरेशन परिवर्तन करने के बाद, उनमें से केवल किसी ने भी VM के अंदर प्रस्तुत किए जा रहे vNUMA कॉन्फ़िगरेशन को सही नहीं किया। VMware समर्थन में कॉल करने के बाद, हमें परीक्षण VM के लिए vCPU हॉटप्लग सुविधा को अक्षम करने और यह देखने के लिए कहा गया कि क्या इससे समस्या ठीक हुई है। VM पर हॉटप्लग अक्षम होने के साथ, CoreInfo आउटपुट ने पुष्टि की कि VM के लिए प्रोसेसर की vNUMA मैपिंग अब सही थी:

NUMA नोड मैप के लिए लॉजिकल प्रोसेसर:
********———————— NUMA नोड 0
——–********————— - NUMA नोड 1
—————********——– NUMA नोड 2
———————******** NUMA नोड 3

यह व्यवहार वास्तव में अक्टूबर 2013 से VMware KB आलेख में प्रलेखित है, (vNUMA अक्षम है यदि VCPU हॉटप्लग सक्षम है)। एक विशिष्ट कॉन्फ़िगरेशन नहीं है जिसकी मैं 32 वीसीपीयू वीएम के लिए अपेक्षा करता हूं, लेकिन क्लाइंट पर उपयोग किए जा रहे मानक टेम्पलेट का एक हिस्सा था और उनके SQL सर्वर को प्रभावित करने के लिए हुआ।

vNUMA के अक्षम होने के प्रभाव

ऐसे कई प्रभाव हैं जो vNUMA को इस तरह अक्षम किए जाने के कारण कार्यभार हो सकता है, लेकिन दो विशिष्ट समस्याएं हैं जो विशेष रूप से इस प्रकार के कॉन्फ़िगरेशन के तहत SQL सर्वर को प्रभावित कर सकती हैं। पहला यह है कि सर्वर को CMEMTHREAD प्रतीक्षा संचय के साथ समस्या हो सकती है क्योंकि एक NUMA नोड को 32 vCPU आवंटित किए गए हैं, और SQLOS में मेमोरी ऑब्जेक्ट के लिए डिफ़ॉल्ट विभाजन प्रति NUMA नोड है। इस विशिष्ट समस्या को बॉब डोर द्वारा Microsoft में CSS समूह में उनके ब्लॉग पोस्ट SQL Server 2008/2008 R2 पर 8 से अधिक CPU के साथ नई मशीनों पर प्रलेखित किया गया था, प्रति NUMA नोड को ट्रेस फ्लैग 8048 की आवश्यकता हो सकती है। प्रतीक्षा आँकड़े समीक्षा करने के एक भाग के रूप में क्लाइंट के साथ VM पर मैंने देखा कि CMEMTHREAD उनका दूसरा उच्चतम प्रतीक्षा प्रकार था, जो मेरे अनुभव से असामान्य है और मुझे ऊपर चित्र 1 में दिखाए गए SQLOS NUMA कॉन्फ़िगरेशन को देखने का कारण बना। इस मामले में ट्रेस फ्लैग समाधान नहीं है, VM कॉन्फ़िगरेशन से vCPU हॉटप्लग को हटाने से समस्या हल हो जाती है।

दूसरी समस्या जो SQL सर्वर को विशेष रूप से प्रभावित करती है यदि आप एक अप्रकाशित संस्करण पर हैं, SQLOS में NUMA मेमोरी प्रबंधन से जुड़ी है, और जिस तरह से SQLOS प्रारंभिक मेमोरी रैंप-अप चरण के दौरान उदाहरण स्टार्टअप के दौरान दूर पृष्ठों को ट्रैक और प्रबंधित करता है। इस व्यवहार को बॉब डोर द्वारा CSS ब्लॉग पोस्ट, हाउ इट वर्क्स:SQL सर्वर (NUMA लोकल, फॉरेन एंड अवे मेमोरी ब्लॉक्स) पर प्रलेखित किया गया था। अनिवार्य रूप से, जब SQLOS प्रारंभिक रैंप-अप के दौरान स्थानीय नोड मेमोरी आवंटन का प्रयास करता है, यदि लौटाया गया स्मृति पता एक अलग मेमोरी नोड से है, तो पृष्ठ को दूर सूची में जोड़ा जाता है, और एक अन्य स्थानीय स्मृति आवंटन प्रयास होता है, और प्रक्रिया तब तक दोहराती है जब तक एक स्थानीय स्मृति आवंटन सफल होता है, या सर्वर स्मृति लक्ष्य तक पहुँच जाता है। चूंकि हमारी तीन चौथाई इंस्टेंस मेमोरी NUMA नोड्स पर बिना किसी शेड्यूलर के मौजूद है, यह उदाहरण के लिए मेमोरी के प्रारंभिक रैंप-अप के दौरान एक खराब प्रदर्शन की स्थिति बनाता है। हाल के अद्यतनों ने प्रारंभिक रैंप-अप के दौरान स्मृति आवंटन के व्यवहार को बदल दिया है ताकि प्रसंस्करण जारी रखने के लिए विदेशी स्मृति का उपयोग करने से पहले केवल स्थानीय स्मृति आवंटन को एक निश्चित संख्या में (विशिष्ट संख्या का दस्तावेजीकरण नहीं किया गया) करने का प्रयास किया जा सके। उन अद्यतनों को KB #2819662, FIX में प्रलेखित किया गया है:NUMA परिवेशों में SQL सर्वर प्रदर्शन समस्याएँ।

सारांश

विस्तृत वीएम के लिए, जिसे 8 से अधिक वीसीपीयू के रूप में परिभाषित किया गया है, यह वांछनीय है कि वीएनयूएमए को हाइपरवाइजर द्वारा वीएम में पास किया जाए ताकि विंडोज और एसक्यूएल सर्वर को उनके कोड बेस के भीतर NUMA ऑप्टिमाइज़ेशन का लाभ उठाने की अनुमति मिल सके। परिणामस्वरूप, इन व्यापक VMs में vCPU हॉटप्लग कॉन्फ़िगरेशन सक्षम नहीं होना चाहिए, क्योंकि यह vNUMA के साथ असंगत है और इसके परिणामस्वरूप वर्चुअलाइज्ड होने पर SQL सर्वर के लिए खराब प्रदर्शन हो सकता है।