पिछले वर्ष की अपनी कई पोस्टों में मैंने एक विशेष प्रतीक्षा प्रकार को देखने वाले लोगों के विषय का उपयोग किया है और फिर प्रतीक्षा करने के लिए "घुटने के बल" फैशन में प्रतिक्रिया व्यक्त की है। आमतौर पर इसका मतलब है कि कुछ खराब इंटरनेट सलाह का पालन करना और कठोर, अनुचित कार्रवाई करना या इस बारे में निष्कर्ष निकालना कि समस्या का मूल कारण क्या है और फिर जंगली-हंस का पीछा करने में समय और प्रयास बर्बाद करना।
प्रतीक्षा प्रकारों में से एक जहां घुटने के बल प्रतिक्रिया सबसे मजबूत होती है, और जहां कुछ सबसे खराब सलाह मौजूद होती है, वह है CXPACKET प्रतीक्षा। यह प्रतीक्षा प्रकार भी है जो आमतौर पर लोगों के सर्वर पर शीर्ष प्रतीक्षा है (2010 और 2014 के मेरे दो बड़े प्रतीक्षा प्रकारों के सर्वेक्षणों के अनुसार - विवरण के लिए यहां देखें), इसलिए मैं इसे इस पोस्ट में कवर करने जा रहा हूं।
CXPACKET प्रतीक्षा प्रकार का क्या अर्थ है?
सबसे सरल व्याख्या यह है कि CXPACKET का अर्थ है कि आपके पास समानांतर में चल रहे प्रश्न हैं और आप *हमेशा* देखेंगे कि CXPACKET समानांतर क्वेरी की प्रतीक्षा करता है। CXPACKET प्रतीक्षा का मतलब यह नहीं है कि आपके पास समस्याग्रस्त समांतरता है - आपको इसे निर्धारित करने के लिए गहराई से खुदाई करने की आवश्यकता है।
समानांतर ऑपरेटर के उदाहरण के रूप में, रिपार्टिशन स्ट्रीम्स ऑपरेटर पर विचार करें, जिसका ग्राफिकल क्वेरी प्लान में निम्न आइकन है:
और यहां एक तस्वीर है जो दिखाती है कि इस ऑपरेटर के लिए समानांतर थ्रेड्स के संदर्भ में क्या चल रहा है, डिग्री-ऑफ-पैरेललिज़्म (डीओपी) 4 के बराबर है:
DOP =4 के लिए, चार निर्माता थ्रेड होंगे, जो क्वेरी प्लान में पहले से डेटा खींचते हैं, फिर डेटा चार उपभोक्ता थ्रेड्स के माध्यम से शेष क्वेरी प्लान में वापस चला जाता है।
आप समानांतर ऑपरेटर में विभिन्न थ्रेड देख सकते हैं जो sys.dm_os_waiting_tasks का उपयोग करके संसाधन की प्रतीक्षा कर रहे हैं। DMV, exec_context_id . में कॉलम (इस पोस्ट में ऐसा करने के लिए मेरी स्क्रिप्ट है)।
किसी भी समानांतर योजना के लिए हमेशा एक 'नियंत्रण' धागा होता है, जो ऐतिहासिक दुर्घटना से हमेशा थ्रेड आईडी 0 होता है। नियंत्रण धागा हमेशा एक CXPACKET प्रतीक्षा को पंजीकृत करता है, जिसकी अवधि योजना को निष्पादित करने में लगने वाले समय के बराबर होती है। पॉल व्हाइट ने यहाँ समानांतर योजनाओं में धागों की एक बड़ी व्याख्या की है।
गैर-नियंत्रण थ्रेड्स केवल तभी पंजीकृत होंगे जब CXPACKET प्रतीक्षा करता है यदि वे ऑपरेटर में अन्य थ्रेड्स से पहले पूरा करते हैं। यह तब हो सकता है जब एक थ्रेड लंबे समय तक संसाधन की प्रतीक्षा में अटक जाता है, इसलिए यह देखने के लिए देखें कि थ्रेड का प्रतीक्षा प्रकार क्या है जो CXPACKET नहीं दिखा रहा है (ऊपर मेरी स्क्रिप्ट का उपयोग करके) और उचित रूप से समस्या निवारण करें। यह थ्रेड्स के बीच एक विषम कार्य वितरण के कारण भी हो सकता है, और मैं अपनी अगली पोस्ट में उस मामले पर और अधिक गहराई में जाऊंगा (यह पुराने आंकड़ों और अन्य कार्डिनैलिटी अनुमान समस्याओं के कारण होता है)।
ध्यान दें कि SQL Server 2016 SP2 और SQL Server 2017 RTM CU3 में, उपभोक्ता थ्रेड्स अब पंजीकृत नहीं हैं CXPACKET प्रतीक्षा करता है। वे CXCONSUMER प्रतीक्षा को पंजीकृत करते हैं, जो सौम्य हैं और जिन्हें अनदेखा किया जा सकता है। यह उत्पन्न होने वाले CXPACKET प्रतीक्षा की संख्या को कम करने के लिए है, और शेष लोगों के कार्रवाई योग्य होने की अधिक संभावना है।
अप्रत्याशित समानता?
यह देखते हुए कि CXPACKET का सीधा सा मतलब है कि आपके पास समानता हो रही है, पहली बात यह है कि क्या आप उस क्वेरी के लिए समानता की अपेक्षा करते हैं जो इसका उपयोग कर रही है। मेरी क्वेरी आपको क्वेरी प्लान नोड आईडी देगी जहां समांतरता हो रही है (यह एक्सएमएल क्वेरी प्लान से नोड आईडी खींचती है यदि थ्रेड का प्रतीक्षा प्रकार सीएक्सपैकेट है) तो उस नोड आईडी को देखें और निर्धारित करें कि समांतरता समझ में आता है या नहीं ।
अप्रत्याशित समानता के सामान्य मामलों में से एक तब होता है जब एक टेबल स्कैन होता है जहां आप एक छोटे इंडेक्स की तलाश या स्कैन की अपेक्षा कर रहे होते हैं। आप इसे या तो क्वेरी प्लान में देखेंगे या आपको CXPACKET वेट (एक क्लासिक वेट स्टैटिस्टिक्स पैटर्न देखने के लिए) के साथ बहुत सारे PAGEIOLATCH_SH वेट्स (यहां विस्तार से चर्चा की गई) दिखाई देंगे। अनपेक्षित टेबल स्कैन के कई कारण हैं, जिनमें शामिल हैं:
- गैर-क्लस्टर इंडेक्स मौजूद नहीं है, इसलिए टेबल स्कैन ही एकमात्र विकल्प है
- पुराने आंकड़े इसलिए क्वेरी ऑप्टिमाइज़र को लगता है कि टेबल स्कैन उपयोग करने के लिए सबसे अच्छी डेटा एक्सेस विधि है
- एक अंतर्निहित रूपांतरण, एक तालिका कॉलम और एक चर या पैरामीटर के बीच डेटा प्रकार बेमेल होने के कारण, जिसका अर्थ है कि एक गैर-संकुल सूचकांक का उपयोग नहीं किया जा सकता है
- एक चर या पैरामीटर के बजाय एक टेबल कॉलम पर अंकगणित का प्रदर्शन किया जा रहा है, जिसका अर्थ है कि एक गैर-संकुल सूचकांक का उपयोग नहीं किया जा सकता है
इन सभी मामलों में, समाधान इस बात से तय होता है कि आपको मूल कारण क्या लगता है।
लेकिन क्या होगा यदि कोई स्पष्ट मूल मामला नहीं है और क्वेरी को समानांतर योजना की गारंटी देने के लिए पर्याप्त महंगा माना जाता है?
समानता को रोकना
अन्य बातों के अलावा, क्वेरी ऑप्टिमाइज़र समानांतर क्वेरी प्लान तैयार करने का निर्णय लेता है यदि सीरियल प्लान की लागत cost threshold for parallelism से अधिक है , उदाहरण के लिए एक sp_configure सेटिंग। समानांतरवाद (या CTFP) के लिए लागत सीमा डिफ़ॉल्ट रूप से पांच पर सेट है, जिसका अर्थ है कि समानांतर योजना के निर्माण को ट्रिगर करने के लिए किसी योजना को बहुत महंगा नहीं होना चाहिए।
अवांछित समानता को रोकने के सबसे आसान तरीकों में से एक है CTFP को बहुत अधिक संख्या में बढ़ाना, जितना अधिक आप इसे सेट करते हैं, उतनी ही कम समानांतर योजनाएँ बनाई जाएंगी। कुछ लोग CTFP को 25 और 50 के बीच कहीं पर सेट करने की वकालत करते हैं, लेकिन सभी ट्वीक करने योग्य सेटिंग्स के साथ, विभिन्न मूल्यों का परीक्षण करना और यह देखना सबसे अच्छा है कि आपके पर्यावरण के लिए सबसे अच्छा क्या काम करता है। यदि आप एक अच्छा CTFP मान चुनने में मदद करने के लिए कुछ और प्रोग्रामेटिक तरीके चाहते हैं, तो जोनाथन ने प्लान कैश का विश्लेषण करने और CTFP के लिए सुझाए गए मान का उत्पादन करने के लिए एक क्वेरी दिखाते हुए एक ब्लॉग पोस्ट लिखा। उदाहरण के तौर पर, हमारे पास एक क्लाइंट है जिसका CTFP 200 पर सेट है, और दूसरा अधिकतम - 32767 पर सेट है - किसी भी समानता को जबरन रोकने के तरीके के रूप में।
आपको आश्चर्य हो सकता है कि दूसरे क्लाइंट को समानांतरवाद को रोकने के लिए एक स्लेजहैमर विधि के रूप में CTFP का उपयोग क्यों करना पड़ा जब आपको लगता है कि वे सर्वर को 'समानांतरता की अधिकतम डिग्री' (या MAXDOP) को 1 पर सेट कर सकते हैं। ठीक है, कोई भी अनुमति स्तर वाला कोई भी व्यक्ति कर सकता है एक क्वेरी MAXDOP संकेत निर्दिष्ट करें और सर्वर MAXDOP सेटिंग को ओवरराइड करें, लेकिन CTFP को ओवरराइड नहीं किया जा सकता है।
और यह समानता को सीमित करने का एक और तरीका है - उस क्वेरी पर MAXDOP संकेत सेट करना जिसे आप समानांतर नहीं करना चाहते।
आप सर्वर MAXDOP सेटिंग को भी कम कर सकते हैं, लेकिन यह एक कठोर समाधान है क्योंकि यह सब कुछ समानांतरता का उपयोग करने से रोक सकता है। आजकल सर्वरों पर मिश्रित कार्यभार होना आम बात है, उदाहरण के लिए कुछ OLTP प्रश्नों और कुछ रिपोर्टिंग प्रश्नों के साथ। यदि आप सर्वर MAXDOP को कम करते हैं, तो आप रिपोर्टिंग क्वेरी के प्रदर्शन को प्रभावित करने वाले हैं।
एक बेहतर समाधान जब एक मिश्रित कार्यभार होता है, जैसा कि मैंने ऊपर वर्णित CTFP का उपयोग करना होगा या संसाधन गवर्नर का उपयोग करना होगा (जो कि केवल उद्यम है, मुझे डर है)। आप कार्यभार को कार्यभार समूहों में अलग करने के लिए संसाधन गवर्नर का उपयोग कर सकते हैं, और फिर प्रत्येक कार्यभार समूह के लिए MAX_DOP (अंडरस्कोर टाइपो नहीं है) सेट कर सकते हैं। और रिसोर्स गवर्नर का उपयोग करने के बारे में अच्छी बात यह है कि MAX_DOP को MAXDOP क्वेरी संकेत द्वारा ओवरराइड नहीं किया जा सकता है।
सारांश
इस सोच के जाल में न पड़ें कि CXPACKET स्वचालित रूप से प्रतीक्षा करता है इसका मतलब है कि आपके साथ खराब समानता हो रही है, और निश्चित रूप से कुछ इंटरनेट सलाह का पालन नहीं करते हैं जो मैंने MAXDOP को 1 पर सेट करके सर्वर को बंद करने के बारे में देखा है। समय निकालें यह जांचने के लिए कि आप CXPACKET को क्यों देख रहे हैं, प्रतीक्षा कर रहा है और क्या यह कुछ संबोधित किया जाना है या सिर्फ एक कार्यभार का एक आर्टिफैक्ट है जो सही ढंग से चल रहा है।
जहां तक सामान्य प्रतीक्षा आंकड़ों का संबंध है, आप प्रदर्शन समस्या निवारण के लिए उनका उपयोग करने के बारे में अधिक जानकारी यहां प्राप्त कर सकते हैं:
- मेरी SQLskills ब्लॉग पोस्ट श्रृंखला, प्रतीक्षा आँकड़ों से शुरू होती है, या कृपया मुझे बताएं कि यह कहाँ दर्द होता है
- मेरे प्रतीक्षा प्रकार और कुंडी कक्षा पुस्तकालय यहाँ
- मेरा प्लूरलसाइट ऑनलाइन प्रशिक्षण पाठ्यक्रम SQL सर्वर:प्रतीक्षा सांख्यिकी का उपयोग करके प्रदर्शन समस्या निवारण
- एसक्यूएल संतरी प्रदर्शन सलाहकार
श्रृंखला के अगले लेख में, मैं विषम समानता पर चर्चा करूँगा और आपको इसे होते हुए देखने का एक सरल तरीका प्रदान करूँगा। तब तक, समस्या निवारण के लिए शुभकामनाएँ!
