64GB + अधिक उपलब्ध के साथ SQL सर्वर की "टोटल सर्वर मेमोरी" की खपत महीनों तक रुक जाती है

Question

मैं एक अजीब मुद्दे में भाग लिया है, जहां SQL सर्वर 2016 मानक संस्करण 64-बिट के लिए कुल स्मृति के ठीक आधे पर ही छाया हुआ है लगता है (64 जीबी 128 जीबी)।

का आउटपुट @@VERSIONहै:

Microsoft SQL Server 2016 (SP1-CU7-GDR) (KB4057119) - 13.0.4466.4 (X64) 22 दिसंबर 2017 11:25:00 कॉपीराइट (c) Microsoft कॉर्पोरेशन मानक संस्करण (64-बिट) Windows Server 2012 R2 डाटेंटर 6.3 पर ( बिल्ड 9600:) (हाइपरविजर)

का आउटपुट sys.dm_os_process_memoryहै:

जब मैं क्वेरी sys.dm_os_performance_counters, मुझे लगता है कि Target Server Memory (KB)में है 131072000और Total Server Memory (KB)सिर्फ इतना है कि के आधे के तहत कम से कम है 65308016। अधिकांश परिदृश्यों में, मैं इसे सामान्य व्यवहार समझूंगा क्योंकि SQL सर्वर ने अभी तक यह निर्धारित नहीं किया है कि इसे अपने लिए कोई और मेमोरी आवंटित करने की आवश्यकता है।

हालाँकि, यह 2 महीने से अधिक समय के लिए ~ 64GB पर "अटक" गया है। इस समय-सीमा के दौरान हमने कुछ डेटाबेस पर स्मृति-गहन संचालन का एक महत्वपूर्ण प्रदर्शन किया है, और उदाहरण के लिए करीब 40 और डेटाबेस को जोड़ा है। हम कुल 292 डेटाबेस पर बैठे हैं, प्रत्येक में पूर्व-आवंटित डेटा फ़ाइलों के साथ 4GB 256MB ऑटोग्रॉथ रेट और 2GB लॉग फ़ाइलों के साथ 128MB ऑटोग्रॉथ रेट है। मैं रात 12:00 बजे एक बार पूर्ण बैकअप करता हूं, और हर 15 मिनट के अंतराल पर 8:00 बजे के माध्यम से शुक्रवार से 6:00 बजे से शुरू होकर सोमवार को लॉग इन बैकअप बैकअप शुरू करता हूं। ये डेटाबेस अपने संपूर्ण थ्रूपुट पर अपेक्षाकृत कम हैं, लेकिन मुझे संदेह है कि कुछ ऐसा हो रहा है, जिसे देखते हुए SQL सर्वर ने इस ओर ध्यान नहीं दिया हैTarget Server Memory स्वाभाविक रूप से नए डेटाबेस परिवर्धन के माध्यम से, सामान्य क्वेरी निष्पादन, साथ ही स्मृति-गहन ईटीएल पाइपलाइनों को चलाया गया है।

SQL सर्वर का उदाहरण स्वयं एक वर्चुअलाइज्ड (VMware) विंडोज सर्वर 2012R2 सर्वर है जिसमें 12 CPU, 144GB मेमोरी (128GB to SQL Server, 16GB आरक्षित विंडोज के लिए), और 4 कुल वर्चुअल डिस्क हैं जो 15K SAS ड्राइव के साथ एक vop ऊपर बैठते हैं। । विंडोज 64GB C पर स्वाभाविक रूप से बैठता है: 32GB की पेज फाइल के साथ डिस्क। डेटा फाइलें 2TB D: डिस्क पर बैठती हैं, लॉग फाइलें 2TB L: डिस्क के ऊपर बैठती हैं, और tempdb 256GB T: डिस्क पर 8x16GB फाइलों के साथ बिना ऑटोग्रॉथ के बैठता है।

मैंने सत्यापित किया है कि SQL सर्वर पर सर्वर के अलावा कोई और इंस्टेंस नहीं चल रहा है MSSQLSERVER।

