घुटना टेककर प्रदर्शन समस्या निवारण से बचना

प्रदर्शन समस्या निवारण एक कला और विज्ञान है। कला अनुभव (और दूसरों के अनुभवों से सीखने) से आती है और विज्ञान प्रसिद्ध दिशानिर्देशों से आता है कि किन परिदृश्यों में क्या करना है।

या कम से कम मुझे यही सोचना और सिखाना पसंद है।

हकीकत में, कई डीबीए और डेवलपर्स वहां अभ्यास करते हैं जिसे मैं 'घुटने-झटका प्रदर्शन समस्या निवारण' कहता हूं। यह आमतौर पर तब होता है जब कोई प्रदर्शन समस्या महत्वपूर्ण चरण में पहुंच जाती है, उदाहरण के लिए, प्रश्नों का समय समाप्त हो जाना, धीमी गति से चलने वाली प्रक्रियाएं या विफल होना, उपयोगकर्ता असंतुष्ट, और प्रबंधन उत्तर और कार्रवाई तेजी से चाहता है!

'घुटने का झटका' समस्या का कुछ सतही विश्लेषण करने और निष्कर्ष पर कूदने से आता है (वास्तव में यह एक तिनके को पकड़ रहा है) कि सबसे प्रचलित लक्षण मूल कारण होना चाहिए और इसे संबोधित करने की कोशिश करना, कोई फायदा नहीं हुआ, अक्सर ऑनलाइन मिलने वाली गुमराह या सर्वथा गलत सलाह का उपयोग करना। इससे बहुत निराशा होती है और समय बर्बाद होता है, और अक्सर बर्बाद धन की ओर जाता है जब संगठन सर्वर और/या I/O सबसिस्टम को अपग्रेड करके समस्या पर हार्डवेयर फेंकने का प्रयास करने का निर्णय लेता है, केवल समस्या को खोजने के लिए अभी भी है , या बहुत जल्दी फिर से प्रकट होता है।

वेट स्टैटिस्टिक्स एनालिसिस उन क्षेत्रों में से एक है जहां घुटने के बल चलना सबसे आसान है, और इस पोस्ट में मैं कुछ सामान्य प्रतीक्षा प्रकारों और गलतियों के बारे में बात करने जा रहा हूं जो लोग अपने आसपास करते हैं। इस तरह के एक लेख में हर मामले में क्या करना है, इस बारे में बहुत गहराई से जाने की गुंजाइश नहीं है, लेकिन मैं आपको सही दिशा में इंगित करने के लिए पर्याप्त जानकारी दूंगा।

LCK_M_XX

अधिकांश लोग यह मानते हैं कि यदि लॉकिंग वेटिंग सबसे अधिक प्रचलित है, तो यह किसी प्रकार की अवरोधन समस्या होनी चाहिए जो कि समस्या है। अक्सर ऐसा होता है, जैसे कि उपयुक्त गैर-संकुल सूचकांक की कमी के कारण REPEATABLE_READ या SERIALIZABLE आइसोलेशन स्तरों में एक टेबल स्कैन होता है जो S टेबल लॉक तक बढ़ जाता है। (और एक त्वरित संकेत के रूप में, यदि आपको नहीं लगता कि आप कभी भी सीरियल का उपयोग करते हैं, तो आप करते हैं यदि आप वितरित लेनदेन का उपयोग करते हैं - सब कुछ कवर के तहत सीरियल में परिवर्तित हो जाता है, जिससे अप्रत्याशित अवरोध और गतिरोध हो सकता है।)

हालाँकि, अक्सर ऐसा होता है कि अवरोध किसी और चीज़ के कारण होता है। डिफ़ॉल्ट READ_COMMITTED आइसोलेशन स्तर के तहत, परिवर्तनों को कवर करने वाले लॉक को तब तक रखा जाता है जब तक कि लेन-देन नहीं हो जाता है, और उसी पंक्ति (पंक्तियों) में पढ़ने और अन्य अपडेट को ब्लॉक कर देगा। अगर कुछ भी लेन-देन करने से रोकता है, तो यह ब्लॉकिंग का कारण बन सकता है।

