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


10

मेरे पास SQL ​​Server 2014 है जिसमें अधिकतम मेमोरी 6GB (भौतिक मेमोरी 8GB) है।

लक्ष्य सर्वर मेमोरी कभी कभी 6GB है और फिर वापस करने के लिए चला जाता है कुल सर्वर स्मृति (लगभग 5.3GB, 6GB कभी नहीं पहुंचता है)। मैंने SQL सर्वर द्वारा उपयोग की गई मेमोरी की जांच करने के लिए sysinos_os_sys_info में प्रतिबद्ध_ kb का उपयोग किया।

जब मैं sysinos_os_buffer_descriptors की निगरानी करता हूं , तो देखता हूं कि पृष्ठ कैश से हटा दिए गए हैं - लेकिन अभी भी 700MB मेमोरी शेष है। यदि किसी मेमोरी की आवश्यकता नहीं है, तो आप इस तथ्य को कैसे समझाएंगे कि पेज कैश से हटा दिए गए हैं? मुझे उम्मीद है कि SQL सर्वर केवल पृष्ठों को हटाता है जब उसे मेमोरी की आवश्यकता होती है।

इस सर्वर पर टैक्लोकेटेड टेम्प टेबल नहीं हैं। मेरा PLE 3632 है। प्रक्रिया कैश 2182 MB है।

मैं उम्मीद करूंगा कि पृष्ठ केवल तब छूट जाएंगे जब कोई मेमोरी नहीं बची है, लेकिन मेरे पास 700 एमबी मुफ्त है या क्या मैं इसे गलत समझ रहा हूं?

क्या कोई कृपया इस व्यवहार को समझाने की कोशिश कर सकता है?

SQL सर्वर डिस्क से भी पढ़ रहा है, इसलिए मुझे लगता है कि मैं यह निष्कर्ष निकाल सकता हूं कि आवश्यक सभी पृष्ठ स्मृति में नहीं हैं।

मैंने कुछ और शोध किया और मैंने डिस्क से मेमोरी में पृष्ठों की एक बड़ी मात्रा को पढ़ा और पढ़े जाने के दौरान टास्कमैनगर में कुछ देखा।

  • उपयोग में स्मृति 7.0GB -> 7.2GB -> 7.0GB -> 7.2GB -> से चली गई ...
  • Sqlservr.exe 5.3GB -> 5.5GB -> 5.3GB -> 5.5GB -> से चला गया ...

यह वैसा ही है जैसे Windows sqlservr.exe को 6GB तक बढ़ने नहीं देता ।

मैंने Shanky द्वारा प्रदान की गई क्वेरी को चलाया:

select
(physical_memory_in_use_kb/1024) Physical_Memory_usedby_Sqlserver_MB,
(locked_page_allocations_kb/1024 )Locked_pages_used_Sqlserver_MB,
(Virtual_address_committed_kb/1024 )Total_Memory_in_MB,--RAM+ Pagefile
process_physical_memory_low,
process_virtual_memory_low
from sys. dm_os_process_memory

इसने निम्न परिणाम दिया:

Physical_Memory_usedby_Sqlserver_MB: 5247
Locked_pages_used_Sqlserver_MB: 0
Total_Memory_in_MB: 5625
process_physical_memory_low: 0
process_virtual_memory_low: 0

मुझे समझ में नहीं आता कि Total_Memory_in_MB 6144 (अधिकतम मेमोरी) के बराबर क्यों नहीं है?

में sys.dm_os_ring_buffers मैंने पाया RESOURCE_MEMPHYSICAL_LOWहै, इसलिए मुझे लगता है कि विंडोज की मेमोरी कम किया गया था और एसक्यूएल सर्वर कुछ लौट जाना चाहिए। लेकिन लगभग 1GB मेमोरी उपलब्ध है => विंडोज यह क्यों कह रहा है कि यह मेमोरी पर कम चल रहा है?