यह सर्वर पूरी तरह से केवल SQL सर्वर उदाहरण के लिए समर्पित है, इसलिए हमारे पास इस पर चलने वाले अन्य एप्लिकेशन या सेवाएं नहीं हैं जो मेमोरी का उपभोग कर सकते हैं।

मैं विश्लेषण के लिए RedGate SQL मॉनिटर का उपयोग करता हूं, और नीचे पिछले 18 दिनों का इतिहास है Total Server Memory। जैसा कि आप देख सकते हैं, स्मृति उपयोग अप्रैल की शुरुआत में ~ 300 एमबी के एकल अपटच से पूरी तरह से स्थिर रहा है।

इसका कारण क्या हो सकता है? यह जानने के लिए कि SQL सर्वर इसके लिए आवंटित अतिरिक्त 64GB + मेमोरी का उपयोग क्यों नहीं करना चाहता है, यह देखने के लिए मैं क्या कर सकता हूं?

रनिंग का आउटपुट sp_Blitz:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

प्राथमिकता 50: प्रदर्शन :

• CPU शेड्यूलर ऑफ़लाइन - कुछ CPU कोर एफिलिएंट मास्किंग या लाइसेंसिंग समस्याओं के कारण SQL सर्वर तक पहुँच योग्य नहीं हैं।

• मेमोरी नोड ऑफ़लाइन - आत्मीयता मास्किंग या लाइसेंसिंग समस्याओं के कारण, कुछ मेमोरी उपलब्ध नहीं हो सकती हैं।

प्राथमिकता 50: विश्वसनीयता :

• दूरस्थ DAC अक्षम - समर्पित व्यवस्थापक कनेक्शन (DAC) के लिए दूरस्थ पहुँच सक्षम नहीं है। SQL सर्वर अनुत्तरदायी होने पर DAC दूरस्थ समस्या निवारण को बहुत आसान बना सकता है।

प्राथमिकता १००: प्रदर्शन :

• एक प्रश्न के लिए कई योजनाएं - योजना कैश में एक ही प्रश्न के लिए 300 योजनाएं मौजूद हैं - जिसका अर्थ है कि हमारे पास संभवतः मानकीकरण मुद्दे हैं।

• सर्वर ट्रिगर सक्षम

  • सर्वर ट्रिगर [RG_SQLLIIIouse_DDLTrigger] सक्षम है। सुनिश्चित करें कि आप समझते हैं कि ट्रिगर क्या कर रहा है - यह कम काम करता है, बेहतर है।

  • सर्वर ट्रिगर [SSMSRemoteBlock] सक्षम है। सुनिश्चित करें कि आप समझते हैं कि ट्रिगर क्या कर रहा है - यह कम काम करता है, बेहतर है।

प्राथमिकता 150: प्रदर्शन :

• जुड़ने के लिए मजबूर करने वाले प्रश्न - पुनः आरंभ के बाद से जुड़ने के 1480 उदाहरण दर्ज किए गए हैं। इसका मतलब यह है कि क्वेरीज़ SQL सर्वर ऑप्टिमाइज़र के आसपास हैं, और अगर उन्हें नहीं पता कि वे क्या कर रहे हैं, तो इससे अच्छे से अधिक नुकसान हो सकता है। यह भी समझा सकता है कि डीबीए ट्यूनिंग प्रयास क्यों काम नहीं कर रहे हैं।

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

प्राथमिकता 170: फ़ाइल कॉन्फ़िगरेशन :

• सी ड्राइव पर सिस्टम डेटाबेस

  • मास्टर - मास्टर डेटाबेस में सी ड्राइव पर एक फ़ाइल है। सिस्टम ड्राइव को C ड्राइव पर डालने से सर्वर के दुर्घटनाग्रस्त होने का जोखिम अंतरिक्ष से बाहर चलने पर होता है।

  • मॉडल - मॉडल डेटाबेस में सी ड्राइव पर एक फ़ाइल है। सिस्टम ड्राइव को C ड्राइव पर डालने से सर्वर के दुर्घटनाग्रस्त होने का जोखिम अंतरिक्ष से बाहर चलने पर होता है।

  • msdb - msdb डेटाबेस में C ड्राइव पर एक फाइल है। सिस्टम ड्राइव को C ड्राइव पर डालने से सर्वर के दुर्घटनाग्रस्त होने का जोखिम अंतरिक्ष से बाहर चलने पर होता है।

