क्या मैं 95% से नीचे प्रक्रिया कैशे हिट अनुपात बता सकता हूँ एक समस्या है। मेरे बॉक्स पर, मान 85 से 95% तक घूमते हैं।
मैं यह समस्या कैसे हल करूं? सर्वर को लगता है कि रैम बहुत है ताकि कोई समस्या न हो। और क्या हो सकता है?
जवाबों:
मुझे अपनी स्प्रेडशीट में महत्वपूर्ण डेटा बिंदुओं को संक्षेप में (और दौर!) दें:
Total Use Count 1
--------------------------------------- -----------------------
Total Plans Total MBs Avg Use Count Total Plans Total MBs
----------- --------- ------------- ----------- ---------
Adhoc 55,987 3,054 3 38,314 2,036
Proc 709 1,502 1,549 135 527तो पहली पंक्ति खराब सामान को दिखाती है, आपकी योजना कैश के बारे में 2/3 (कुछ बहुत मामूली अपवादों के साथ केवल एक बार उपयोग की जाने वाली चीजें)। आपको जितना हो सके उतना इनसे छुटकारा पाने की कोशिश करनी चाहिए। दूसरी पंक्ति अच्छा सामान दिखाती है। ये वो चीजें हैं जो आप अपने प्लान कैश में चाहते हैं (पुन: उपयोग की उच्च राशि वाली योजनाएं)। बाकी डेटा काफी हद तक अप्रासंगिक IMHO है। हालांकि एक अन्य बिंदु: आप कहते हैं कि एक्सेस विशेष रूप से संग्रहीत प्रक्रियाओं के माध्यम से होता है, लेकिन यदि वे प्रक्रियाएं गतिशील एसक्यूएल का उपयोग करती हैं, तो उन बयानों को AdHocयोजनाओं के रूप में कैश किया जाता है , Procयोजनाएं नहीं ।
2008 या उससे अधिक पर, मैं कहूंगा कि optimize for ad hoc workloadsअगली समस्या को चालू करें और आगे बढ़ें - यह एमबी की आपकी एकल-उपयोग योजनाओं की राशि लेगा जो वर्तमान में कुछ भी नहीं के बगल में है। दुर्भाग्य से, 2005 में, आपके विकल्प कथन-स्तर OPTION (RECOMPILE)और / या कम / कोई गतिशील एसक्यूएल का उपयोग करने के लिए उन संग्रहीत प्रक्रियाओं को रद्द करने से अलग नहीं हैं, या डेटाबेस स्तर पर मजबूर पैरामीटरकरण को चालू करने से अलग हैं - जो कि बेहतर योजना को फिर से उपयोग करने की कोशिश करता है योजना मिलान के उद्देश्यों के लिए शाब्दिक मानदंड के समान प्रश्न। मैं योजना मार्गदर्शिकाओं का उल्लेख करने में संकोच करता हूं क्योंकि वे डरपोक के लिए नहीं हैं और - जैसा कि मैंने बाद में इस उत्तर पर चर्चा की है - मुझे यकीन नहीं है कि यह उस रास्ते से नीचे जाने लायक है जब तक कि आपको पता नहीं है कि आपकी योजना कैश निश्चित रूप से आपके प्रदर्शन का स्रोत है मुद्दा।
मैंने इसके बारे में पूछा @@VERSION, क्योंकि SP2 से पहले, योजना कैश को आवंटित की जा सकने वाली मेमोरी की मात्रा के लिए एल्गोरिथ्म अपेक्षाकृत ढीला-ढाला था। SP2 के रूप में उन्होंने काफी कस दिया ( इस पोस्ट और इस पोस्ट में परिवर्तन को प्रलेखित और समझाया गया है )। आपके मामले में, योजना कैश अपेक्षाकृत भरी हुई है, इसलिए यह आश्चर्य की बात नहीं है कि आप कैश मिस कर रहे हैं। 26 जीबी = 5.8 जीबी की ऊपरी सीमा; मैं स्प्रेडशीट में ~ 4.5 GB देखता हूं लेकिन यहां कुछ गणना या कॉन्फ़िगरेशन अंतर हो सकता है जिसके बारे में मुझे नहीं पता है।
यह MSDN आलेखoptimize for ad hoc workloads 2008 में जोड़े गए सर्वर सेटिंग के बारे में बात करता है , और ध्वज 8032 का पता लगाता है, जो आपको अपने कैश को अधिक मेमोरी आवंटित करने की अनुमति देगा (संभवतः सर्वर स्तर पर इस सेटिंग को सेट करने की अनुपस्थिति में, जो अब मैं सभी को सलाह देता हूं हमारे ग्राहक, या कम से कम 99% जो अब 2005 में नहीं हैं)। मैंने 2005 एसपी 3 या एसपी 4 पर इस ट्रेस ध्वज का कभी परीक्षण नहीं किया है, और ईमानदारी से यह भी सुनिश्चित नहीं है कि इसे कब पेश किया गया था। मुझे यह भी पता नहीं है कि क्या यह आपकी समस्या को हल करेगा या इसे स्थानांतरित कर देगा, क्योंकि मुझे लगता है कि भले ही आपके पास कुछ% अधिक RAM कैश के लिए आवंटित किया गया हो, फिर भी आप इसे भरते रहेंगे और बहुत सारे कैश मिस होने के कारण आपके संग्रहीत कार्यविधियाँ।
या, ज़ाहिर है, अगर वहाँ भी हल करने के लिए एक समस्या है जो सीधे योजना कैश से संबंधित है। सिर्फ इसलिए कि आपका कैश हिट अनुपात उतना अधिक नहीं है जितना कि आप उम्मीद कर सकते हैं कि इसका मतलब यह नहीं है कि यह आपकी समस्या पैदा कर रहा है, और निश्चित रूप से इसका मतलब यह है कि यहां तक कि 100% कैश हिट अनुपात - जो कि यथार्थवादी नहीं लगता है, ऐसा नहीं है आपकी योजनाएँ एकल-उपयोग और तदर्थ हैं - आपके उपयोगकर्ता अभी भी पूरी तरह से किसी और चीज़ के कारण होने वाली प्रदर्शन समस्याओं से पीड़ित हो सकते हैं।
मेरा सुझाव योजना कैश हिट अनुपात की तुलना में बेहतर धूम्रपान बंदूकों की तलाश करना है। अपने उपयोगकर्ताओं की प्रदर्शन शिकायतों के बारे में अधिक जानकारी प्राप्त करें। क्या सभी प्रश्न हमेशा धीमे होते हैं? कुछ प्रश्न? दिन / सप्ताह / व्यापार चक्र का निश्चित समय? क्या केवल रिपोर्टिंग की गति धीमी है? SQL सर्वर सर्वोत्तम प्रथाओं पर इस भर्ती के सूखे और लंबे दस्तावेज़ के माध्यम से एक गंभीर रीडिंग लें - विशेष रूप से, प्रतीक्षा और कतारों पर अनुभाग, जो आपको प्रदर्शन समस्याओं की पहचान, निदान और समाधान के लिए एक तार्किक दृष्टिकोण तैयार करने में मदद कर सकता है। डैशबोर्ड पर कुछ नंबर बनाना बेहतर दिखता है - एक ऐसा नंबर जिसे आप सीधे तौर पर समस्या में योगदान नहीं देते हैं - बहुत संतोषजनक हो सकता है, लेकिन यदि यह आपके उपयोगकर्ताओं के प्रदर्शन के मुद्दों को हल नहीं करता है, तो यह वास्तव में आपको नहीं मिला है। कहीं भी।
ये संकलन / पुनर्संयोजन और योजना के पुन: उपयोग पर पढ़ने में भी उपयोगी हो सकते हैं। इनमें से कुछ 2008 (विशेष रूप से तदर्थ कार्यभार सेटिंग के बारे में) पर केंद्रित हैं, लेकिन 2005 के लिए और / या उन्नयन (संकेत, संकेत) के लाभों को बेहतर ढंग से समझने के लिए बहुत सारी जानकारी अभी भी उपयोगी है।