<Record id="13861" type="RING_BUFFER_RESOURCE_MONITOR" time="20635079241">   
   <ResourceMonitor>
        <Notification>RESOURCE_MEMPHYSICAL_LOW</Notification>
        <IndicatorsProcess>0</IndicatorsProcess>
        <IndicatorsSystem>2</IndicatorsSystem>
        <NodeId>0</NodeId>
        <Effect type="APPLY_LOWPM" state="EFFECT_OFF" reversed="0">0</Effect>
        <Effect type="APPLY_HIGHPM" state="EFFECT_IGNORE" reversed="0">85827186</Effect>
        <Effect type="REVERT_HIGHPM" state="EFFECT_OFF" reversed="0">0</Effect>   
   </ResourceMonitor>   
   <MemoryNode id="0">
        <TargetMemory>6050080</TargetMemory>
        <ReservedMemory>67208656</ReservedMemory>
        <CommittedMemory>5423548</CommittedMemory>
        <SharedMemory>0</SharedMemory>
        <AWEMemory>0</AWEMemory>
        <PagesMemory>4975656</PagesMemory>   
   </MemoryNode>   
   <MemoryRecord>
        <MemoryUtilization>100</MemoryUtilization>
        <TotalPhysicalMemory>8387608</TotalPhysicalMemory>
        <AvailablePhysicalMemory>1048452</AvailablePhysicalMemory>
        <TotalPageFile>11142348</TotalPageFile>
        <AvailablePageFile>2887916</AvailablePageFile>
        <TotalVirtualAddressSpace>137438953344</TotalVirtualAddressSpace>
        <AvailableVirtualAddressSpace>137371168056</AvailableVirtualAddressSpace>
        <AvailableExtendedVirtualAddressSpace>0</AvailableExtendedVirtualAddressSpace
   </MemoryRecord> 
</Record>

अपडेट
कुछ अधिक शोध के बाद क्यों हमेशा 1 जीबी मेमोरी उपलब्ध थी, मुझे लगता है कि मुझे कुछ मिला।
क्या यह संभव है कि SQL सर्वर केवल मुफ्त मेमोरी आवंटित कर सकता है और उपलब्ध मेमोरी को अनदेखा किया जाता है? प्रोसेस एक्सप्लोरर (सिसिन्टर्नल्स) चलाते समय मैंने देखा कि फ्री मेमोरी 0 थी।

जवाबों:


3

मुझे यह कहने के लिए शुरू करना चाहिए कि आपने अधिकतम सर्वर मेमोरी को 6 जीबी पर सेट किया है और कुल मेमोरी 8 जीबी है, इसलिए आपके पास ओएस के लिए सिर्फ 2 जीबी बचा है, जो कई मामलों में, भले ही विंडोज मशीन पर SQL सर्वर के अलावा कुछ भी स्थापित न हो। , OS को बहुत कम मेमोरी प्रदान की जाती है। ठीक से काम करने के लिए, एंटीवायरस स्थापित सिस्टम पर, ओएस को कम से कम 4 जीबी दिया जाना चाहिए। मैं सीधे ओएस के लिए 2 जीबी छोड़ देता हूं और एवी के लिए 1.5 जी।

टारगेट सर्वर मेमोरी कभी-कभी 6GB होती है और फिर टोटल सर्वर मेमोरी (लगभग 5.3GB, कभी 6GB तक नहीं पहुँचती) पर वापस आ जाती है।

लक्ष्य सर्वर मेमोरी यह दर्शाता है कि आदर्श मामले में ठीक से कार्य करने के लिए SQL सर्वर द्वारा कितनी मेमोरी की आवश्यकता है। लक्ष्य सर्वर मेमोरी 6 GB होने का प्रयास कर रही है क्योंकि आपने अधिकतम सर्वर मेमोरी सेट कर दी है मान 6 जीबी । यह उन सभी मेमोरी का उपभोग करने की कोशिश कर रहा है जिसकी अनुमति है।

कुल सर्वर मेमोरी वह है जो SQL सर्वर वास्तव में अभी उपभोग करने में सक्षम है। यह मेमोरी के लिए प्रतिबद्ध है और भौतिक रैम द्वारा समर्थित है। यह आपके मामले में 5.5 जीबी अधिकतम है।