प्राथमिकता 200: सूचनात्मक :

• एजेंट नौकरियां एक साथ शुरू - एकाधिक SQL सर्वर एजेंट नौकरियों को एक साथ शुरू करने के लिए कॉन्फ़िगर किया गया है। विस्तृत कार्यक्रम सूची के लिए, URL में क्वेरी देखें।

• मास्टर डेटाबेस मास्टर में टेबल्स - मास्टर डेटाबेस में कमांडलॉग टेबल को जुलाई 30, 2017 5:22 PM पर अंतिम उपयोगकर्ताओं द्वारा बनाया गया था। आपदा की स्थिति में मास्टर डेटाबेस में टेबल को बहाल नहीं किया जा सकता है।

• ट्रेसफ्लैग ऑन

  • विश्व स्तर पर ट्रेस ध्वज 1118 सक्षम है।

  • वैश्विक स्तर पर ट्रेस ध्वज 1222 सक्षम है।

  • वैश्विक स्तर पर ट्रेस ध्वज 2371 सक्षम है।

प्राथमिकता 200: गैर-डिफ़ॉल्ट सर्वर कॉन्फ़िगरेशन :

• एजेंट XP - यह sp_configure विकल्प बदल दिया गया है। इसका डिफ़ॉल्ट मान 0 है और इसे 1 पर सेट किया गया है।

• बैकअप चेकसम डिफ़ॉल्ट - यह sp_configure विकल्प बदल दिया गया है। इसका डिफ़ॉल्ट मान 0 है और इसे 1 पर सेट किया गया है।

• बैकअप संपीड़न डिफ़ॉल्ट - यह sp_configure विकल्प बदल दिया गया है। इसका डिफ़ॉल्ट मान 0 है और इसे 1 पर सेट किया गया है।

• समानता के लिए लागत सीमा - इस sp_configure विकल्प को बदल दिया गया है। इसका डिफ़ॉल्ट मान 5 है और इसे 48 पर सेट किया गया है।

• समानता की अधिकतम डिग्री - इस sp_configure विकल्प को बदल दिया गया है। इसका डिफ़ॉल्ट मान 0 है और इसे 12 पर सेट किया गया है।

• अधिकतम सर्वर मेमोरी (MB) - यह sp_configure विकल्प बदल दिया गया है। इसका डिफ़ॉल्ट मान 2147483647 है और इसे 128000 पर सेट किया गया है।

• तदर्थ कार्यभार के लिए अनुकूलन - यह sp_configure विकल्प बदल दिया गया है। इसका डिफ़ॉल्ट मान 0 है और इसे 1 पर सेट किया गया है।

• उन्नत विकल्प दिखाएं - इस sp_configure विकल्प को बदल दिया गया है। इसका डिफ़ॉल्ट मान 0 है और इसे 1 पर सेट किया गया है।

• xp_cmdshell - इस sp_configure विकल्प को बदल दिया गया है। इसका डिफ़ॉल्ट मान 0 है और इसे 1 पर सेट किया गया है।

प्राथमिकता 200: विश्वसनीयता :

• मास्टर में विस्तारित प्रक्रियाएँ

