हाइपर-वी . के भीतर डायनेमिक मेमोरी का उपयोग करते समय जोखिम

वर्चुअलाइजेशन संगठनों के लिए बहुत लोकप्रिय है:यह उन्हें एक ही होस्ट पर कई सर्वरों को जोड़कर हार्डवेयर का बेहतर उपयोग करने की अनुमति देता है, HA क्षमताएं प्रदान करता है, और हीटिंग/कूलिंग, SQL सर्वर लाइसेंस और हार्डवेयर जैसी विभिन्न लागतों में कमी देता है। मैं संगठनों के साथ कई परियोजनाओं में शामिल रहा हूं ताकि उन्हें भौतिक से आभासी वातावरण में माइग्रेट करने में मदद मिल सके और इन लाभों का अनुभव करने में उनकी मदद की हो।

इस लेख में मैं आपके साथ जो साझा करना चाहता हूं वह एक अजीबोगरीब समस्या है जो मुझे डायनेमिक मेमोरी का उपयोग करते हुए विंडोज सर्वर 2012 आर 2 पर हाइपर-वी के साथ काम करते समय आई थी। मुझे यह स्वीकार करना होगा कि वर्चुअलाइजेशन के बारे में मेरा अधिकांश ज्ञान VMware के साथ रहा है, हालांकि यह अब बदल रहा है।

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

हाइपर-वी के साथ खेलते हुए मैंने पाया है कि वर्चुअल मशीनों को सरल और सीखने में आसान बनाने के लिए प्रावधान किया गया है। थोड़े से प्रयास से मैं अपने ग्राहक के अनुभव का अनुकरण करने के लिए एक प्रयोगशाला वातावरण बनाने में सक्षम था। मुझे काम करने के लिए शानदार हार्डवेयर प्रदान करने का श्रेय मेरे बॉस को जाता है। मैं एक i7 प्रोसेसर, 32GB RAM और दो 1TB SSD के साथ एक Dell M6800 चला रहा हूँ। यह जानवर उन बहुत से सर्वरों से बेहतर है जिन पर मैंने काम किया है।

अपने लैपटॉप पर VMware वर्कस्टेशन 11 का उपयोग करते हुए, मैंने 4 vCPU, 24GB RAM और 100GB स्टोरेज के साथ एक Windows Server 2012 R2 अतिथि बनाया। एक बार अतिथि बनने और पैच करने के बाद मैंने हाइपर-वी भूमिका जोड़ी और हाइपर-वी के तहत एक अतिथि का प्रावधान किया। नए मेहमान को Windows Server 2012 R2 के साथ 2 vCPU, 22GB RAM और 60GB स्टोरेज के साथ SQL Server 2014 RTM चलाने के साथ बनाया गया था।

मैंने परीक्षण के तीन सेट चलाए, प्रत्येक गतिशील स्मृति का उपयोग कर रहा था। प्रत्येक परीक्षण के लिए मैंने बफर पूल को भरने के लिए एडवेंचरवर्क्स2014 डेटाबेस के खिलाफ रेड गेट के SQL डेटा जेनरेटर का उपयोग किया। पहले टेस्ट के लिए मैंने स्टार्टअप रैम वैल्यू के लिए 512MB के साथ शुरुआत की थी क्योंकि यह विंडोज सर्वर 2012 R2 को शुरू करने के लिए मेमोरी की न्यूनतम मात्रा है और बफर पूल लगभग 8GB पर बढ़ना बंद कर देता है।

प्रत्येक परीक्षण के लिए मैं अपनी परीक्षण तालिका को छोटा कर दूंगा, अतिथि को बंद कर दूंगा, स्मृति सेटिंग्स को संशोधित करूंगा और अतिथि का बैक अप शुरू करूंगा। दूसरे परीक्षण के लिए मैंने स्टार्टअप रैम को 768एमबी तक बढ़ा दिया और बफर पूल का आकार केवल 12जीबी से अधिक हो गया।

तीसरे और अंतिम परीक्षण के लिए स्टार्टअप रैम को 1024MB तक बढ़ा दिया, डेटा जनरेटर चलाया और बफर पूल केवल 16GB से कम तक बढ़ने में सक्षम था।

इन मूल्यों पर थोड़ा गणित करने से पता चलता है कि बफर पूल स्टार्टअप रैम के 16 गुना से अधिक नहीं बढ़ सकता है। यह SQL सर्वर के लिए बहुत समस्याग्रस्त हो सकता है यदि स्टार्टअप RAM अधिकतम मेमोरी के आकार के 1/16 से कम है। आइए एक हाइपर-V अतिथि के बारे में सोचें जिसमें 64GB RAM के साथ SQL सर्वर चल रहा हो और स्टार्टअप RAM मान 1GB हो। हमने देखा है कि बफ़र पूल इस कॉन्फ़िगरेशन के साथ 16GB से अधिक का उपयोग करने में सक्षम नहीं होगा, लेकिन यदि हम स्टार्टअप RAM मान को 4096MB पर सेट करते हैं तो बफ़र पूल 16 गुना बढ़ाने में सक्षम होगा जिससे हम सभी 64GB का उपयोग कर सकेंगे।