एसक्यूएल सर्वर अपनी मेमोरी खपत को बढ़ाने की कोशिश कर रहा है, लेकिन 5.3 या 5.5 जीबी तक पहुंचने के बाद, ओएस एसक्यूएल सर्वर को अपनी मेमोरी की खपत को आगे नहीं बढ़ाने के लिए कह रहा है और वास्तव में कम मेमोरी नोटिफिकेशन को झंडी दिखा सकता है। यह इसलिए हो रहा है क्योंकि OS कम मेमोरी का सामना कर रहा है जैसा कि पहले ही ऊपर कहा जा चुका है। SQLOS जवाब देता है अगर विंडोज ओएस अपने कैश को अपनी खपत को कम करने के लिए कहकर स्मृति दबाव का सामना करता है। आप रिंग बफ़र को यह जांचने के लिए क्वेरी कर सकते हैं कि क्या कम स्मृति सूचना संकेतित थी। मुझे DMV को जोड़ना होगा sysinos_os_ring_buffer अनिर्धारित लेकिन सुरक्षित है।

मैं देखता हूं कि पेज कैश से हटा दिए गए हैं - लेकिन अभी भी 700MB मेमोरी बाकी है। यदि किसी मेमोरी की आवश्यकता नहीं है, तो आप इस तथ्य को कैसे समझाएंगे कि पेज कैश से हटा दिए गए हैं? मुझे उम्मीद है कि SQL सर्वर केवल पृष्ठों को हटाता है जब उसे मेमोरी की आवश्यकता होती है।

आप देख रहे हैं मुक्त स्मृति के लिए, मैं होता सुझाव नहीं आप DMV को देखने के लिए sys.dm_os_buffer_descriptorsओएस काउंटर Available Mbytes आप भौतिक स्मृति की मात्रा, बाइट में, कंप्यूटर पर चल रहे प्रक्रियाओं के लिए उपलब्ध बता देंगे। मेरा सुझाव है कि आप यह भी देखें कि एक समझदार बफर पूल आकार का मूल्यांकन करने के लिए एक निर्धारक विधि क्या है? और यह भी पढ़ें कि क्या SQL सर्वर को अधिक RAM की आवश्यकता होती है ताकि यह पता लगाया जा सके कि SQL सर्वर को कितनी जरूरत है और यदि SQL सर्वर मेमोरी प्रेशर का सामना कर रहा है। आपने जो उल्लेख किया है, यदि आप सुनिश्चित हैं कि पृष्ठ बफर पूल से हटाए जा रहे हैं, तो हाँ SQL सर्वर को लगता है कि पृष्ठों को स्थानांतरित करना होगा क्योंकि इसे नए पृष्ठों को समायोजित करने के लिए स्थान की आवश्यकता होती है। मुझे यकीन नहीं है कि आपने 700 एमबी की गणना कैसे की है।

एक अन्य बात, कृपया SQL सर्वर मेमोरी की खपत के लिए टास्क मैनेजर को न देखें। यह आपको हमेशा सही मूल्य नहीं देता है खासकर जब SQL सर्वर सेवा खाते में मेमोरी विशेषाधिकार में लॉक पेज होते हैं । आपके मामले में, भले ही SQL सर्वर में 6 जीबी की अधिकतम सर्वर मेमोरी हो, ओएस सिर्फ 2 जीबी दिया जा रहा है, जो कि SQL सर्वर को इसकी खपत नहीं बढ़ने के लिए मजबूर कर रहा है क्योंकि SQL सर्वर के लिए 2 जीबी कम है। सिस्टम पर चलने वाले SQL सर्वर के अलावा भी कुछ है?

यदि आप SQL सर्वर मेमोरी खपत की गणना करना चाहते हैं तो कृपया उपयोग करें:

select
(physical_memory_in_use_kb/1024) Physical_Memory_usedby_Sqlserver_MB,
(locked_page_allocations_kb/1024 ) Locked_pages_used_Sqlserver_MB,
(virtual_address_space_committed_kb/1024 ) Total_Memory_in_MB,--RAM+ Pagefile
process_physical_memory_low,
process_virtual_memory_low
from sys.dm_os_process_memory

मुझे समझ में नहीं आता है कि Total_Memory_in_MB 6144 (अधिकतम मेमोरी) के बराबर क्यों नहीं है।