• मास्टर - मास्टर डेटाबेस में [sqbdata] विस्तारित संग्रहीत कार्यविधि है। सीएलआर उपयोग में हो सकता है, और मास्टर डेटाबेस को अब आपके बैकअप / रिकवरी प्लानिंग का हिस्सा होना चाहिए।

  • मास्टर - मास्टर डेटाबेस में [sqbdir] विस्तारित संग्रहीत कार्यविधि है। सीएलआर उपयोग में हो सकता है, और मास्टर डेटाबेस को अब आपके बैकअप / रिकवरी प्लानिंग का हिस्सा होना चाहिए।

  • मास्टर - [sqbmemory] विस्तारित संग्रहीत कार्यविधि मास्टर डेटाबेस में है। सीएलआर उपयोग में हो सकता है, और मास्टर डेटाबेस को अब आपके बैकअप / रिकवरी प्लानिंग का हिस्सा होना चाहिए।

  • मास्टर - मास्टर डेटाबेस में [sqbstatus] विस्तारित संग्रहीत कार्यविधि है। सीएलआर उपयोग में हो सकता है, और मास्टर डेटाबेस को अब आपके बैकअप / रिकवरी प्लानिंग का हिस्सा होना चाहिए।

  • मास्टर - मास्टर डेटाबेस में [sqbtest] विस्तारित संग्रहीत कार्यविधि है। सीएलआर उपयोग में हो सकता है, और मास्टर डेटाबेस को अब आपके बैकअप / रिकवरी प्लानिंग का हिस्सा होना चाहिए।

  • मास्टर - [sqbtestcancel] विस्तारित संग्रहीत कार्यविधि मास्टर डेटाबेस में है। सीएलआर उपयोग में हो सकता है, और मास्टर डेटाबेस को अब आपके बैकअप / रिकवरी प्लानिंग का हिस्सा होना चाहिए।

  • मास्टर - [sqbteststatus] विस्तारित संग्रहीत कार्यविधि मास्टर डेटाबेस में है। सीएलआर उपयोग में हो सकता है, और मास्टर डेटाबेस को अब आपके बैकअप / रिकवरी प्लानिंग का हिस्सा होना चाहिए।

  • मास्टर - मास्टर डेटाबेस में [sqbutility] विस्तारित संग्रहीत कार्यविधि है। सीएलआर उपयोग में हो सकता है, और मास्टर डेटाबेस को अब आपके बैकअप / रिकवरी प्लानिंग का हिस्सा होना चाहिए।

  • मास्टर - मास्टर डेटाबेस में [sqlbackup] विस्तारित संग्रहीत कार्यविधि है। सीएलआर उपयोग में हो सकता है, और मास्टर डेटाबेस को अब आपके बैकअप / रिकवरी प्लानिंग का हिस्सा होना चाहिए।

प्राथमिकता 210: गैर-डिफ़ॉल्ट डेटाबेस कॉन्फ़िगरेशन :

• कमिटेड स्नैपशॉट अलगाव पढ़ें - यह डेटाबेस सेटिंग डिफ़ॉल्ट नहीं है।

  • Redgate

  • RedGateMonitor

• स्नैपशॉट अलगाव सक्षम - यह डेटाबेस सेटिंग डिफ़ॉल्ट नहीं है।

  • Redgate

  • RedGateMonitor

प्राथमिकता 240: प्रतीक्षा आँकड़े :

• 1 - SOS_SCHEDULER_YIELD - 1770.8 घंटे वेट, 115.9 मिनट औसत प्रतीक्षा समय प्रति घंटे, 100.0% सिग्नल प्रतीक्षा, 1419212079 प्रतीक्षा कार्य, 4.5 एमएस औसत प्रतीक्षा समय।

प्राथमिकता 250: सूचनात्मक :

• SQL सर्वर NT सेवा खाते के अंतर्गत चल रहा है - मैं NT सेवा \ MSSQLSERVER के रूप में चल रहा हूं। काश मेरे पास इसके बजाय एक सक्रिय निर्देशिका सेवा खाता होता।

प्राथमिकता 250: सर्वर जानकारी :

• डिफ़ॉल्ट ट्रेस सामग्री - डिफ़ॉल्ट ट्रेस 14 अप्रैल 2018 11:21 अपराह्न और 16 अप्रैल 2018 11:13 पूर्वाह्न के बीच 36 घंटे का डेटा रखता है। डिफ़ॉल्ट ट्रेस फ़ाइल में स्थित हैं: C: \ Program Files \ Microsoft SQL Server \ MSSQL13.MSSQLSERVER \ MSSQL \ लॉग

