RESOURCE_SEMAPHORE और RESOURCE_SEMAPHORE_QUERY_COMPILE सेकंड प्रकार कैसे हल करें


13

हम धीमे चल रहे sql सर्वर प्रश्नों के मूल कारण का पता लगाने का प्रयास कर रहे हैं / डेटाबेस में से किसी एक से डेटा को प्राप्त कर रहे हैं, आकार 300 GB, नीचे विन्यास के साथ सर्वर पर होस्ट किया गया है:

Windows सर्वर 2003 R2, SP2, एंटरप्राइज़ संस्करण, 16 जीबी रैम, 12 सीपीयू 32 बिट

SQL सर्वर 2005, SP4, एंटरप्राइज़ संस्करण, 32 बिट।

हमने पहले ही 64 बिट में अपग्रेड पर कारोबार की सूचना दे दी है जिसमें एक महीने का समय लगेगा।

लेकिन वर्तमान मुद्दे के लिए, हम डेटा को इकट्ठा करने की कोशिश कर रहे हैं यदि हम मेमोरी दबाव को हल कर सकते हैं या अंत में रैम को बढ़ाने के लिए एक निष्कर्ष पर आ सकते हैं।

पूरा किया गया कार्य: पुन: अनुक्रमण और अद्यतन आँकड़े इस DB के लिए उचित हैं।

जैसा कि नीचे दिखाया गया है, हम पिछले 5 दिनों के लिए सेमाफोर वेइटाइप को देख रहे हैं, जो भार के घंटों के दौरान चला गया है:

waittype

प्रश्नों के बाद कुछ जानकारी: बफर का आकार = 137272

SELECT SUM(virtual_memory_committed_kb)
FROM sys.dm_os_memory_clerks
WHERE type='MEMORYCLERK_SQLBUFFERPOOL'

और अर्ध-मेमोरी मेमोरी = 644024 प्रति प्रश्न नीचे

 SELECT SUM(total_memory_kb)
FROM sys.dm_exec_query_resource_semaphores

नीचे कुछ और जानकारी एकत्र की गई है dm_exec_query_resource_semaphoresऔर sys.dm_exec_query_memory_grantsdmv की है

dmvserror

इसलिए ऊपर दी गई जानकारी से और SP_Blitz डेटा रिसोर्स सेमाफोर की समस्या से लगता है।

उपलब्ध 16 जीबी रैम की तुलना में मेमोरी 'target_memory_kb' संसाधन सेमीफोर आईडी के लिए बहुत कम है।

नोट * प्रति 8 घंटे के विश्लेषण पर 'लक्ष्य_मिमोरी_बेक' हमेशा 16 जीबी उपलब्ध की तुलना में 1 जीबी से कम है?

यहाँ क्या समस्या हो सकती है और कैसे हल करें, कृपया सुझाव दें

धन्यवाद


टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है । इसके अलावा ऑफ-टॉपिक टिप्पणियां केवल हटा दी जाएंगी।
पॉल व्हाइट 9

जवाबों:


25

ओह, अच्छाई, मुझे यहाँ कुछ बुरी खबर है।

32-बिट OS पर, SQL सर्वर केवल क्वेरी वर्कस्पेस जैसी चीजों के लिए पहले 4GB मेमोरी का उपयोग करता है। (और यह उस 4 जीबी के लिए ओएस लड़ रहा है, भी - किसी भी अन्य चल रहे ऐप भी उस मेमोरी के लिए प्रतिस्पर्धा करेंगे।)

4 जीबी बहुत लग सकता है, लेकिन एक क्वेरी लिखना अपेक्षाकृत आसान है जिसे चलाने के लिए कई जीबी मेमोरी की आवश्यकता होती है। जब पर्याप्त क्वेरी पर्याप्त मेमोरी की मांग करते हैं, तो SQL सर्वर RESOURCE_SEMAPHORE प्रतीक्षा करता है क्योंकि क्वेरी को प्रारंभ करने के लिए पर्याप्त मेमोरी नहीं मिल सकती है। RESOURCE_SEMAPHORE_QUERY_COMPILE का अर्थ है कि उन्हें निष्पादन योजना तैयार करने के लिए पर्याप्त मेमोरी भी नहीं मिल सकती है - और हाँ, यह बहुत बुरा है।

तो आप इसे कैसे ठीक करते हैं?

  • 64-बिट OS पर स्विच करें (आपके द्वारा चलाया जा रहा OS वैसे भी समर्थन से लंबा है)
  • SQL सर्वर के 64-बिट बिल्ड पर स्विच करें
  • सर्वर पर मेमोरी मांगों को कम करें (इस बॉक्स पर कोई अन्य ऐप न चलाएं, और यह 32-बिट बॉक्स पर विशेष रूप से महत्वपूर्ण है क्योंकि हम सिर्फ 4GB पर कैप किए गए हैं)
  • AWE / PAE स्विच के साथ अधिक मेमोरी का उपयोग करें - सिवाय इसके कि RESOURCE_SEMAPHORE के लिए काम नहीं करता है क्योंकि SQL सर्वर केवल क्वेरी वर्कस्पेस के लिए पहले 4GB का उपयोग कर सकता है
  • ट्यून क्वेरी और इंडेक्स ताकि उन्हें कम मेमोरी की आवश्यकता हो

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.