माइक्रोसॉफ्ट सर्टिफाइड मास्टर ब्रेंट ओजर ने हाल ही में SQL सर्वर में समानता पर चर्चा की, विशेष रूप से प्रतीक्षा प्रकार CXPACKET और CXCONSUMER ने क्वेस्ट के डेटाबेस ट्रेनिंग डेज़ फॉल सीरीज़ की अपनी अंतिम किस्त में। अपने सामान्य विनोदी और सुलभ अंदाज़ में, ब्रेंट ने समानांतरवाद की अवधारणाओं को स्पष्ट किया और समझाया कि जब आप बहुत सारे CXPACKET और CXCONSUMER प्रतीक्षा आँकड़े देखते हैं तो इसे कैसे संभालना है।
सबसे पहले, समानांतरवाद क्या है, और SQL सर्वर क्वेरी को समानांतर में निष्पादित क्यों करता है?
सीधे शब्दों में कहें, SQL सर्वर स्वचालित रूप से पहचानता है कि किसी विशेष क्वेरी में एक बड़ा कार्यभार है, और यह निर्धारित करता है कि कार्य केवल एक से अधिक प्रोसेसर में अधिक कुशलता से किया जा सकता है। यह आम तौर पर एक स्मार्ट निर्णय है, लेकिन जब SQL सर्वर कार्य करने वाले थ्रेड्स में लोड को संतुलित नहीं करता है, तो यह परेशानी में पड़ सकता है।
CXPACKET और CXCONSUMER प्रतीक्षा प्रकारों को समझना
CXPACKET और CXCONSUMER प्रतीक्षा प्रकार हैं जो इंगित करते हैं कि कार्य समान रूप से संतुलित नहीं है। जब आप अपने सर्वर पर ये प्रतीक्षा आँकड़े देखते हैं, तो आपको पता चल जाएगा कि SQL सर्वर समानांतर में क्वेरी चला रहा है, लेकिन उपलब्ध प्रोसेसर में उन्हें वितरित करने का अच्छा काम नहीं कर रहा है।
प्रत्येक डेटाबेस पेशेवर "लागत" की अवधारणा से परिचित है, यह व्यक्त करने के लिए कि संसाधन खपत के संदर्भ में क्वेरी को निष्पादित करना कितना महंगा है। ये "क्वेरी रुपये" काम का एक अनुमानित उपाय है, और एक महत्वपूर्ण संकेत है कि क्वेरी समानांतर में चलेगी या नहीं। एक सस्ती क्वेरी को समानांतर में चलाने की आवश्यकता नहीं होगी, लेकिन एक महंगी क्वेरी होगी। लक्ष्य जितनी जल्दी हो सके क्वेरी को निष्पादित करना है ताकि अगली पंक्ति शुरू हो सके। SQL सर्वर एक थ्रेड को शेड्यूलर के रूप में निर्दिष्ट करता है, और यह थ्रेड, जिसे ब्रेंट ने "रोबोट अधिपति" समझा, वर्कर थ्रेड्स, या "रोबोट मिनियन्स" को समानांतर वर्कलोड के टुकड़े असाइन करेगा।
समानतावाद और रोबोट अधिपति
यह कैसे काम करता है यह दिखाने के लिए ब्रेंट एक डेमो में कबूतर। स्टैक ओवरफ्लो डेटाबेस का उपयोग करते हुए, उन्होंने एक कम लागत वाला डेटाबेस लुकअप बनाया जो एक इंडेक्स की उपस्थिति के कारण बहुत तेज़ था। निष्पादन योजना बहुत सीधी थी और इसे चलाने के लिए समानांतरवाद की आवश्यकता नहीं थी।
लेकिन, जब उन्होंने किसी ऐसी चीज़ की खोज शुरू की जो अनुक्रमणिका में नहीं थी, तो तालिका के संकुल अनुक्रमणिका पर प्रत्येक पंक्ति के लिए एक कुंजी लुकअप के लिए बाध्य करके चीज़ें बदल गईं। SQL सर्वर ने माना कि यह बहुत काम का होगा, इसलिए इसने समांतरता को पेश किया और निष्पादन योजना पर एक आइकन के रूप में इंगित किया। यदि निष्पादन योजना त्रि-आयामी थी, तो आप ढेर सारे थ्रेड्स को देख पाएंगे, लेकिन चूंकि ऐसा नहीं है, इसलिए आपको प्रत्येक CPU थ्रेड द्वारा निष्पादित लॉजिकल रीड्स जैसी जानकारी देखने के लिए आंकड़ों को देखने की आवश्यकता है।
हालाँकि, SQL सर्वर ने केवल कुछ थ्रेड्स को यह कार्य सौंपा, उन सभी को नहीं। ब्रेंट ने समझाया कि समानांतर आइकन से परे जो कुछ भी हो रहा है वह केवल निर्दिष्ट प्रोसेसर पर ही हो रहा है। इसलिए, प्रारंभिक पठन करने वाले धागे अब केवल वही हैं जो मुख्य लुकअप कर रहे हैं। रोबोट के अधिपति ने सभी मंत्रियों को पिच करने के लिए कहने के बजाय केवल कुछ मंत्रियों को पूरा कार्य करने के लिए कहा।
उन्होंने आगे बताया कि SQL सर्वर को इस बात का हिसाब देना होता है कि थ्रेड क्या कर रहे हैं और साथ ही यह भी ट्रैक करें कि रोबोट अधिपति क्या कर रहा है। शुरुआती दिनों में, यह सब काम एक प्रतीक्षा आंकड़े द्वारा दर्शाया गया था, लेकिन इसका कोई मतलब नहीं था क्योंकि कोई फर्क नहीं पड़ता, अधिपति को अभी भी इंतजार करना पड़ता है जबकि सभी धागे काम कर रहे हैं। इसलिए, एक नया प्रतीक्षा प्रकार पेश किया गया था - यह CXCONSUMER था और यह ट्रैक करता है कि शेड्यूलर/ओवरलॉर्ड थ्रेड क्या कर रहा है, जबकि CXPACKET ट्रैक करता है कि कार्यकर्ता/मिनियन थ्रेड क्या कर रहे हैं।
ब्रेंट एक प्रकार जोड़कर इसे और भी जटिल बनाने के लिए क्वेरी पर वापस चला गया। अब, यह और भी स्पष्ट हो जाता है कि समानांतरवाद ऑपरेशन को और अधिक कुशल बनाने के बजाय समस्या पैदा कर रहा है। कुछ वर्कर थ्रेड्स में काम और भी अधिक असंतुलित हो गया है, और कुछ की मेमोरी खत्म हो रही है और डिस्क पर फैल रहे हैं। उन्होंने काम करने वाले कोर पर और भी बोझ डालते हुए एक जुड़ाव जोड़ा, जिन्हें गैर-काम करने वालों से कोई सहायता नहीं मिल रही है। CXPACKET आँकड़े चढ़ते रहे।
इस स्थिति में आप क्या कर सकते हैं? समांतरता निर्णय सर्वर स्तर पर हो रहा है न कि क्वेरी स्तर पर, इसलिए यह कुछ कॉन्फ़िगरेशन परिवर्तन करने जा रहा है।
कुंजी कॉन्फ़िगरेशन का आकलन करना
हमने पहले ही सीखा है कि यदि क्वेरी की लागत एक निश्चित स्तर से अधिक है, तो यह SQL सर्वर को समानांतर करने का कारण बनता है। छोटे प्रश्न एक ही सूत्र में विवश हो जाते हैं। लेकिन दहलीज को क्या नियंत्रित करता है? यह समानता के लिए कॉस्ट थ्रेसहोल्ड (CTFP) नामक एक संपत्ति है। डिफ़ॉल्ट रूप से, यदि निष्पादन योजना 5 क्वेरी रुपये से अधिक की लागत निर्धारित करती है, तो क्वेरी समानांतर हो जाएगी। हालांकि इस बारे में कोई मार्गदर्शन नहीं है कि इसे कैसे सेट किया जाए, ब्रेंट 50 से अधिक संख्या की सिफारिश करता है। इससे तुच्छ प्रश्नों के लिए समानता से छुटकारा मिल जाएगा।
एक अन्य कॉन्फ़िगरेशन समांतरता की अधिकतम डिग्री (MAXDOP) है जो SQL सर्वर द्वारा क्वेरी को असाइन किए जाने वाले थ्रेड्स की संख्या का वर्णन करता है। यहां डिफ़ॉल्ट मान शून्य है, जिसका अर्थ है कि SQL सर्वर क्वेरी को निष्पादित करने के लिए 64 तक सभी उपलब्ध प्रोसेसर का उपयोग कर सकता है। MAXDOP विकल्प को 1 पर सेट करना SQL सर्वर को केवल एक प्रोसेसर का उपयोग करने तक सीमित करता है - वास्तव में, एक सीरियल प्लान को क्वेरी निष्पादित करने के लिए मजबूर करता है। SQL सर्वर आपके पास मौजूद सर्वर कोर की संख्या के आधार पर MAXDOP मान की अनुशंसा करेगा, लेकिन आम तौर पर, कम MAXDOP समझ में आता है क्योंकि कई बार सभी कोर की आवश्यकता नहीं होगी।
ब्रेंट ने इन दो विन्यासों में समायोजन किया और अपनी क्वेरी फिर से चलाई। इस बार, हम देख सकते हैं कि अधिक कोर समानांतर ऑपरेशन में लगे हुए थे। CXPACKET प्रतीक्षा आँकड़े कम थे, जिसका अर्थ था कि लोड पहले की तुलना में अधिक कोर में समान रूप से संतुलित था।
CXPACKET और CXCONSUMER प्रतीक्षा आंकड़ों का मुकाबला करने के लिए युक्तियाँ
यदि आप अत्यधिक CXPACKET और CXCONSUMER प्रतीक्षा आँकड़े देख रहे हैं, तो ब्रेंट निम्नलिखित चरणों की अनुशंसा करता है:
- CTFP और MAXDOP प्रति उद्योग सर्वोत्तम अभ्यास सेट करें और फिर उन सेटिंग्स को कुछ दिनों के लिए बेक होने दें। यह योजना कैश को साफ़ करता है और SQL सर्वर को क्वेरी निष्पादन योजनाओं (लागत का पुनर्मूल्यांकन) के पुनर्निर्माण के लिए बाध्य करता है।
- अनुक्रमणिका में सुधार करें जिससे स्कैन और सॉर्ट करने के लिए क्वेरी समानांतर होने में लगने वाले समय में कमी आएगी। नई अनुक्रमणिका को बेक होने दें और फिर उन प्रश्नों की तलाश करें जो अभी भी बहुत काम कर रहे हैं।
- उन प्रश्नों को ट्यून करें और उन्हें कुछ दिनों के लिए बेक होने दें।
- आखिरकार, यदि समांतरता अभी भी एक गंभीर समस्या है, तो समांतरता के मुद्दों के साथ विशिष्ट प्रश्नों की तलाश शुरू करें।
और भी अधिक जानकारी के लिए, आप ब्रेंट के पूरे प्रशिक्षण सत्र को CXPACKET और CXCONSUMER पर ऑन-डिमांड प्रतीक्षा आँकड़े नीचे देख सकते हैं।