• ड्राइव सी स्पेस - 196816.00MB सी ड्राइव पर मुफ्त

• ड्राइव डी स्पेस - ई ड्राइव पर 894823.00MB मुफ्त

• ड्राइव L स्पेस - F ड्राइव पर 1361367.00MB मुफ्त

• ड्राइव टी स्पेस - 114441.00MB जी ड्राइव पर मुफ्त

• हार्डवेयर - लॉजिकल प्रोसेसर: 12. भौतिक मेमोरी: 144 जीबी।

• हार्डवेयर - NUMA विन्यास

  • नोड: 0 राज्य: ऑनलाइन ऑनलाइन अनुसूचक: 4 ऑफ़लाइन अनुसूचक: 2 प्रोसेसर समूह: 0 मेमोरी नोड: 0 मेमोरी वीएएस आरक्षित जीबी: 186

  • नोड: 1 राज्य: ऑफ़लाइन ऑनलाइन अनुसूचक: 0 ऑफ़लाइन अनुसूचक: 6 प्रोसेसर समूह: 0 मेमोरी नोड: 0 मेमोरी वीएएस आरक्षित जीबी: 186

• झटपट फ़ाइल इनिशियलाइज़ेशन सक्षम - सेवा खाते में प्रदर्शन मात्रा रखरखाव कार्य की अनुमति है।

• पावर प्लान - आपके सर्वर में 2.60GHz CPU हैं, और संतुलित पावर मोड में है - उह ... आप चाहते हैं कि आपका CPU पूरी गति से चले, है ना?

• सर्वर लास्ट रिस्टार्ट - Mar 9 2018 7:27 AM

• सर्वर का नाम - [फिर से तैयार]

• सेवाएं

  • सेवा: SQL सर्वर (MSSQLSERVER) सेवा खाता NT Service \ MSSQLSERVER के अंतर्गत चलता है। अंतिम स्टार्टअप का समय: मार्च 9 2018 7:27 पूर्वाह्न। स्टार्टअप प्रकार: स्वचालित, वर्तमान में चल रहा है।

  • सेवा: SQL सर्वर एजेंट (MSSQLSERVER) सेवा खाता LocalSystem के अंतर्गत चलता है। अंतिम स्टार्टअप समय: नहीं दिखाया गया है। स्टार्टअप प्रकार: स्वचालित, वर्तमान में चल रहा है।

• SQL सर्वर अंतिम पुनः आरंभ - मार्च 9 2018 6:27 पूर्वाह्न

• SQL सर्वर सेवा - संस्करण: 13.0.4466.4। पैच स्तर: SP1। संचयी अद्यतन: CU7। संस्करण: मानक संस्करण (64-बिट)। उपलब्धता समूह सक्षम: 0. उपलब्धता समूह प्रबंधक स्थिति: 2

• वर्चुअल सर्वर - प्रकार: (HYPERVISOR)

• विंडोज संस्करण - आप विंडोज का एक बहुत ही आधुनिक संस्करण चला रहे हैं: सर्वर 2012R2 युग, संस्करण 6.3

प्राथमिकता 254: रूडेट :

• कैप्टन का लॉग: कुछ और कुछ को छोड़ दें ...

Comments

यह उत्तर SQL सर्वर को सभी मेमोरी का उपयोग करने में

— SqlWorldWide

की पूरी उत्पादन जोड़ें select @@versionऔर select * from sys.dm_os_process_memoryप्रश्न में। क्या आपने Total Server Memory (KB)परफॉमन काउंटर से मूल्य देखने की कोशिश की ?

— शंकी

@SqlWorldWide मैं पहले से ही उस प्रश्न में है, और दी गई सलाह अनिवार्य रूप से है जो मैंने अपने मुख्य विषय में प्रदान की है। मैं अपने दिए गए परिदृश्य के लिए उस पोस्ट के माध्यम से एक समाधान खोजने में असमर्थ था।

— पिकोडेग्लो