उदाहरण के लिए, यदि डेटाबेस को सिंक्रोनाइज़ किया जाता है, तो लेन-देन तब तक अपने लॉक को कमिट और रिलीज़ नहीं कर सकता है जब तक कि लॉग रिकॉर्ड को मिरर में नहीं भेजा जाता है और मिरर के लॉग ड्राइव पर लिखा जाता है। यदि नेटवर्क गंभीर रूप से भीड़भाड़ वाला है, या दर्पण पर बड़े पैमाने पर I/O विवाद है, तो यह मिररिंग ऑपरेशन में गंभीर रूप से देरी कर सकता है, और इसलिए लेनदेन को करने में अधिक समय लगता है। यह अवरुद्ध करने जैसा लगेगा लेकिन मूल कारण मिररिंग के साथ संसाधन विवाद है।

लॉकिंग वेट के लिए, जब तक कि क्वेरी प्लान को देखने से कारण स्पष्ट न हो, लॉक रिसोर्स (जैसे टेबल-लेवल जो लॉक एस्केलेशन, या आइसोलेशन लेवल को दर्शाता है, ब्लॉकिंग चेन का पालन करें (एक स्क्रिप्ट का उपयोग करके जो ब्लॉकिंग_सेशन_आईडी कॉलम को sys.dm_exec_requests में चलता है और फिर यह देखने के लिए देखें कि ब्लॉकिंग चेन के शीर्ष पर कौन सा धागा इंतजार कर रहा है। यह मूल कारण की ओर इशारा करेगा।

ASYNC_NETWORK_IO

इसका नाम बहुत भ्रम पैदा करता है। आप किस शब्द पर ध्यान केंद्रित करते हैं? नेटवर्क। इस प्रतीक्षा प्रकार के कारण का आमतौर पर नेटवर्क से कोई लेना-देना नहीं होता है। इसे वास्तव में WAITING_FOR_APP_ACK (नॉलेजमेंट), या ऐसा ही कुछ कहा जाना चाहिए, जैसा कि वास्तव में हो रहा है:SQL सर्वर ने क्लाइंट को कुछ डेटा भेजा है और क्लाइंट को यह स्वीकार करने की प्रतीक्षा कर रहा है कि उसने डेटा का उपभोग किया है।

प्रतीक्षा आँकड़ों के बारे में पढ़ाते समय मेरे पसंदीदा डेमो में से एक एक क्वेरी चलाना है जो प्रबंधन स्टूडियो में एक बड़ा परिणाम देता है और सर्वर रैक को ASYNC_NETWORK_IO प्रतीक्षा करता है। स्पष्ट रूप से कोई नेटवर्क शामिल नहीं है - यह सिर्फ SSMS है जो SQL सर्वर को उत्तर देने में लंबा समय लेता है। यह वही कर रहा है जिसे आरबीएआर (रो-बाय-एगोनाइजिंग-रो) के रूप में जाना जाता है, जहां एक समय में केवल एक पंक्ति को परिणामों से खींचा जाता है और संसाधित किया जाता है, बजाय सभी परिणामों को कैशिंग करने और फिर तुरंत SQL सर्वर को जवाब देने और संसाधित करने के लिए आगे बढ़ना कैश्ड पंक्तियाँ।

यह ASYNC_NETWORK_IO प्रतीक्षा का प्रमुख कारण है - खराब एप्लिकेशन डिज़ाइन। फिर मैं देखता हूं कि एप्लिकेशन कोड चलाने वाले सर्वर में प्रदर्शन समस्या है, भले ही एप्लिकेशन कोड स्वयं अच्छी तरह डिज़ाइन किया गया हो। कभी-कभी यह नेटवर्क होता है, लेकिन मेरे अनुभव में ऐसा बहुत कम होता है।

OLEDB

यहां सामान्य प्रतिक्रिया यह है कि इस प्रतीक्षा प्रकार को लिंक किए गए सर्वरों के साथ समान किया जाए। हालाँकि, यह प्रतीक्षा समय अधिक सामान्य हो गया जब SQL सर्वर 2005 को शिप किया गया, क्योंकि 2005 में नए DMV का एक बेड़ा था, और DMV ज्यादातर कवर के तहत OLE DB का उपयोग करते हैं। लिंक की गई सर्वर समस्याओं की तलाश करने से पहले, मैं जांचता हूं कि कोई निगरानी उपकरण सर्वर पर लगातार DMV चला रहा है या नहीं।

यदि आपके पास लिंक किए गए सर्वर हैं, तो लिंक किए गए सर्वर पर जाकर समस्या निवारण जारी रखें और वहां प्रतीक्षा आँकड़ों को देखकर देखें कि सबसे प्रचलित समस्या क्या है, और फिर वही विश्लेषण जारी रखें।

एक अन्य चीज जो OLEDB प्रतीक्षा का कारण बन सकती है वह है DBCC CHECKDB (और संबंधित कमांड)। यह अपने क्वेरी प्रोसेसर और स्टोरेज इंजन सबसिस्टम के बीच सूचनाओं को संप्रेषित करने के लिए OLE DB रोसेट का उपयोग करता है।

अन्य प्रतीक्षाएं

CXPACKET, PAGEIOLATCH_XX, SOS_SCHEDULER_YIELD, और WRITELOG, कुछ अन्य प्रतीक्षाएं हैं जो घुटने के बल चलने वाली प्रतिक्रियाओं का कारण बनती हैं, और मैं उन्हें अगले महीने अपनी पोस्ट में शामिल करूंगा।

सारांश

जब आपके पास कोई प्रदर्शन समस्या हो, तो उस डेटा को समझने के लिए समय निकालें जिसे आप देख रहे हैं और समस्या के मूल कारण को कम करने में मदद करने के लिए आगे की जांच करें। जो कुछ भी शीर्ष प्रतीक्षा आँकड़ा प्रतीत होता है उसे केवल समझ न लें और ऑनलाइन मिलने वाली सलाह के पहले भाग का पालन करें (जब तक कि यह एक प्रसिद्ध और प्रतिष्ठित स्रोत से न हो) या आप संभवतः अपनी समस्या का समाधान नहीं करेंगे, और यहां तक ​​​​कि हो सकता है इसे और खराब करें।

जहां तक ​​सामान्य प्रतीक्षा आंकड़ों का संबंध है, आप प्रदर्शन समस्या निवारण के लिए उनका उपयोग करने के बारे में अधिक जानकारी यहां प्राप्त कर सकते हैं:

• मेरी ब्लॉग पोस्ट श्रृंखला, प्रतीक्षा आंकड़ों से शुरू होती है, या कृपया मुझे बताएं कि यह कहां दर्द होता है
• मेरे प्रतीक्षा प्रकार और कुंडी कक्षा पुस्तकालय यहां
• मेरा प्लूरलसाइट ऑनलाइन प्रशिक्षण पाठ्यक्रम SQL सर्वर:प्रतीक्षा सांख्यिकी का उपयोग करके प्रदर्शन समस्या निवारण
• एसक्यूएल संतरी प्रदर्शन सलाहकार

यह उन पदों की श्रृंखला में पहला था जो मैं इस वर्ष के दौरान कर रहा हूँ जो SQL सर्वर के आसपास घुटने-झटके (पुनः) कार्यों के बारे में बात करते हैं और वे गलत काम क्यों कर रहे हैं। अगली बार तक, समस्या निवारण के लिए शुभकामनाएँ!