एकमात्र संदर्भ जो मुझे इस बारे में मिल सकता है कि बफर पूल स्टार्टअप रैम मान के 16 गुना तक सीमित क्यों है, श्वेतपत्र में पृष्ठ 8 और 16 पर थे, एचवीडीएम के साथ SQL सर्वर चलाने के लिए सर्वोत्तम अभ्यास। यह दस्तावेज़ बताता है कि चूंकि स्टार्टअप समय पर बफर कैश मान की गणना की जाती है, यह एक स्थिर मान है और बढ़ता नहीं है। हालाँकि यदि SQL सर्वर यह पता लगाता है कि हॉट ऐड मेमोरी समर्थित है तो यह बफर पूल के लिए वर्चुअल एड्रेस स्पेस के लिए आरक्षित आकार को स्टार्टअप मेमोरी से 16 गुना बढ़ा देता है। यह दस्तावेज़ यह भी बताता है कि यह व्यवहार SQL Server 2008 R2 और इससे पहले को प्रभावित करता है, हालाँकि मेरा परीक्षण SQL Server 2014 के साथ Windows Server 2012 R2 पर आयोजित किया गया था, इसलिए मैं सर्वोत्तम प्रथाओं के दस्तावेज़ को अद्यतन करने के लिए Microsoft से संपर्क करूँगा।

चूंकि अधिकांश उत्पादन डीबीए वर्चुअल मशीनों का प्रावधान नहीं करते हैं या उस स्थान पर भारी काम नहीं करते हैं, और वर्चुअलाइजेशन इंजीनियर नवीनतम और महानतम SQL सर्वर तकनीक का अध्ययन नहीं कर रहे हैं, मैं समझ सकता हूं कि बफर पूल डायनेमिक मेमोरी को कैसे संभालता है, इस बारे में यह महत्वपूर्ण जानकारी बहुत कुछ अज्ञात है। लोगों का।

लेखों का अनुसरण करना भी भ्रामक हो सकता है। हाइपर-वी डायनेमिक मेमोरी कॉन्फ़िगरेशन गाइड लेख में, स्टार्टअप रैम का विवरण पढ़ता है:

इष्टतम स्मृति उपयोग किसके लिए, मेजबान या अतिथि? यदि वर्चुअलाइजेशन व्यवस्थापक इसे पढ़ रहा था, तो वे संभवतः यह निर्धारित करेंगे कि इसका मतलब ऑपरेटिंग सिस्टम को शुरू करने के लिए न्यूनतम मेमोरी है।

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

स्टोरेज एरेज़, स्टोरेज नेटवर्क, मल्टी-पाथिंग आदि के साथ एक सैन कैसे काम करता है, इसके बारे में मूल बातें जानने के साथ-साथ वर्चुअलाइजेशन के भीतर सीपीयू और स्टोरेज आवंटन के शेड्यूलिंग के साथ हाइपरवाइजर कैसे काम करता है, एक डीबीए बेहतर संवाद कर सकता है और समस्या होने पर समस्या निवारण कर सकता है। . इन वर्षों में मैंने SQL सर्वर के लिए मानक बनाने के लिए कई SAN और वर्चुअलाइजेशन व्यवस्थापकों के साथ सफलतापूर्वक काम किया है। ये मानक SQL सर्वर के लिए अद्वितीय हैं और आवश्यक रूप से वेब या एप्लिकेशन सर्वर पर लागू नहीं होते हैं।

SQL सर्वर के लिए सर्वोत्तम प्रथाओं को पूरी तरह से समझने के लिए DBA वास्तव में SAN और वर्चुअलाइजेशन व्यवस्थापकों पर भरोसा नहीं कर सकते हैं, चाहे वह कितना भी अच्छा क्यों न हो, इसलिए हमें अपने आप को सबसे अच्छा शिक्षित करने की आवश्यकता है कि उनकी विशेषज्ञता के क्षेत्र हमें कैसे प्रभावित कर सकते हैं।

अपने परीक्षण के दौरान मैंने पॉल रान्डल के ब्लॉग पोस्ट, व्यर्थ बफर पूल मेमोरी से प्रदर्शन के मुद्दों से एक क्वेरी का उपयोग किया, यह निर्धारित करने के लिए कि एडवेंचरवर्क्स2014 डेटाबेस कितना बफर पूल का उपयोग कर रहा था। मैंने नीचे कोड शामिल किया है:

SELECT
    (CASE WHEN ([database_id] = 32767)
        THEN N'Resource Database'
        ELSE DB_NAME ([database_id]) END) AS [DatabaseName],
    COUNT (*) * 8 / 1024 AS [MBUsed],
    SUM (CAST ([free_space_in_bytes] AS BIGINT)) / (1024 * 1024) AS [MBEmpty]
FROM sys.dm_os_buffer_descriptors
GROUP BY [database_id];

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