@Shanky मैंने अनुरोधित आउटपुट जोड़े हैं। Total Server Memory (KB)से प्रदान किया गया था sys.dm_os_performance_counters।

— पिकोडेग्लो

Answer 1

मुझे यकीन है कि आपने वर्चुअल सीपीयू को इस तरह से कॉन्फ़िगर किया है कि कुछ सीपीयू नोड्स और / या मेमोरी नोड्स ऑफ़लाइन हैं।

Sp_Blitz डाउनलोड करें (अस्वीकरण: मैं उस मुक्त स्रोत स्क्रिप्ट के लेखकों में से एक हूं) और इसे चलाएं:

sp_Blitz @CheckServerInfo = 1;

सीपीयू और / या मेमोरी नोड्स ऑफ़लाइन होने के बारे में चेतावनी के लिए देखें। SQL सर्वर मानक संस्करण केवल पहले 4 CPU सॉकेट्स को देखता है, और आपने VM को 6 दोहरे कोर सीपीयू जैसे कुछ के रूप में कॉन्फ़िगर किया होगा। यह एंटरप्राइज एडिशन के 20-कोर-लिमिट्स को याद रखने की मात्रा से मिलता- जुलता है ।

यदि आप यहाँ sp_Blitz के आउटपुट को साझा करना चाहते हैं, तो आप इसे मार्कडाउन के आउटपुट में इस तरह चला सकते हैं, जिसे आप अपने प्रश्न में कॉपी / पेस्ट कर सकते हैं:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

अपडेट 2018/04/16 - पुष्टि की गई। आपने sp_Blitz आउटपुट (इसके लिए धन्यवाद!) को संलग्न किया और यह वास्तव में दिखाता है कि आपके पास CPU और मेमोरी नोड्स ऑफ़लाइन हैं। जिसने भी VM का निर्माण किया है उसने 12 सिंगल-कोर सीपीयू के रूप में कॉन्फ़िगर किया है, इसलिए SQL सर्वर मानक संस्करण केवल पहले 4 सॉकेट (कोर), और उनसे जुड़ी मेमोरी को देख रहा है।

इसे ठीक करने के लिए, VM को बंद करें, इसे 2-सॉकेट, 6-कोर VM के रूप में कॉन्फ़िगर करें, और फिर SQL सर्वर मानक संस्करण सभी कोर और मेमोरी को देखेगा। इससे आपका SOS_SCHEDULER_YIELD इंतजार भी कम हो जाएगा - अभी, आपका SQL Server पहले 4 कोर को हथौड़े से मार रहा है, लेकिन ऐसा है। इस फिक्स के बाद, यह सभी 12 कोर पर काम करने में सक्षम होगा।

Comments

अलग-अलग पृष्ठ , एक ही वीडियो मुझे लगता है

— मैरियन

@BrentOzar मैंने इस कॉन्फ़िगरेशन परिवर्तन के परिणामों से पहले / बाद में यहाँ साझा किया है । मैं सहायता की सराहना करता हूं - आपने हमें बहुत सिरदर्द से बचाया है!

— पिकोडेगलो

@PicoDeGallo आपका स्वागत है! हां, यही कारण है कि मैंने इसे sp_Blitz में डाल दिया है - हम उन कई प्रकार की सामान्य समस्याओं का पता लगाते हैं, और वे बहुत आसान हैं कि केवल मुफ्त स्वास्थ्य जांच की खरीद को चलाकर। अपने सालसा से प्यार करो, वैसे। (रुको, यह गलत लग रहा था।)

— ब्रेंट ओजर

Answer 2

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

उन लोगों के लिए जो VMware vSphere 6.5 का उपयोग कर सकते हैं, ब्रेंट द्वारा वर्णित कार्रवाई आइटम को पूरा करने के लिए संक्षिप्त चरण निम्नानुसार हैं।

1. अपने VMware क्लस्टर के लिए vSphere वेब क्लाइंट में लॉगिन करें, और SQL सर्वर को होस्ट करने वाली वर्चुअल मशीन पर ब्राउज़ करें। CPU और मेमोरी कॉन्फ़िगरेशन को समायोजित करने के लिए आपका VM ऑफ़लाइन होना चाहिए।