स्तंभ Total_Memory_in_MB SQL सर्वर (RAM + पेज फ़ाइल) द्वारा उपयोग की जाने वाली कुल मेमोरी को दर्शाता है। RAM वास्तव में भौतिक मेमोरी है जो उपयोग की गई या प्रतिबद्ध मेमोरी है। SQL सर्वर प्रक्रिया का कुछ हिस्सा डिस्क पर भी आधारित है और यह वर्चुअल मेमोरी या पेज फ़ाइल के रूप में बनता है और इसलिए यदि आप SQL सर्वर द्वारा उपभोग की जाने वाली TOTAL मेमोरी को देखने जा रहे हैं तो यह भौतिक मेमोरी और पेज फ़ाइल का योग होगा।

जबकि स्तंभ Physical_Memory_usedby_Sqlserver_MB केवल भौतिक मेमोरी (भौतिक RAM या समर्थित मेमोरी द्वारा समर्थित मेमोरी) का उपयोग किया जाता है। यही कारण है कि दोनों अलग हैं। यदि आप वास्तविक कॉलम को पहले देखते हैं, तो भौतिक मेमोरी का उपयोग किया जाता है और अन्य वर्चुअल मेमोरी के लिए प्रतिबद्ध है।

यदि आप पृष्ठांकित मेमोरी देखना चाहते हैं जो Total_Memory_in_MB और Physical_Memory_usedby_Sqlserver_MB के बीच अंतर होगा ।

नोट: उपयोग की जाने वाली कुल मेमोरी का उपयोग भौतिक मेमोरी से अधिक होगा।


5

SQL Server बफ़र कैश के अलावा और भी बहुत से Caches का उपयोग करता है, हालाँकि यह सबसे बड़ा और दूर का सबसे बड़ा उदाहरण है (एक स्पष्ट उदाहरण योजना कैश है)। आप स्मृति के माध्यम से DBCC MEMORYSTATUSऔर DMV की एक किस्म पर करीब से नज़र डाल सकते हैं। लक्ष्य मेमोरी और कुल मेमोरी विशेष रूप से बफर पूल / कैश को संदर्भित करती है।

क्रिस्चियन बोल्टन के सेमीफाइनल प्रोफेशनल SQL सर्वर 2008 इंटरनैशनल एंड ट्रबलशूटिंग के कुछ अंश :

  • MSSQL$<instance >:Memory Manager\Total Server Memory (KB):
    यह बफ़र पूल के वर्तमान आकार को इंगित करता है।
  • MSSQL$<instance >:Memory Manager\Target Server Memory (KB):
    यह बफर पूल के लिए आदर्श आकार को इंगित करता है। कुल और लक्ष्य एक सर्वर पर लगभग एक ही होना चाहिए जिसमें कोई मेमोरी दबाव नहीं है जो कुछ समय से चल रहा है। यदि टोटल टारगेट से काफी कम है , तो यह संभावना है कि SQL सर्वर मेमोरी प्रेशर के कारण बफर पूल को विकसित नहीं कर सकता है, जिस स्थिति में आप आगे की जांच कर सकते हैं।

बस जोड़ने के लिए भले ही कुल और लक्ष्य सर्वर मेमोरी समान हो हम 100% सुनिश्चित नहीं हो सकते हैं कि कोई मेमोरी दबाव नहीं है। इस मामले में हमें कुछ और मेमोरी काउंटरों को आग लगाने और उनके डेटा प्राप्त करने के साथ-साथ किसी निष्कर्ष पर पहुंचने की आवश्यकता है।
शांकी

"टोटल और टारगेट सर्वर पर लगभग एक ही होना चाहिए, जिसमें कोई मेमोरी प्रेशर न हो जो कुछ समय से चल रहा हो।" आइए इस बारे में सोचते हैं। मैं 128 जीबी रैम के साथ एक नया एसक्यूएल सर्वर खड़ा करता हूं, और मैं एक 1 जीबी डेटाबेस लाता हूं। इसे एक महीने तक चलने दें। क्या मुझे वास्तव में यह विश्वास है कि कुल और लक्ष्य उस महीने के अंत में लगभग एक ही होने जा रहे हैं? यदि वे नहीं हैं, तो क्या मुझे विश्वास है कि सर्वर स्मृति दबाव में है? मेरे लिए इस पर भरोसा करना मुश्किल है।
माइक शेरिल 'कैट रिकॉल'
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.