2. प्राथमिक फलक के भीतर, ऊपर जाएं Configure > VM hardware, Editऊपरी दाएं कोने में स्थित बटन पर क्लिक करें। आपके पास एक संदर्भ मेनू खुल जाएगा Edit Settings। संदर्भ के लिए, नीचे की छवि गलत कॉन्फ़िगरेशन है। ध्यान दें कि मैंने Cores per Socketनिर्धारित किया है 1। SQL सर्वर मानक संस्करण की सीमाओं को देखते हुए, यह एक बुरा कॉन्फ़िगरेशन है।

   

3. Cores per Socketमूल्य को समायोजित करने के रूप में फिक्स उतना ही सरल है । हमारे मामले में, हम इसे सेट करते हैं 6ताकि हमारे पास हो 2 Sockets। यह SQL सर्वर को सभी 12 प्रोसेसर का उपयोग करने की अनुमति देता है।

   

एक महत्वपूर्ण सूचना: Do जहां या तो करने के लिए मान सेट नहीं Number of Coresया Socketsएक विषम संख्या होगी। NUMA को संतुलन पसंद है, और अंगूठे के नियम से, 2. द्वारा विभाज्य होने की आवश्यकता है। उदाहरण के लिए, 4 कोर से 3 सॉकेट का कॉन्फ़िगरेशन असंतुलित होगा। वास्तव में, यदि आप sp_Blitzइस प्रकार के कॉन्फ़िगरेशन के साथ चलना चाहते हैं, तो यह इस बारे में चेतावनी को टॉस करेगा।

VMware vSphere (पीडीएफ चेतावनी) पर Microsoft SQL सर्वर को आर्किटेक्चर में धारा 3.3 इस पर विस्तार से बताती है। श्वेतपत्र में बताई गई प्रथाएँ SQL सर्वर के अधिकांश ऑन-प्रिमाइसेस वर्चुअलाइजेशन पर लागू होती हैं।

ब्रेंट की पोस्ट के बाद मैंने अपने शोध के माध्यम से कुछ और संसाधन संकलित किए हैं:

• बड़े डेटाबेस का वर्चुअलाइजेशन - VMware CPU क्षमता योजना

• वर्चुअल मशीन vCPU और vNUMA राइटिंग - अंगूठे के नियम

• VSphere 6.5 में वर्चुअल NUMA टोपोलॉजी से सॉकेट प्रति सॉकेट की गिरावट

मैं पिछले 24 घंटों में RedGate SQL मॉनिटर से कैप्चर करूँगा। ध्यान देने का प्राथमिक बिंदु सीपीयू उपयोग और वेट की संख्या है - कल हमारे चरम समय के दौरान, हम भारी सीपीयू उपयोग और प्रतीक्षा सामग्री का अनुभव कर रहे थे। इस साधारण सुधार के बाद, हमने अपने प्रदर्शन में दस गुना सुधार किया है। यहां तक ​​कि हमारी डिस्क I / O में भी काफी कमी आई है। यह एक प्रतीत होता है आसानी से अनदेखी की गई सेटिंग है जो परिमाण के क्रम से आभासी प्रदर्शन में सुधार कर सकती है। कम से कम, यह हमारे इंजीनियरों और एक पूर्ण डीओएच पल को नजरअंदाज कर दिया गया था ।

Comments

+1: यह वास्तव में ब्रेंट ओजर के जवाब को पूरा करता है।

— शांकी

Answer 3

इसके अलावा, MSDN के अनुसार , SQL सर्वर मानक 64GB RAM तक सीमित है। हमने डेटाबेस को कई उदाहरणों में विभाजित करके इसे हल किया है, लेकिन आपकी स्थिति इसके लिए अनुमति नहीं दे सकती है।

हम्म 2016 में सीमा के रूप में 128 जीबी लगती है, लेकिन उदाहरण-विभाजन अभी भी एक विकल्प हो सकता है।