अनपेक्षित साइड इफेक्ट्स - स्लीपिंग सेशन होल्डिंग लॉक

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

सत्र की स्थिति को समझना

SQL सर्वर के लिए आप किस DMV को देखते हैं, इस पर निर्भर करते हुए, एक सत्र में कुछ भिन्न स्थितियाँ हो सकती हैं। स्लीपिंग स्टेटस का मतलब है कि इंजन ने कमांड को पूरा कर लिया है, क्लाइंट और सर्वर के बीच सब कुछ इंटरेक्शन के हिसाब से पूरा हो गया है, और कनेक्शन क्लाइंट से अगले कमांड के आने का इंतजार कर रहा है। यदि स्लीपिंग सत्र में एक खुला लेनदेन होता है, तो यह हमेशा कोड से संबंधित होता है न कि SQL सर्वर से। खुले हुए लेन-देन को कुछ बातों से समझाया जा सकता है। पहली संभावना एक स्पष्ट लेन-देन के साथ एक प्रक्रिया है जो XACT_ABORT सेटिंग को चालू नहीं करती है और फिर सीएसएस टीम द्वारा इस वास्तव में पुरानी पोस्ट में बताए गए अनुसार सफाई को सही ढंग से संभालने वाले एप्लिकेशन के बिना समय समाप्त हो जाता है:

• यह कैसे काम करता है:स्लीपिंग/वेटिंग कमांड सेशन क्या है

यदि प्रक्रिया ने XACT_ABORT सेटिंग को सक्षम किया होता तो यह लेन-देन का समय समाप्त होने पर स्वचालित रूप से निरस्त हो जाता और लेन-देन वापस आ जाता। SQL सर्वर ठीक वही कर रहा है जो इसे ANSI मानकों के तहत करने और निष्पादित किए गए कमांड के ACID गुणों को बनाए रखने के लिए आवश्यक है। टाइमआउट SQL सर्वर से संबंधित नहीं है, यह .NET क्लाइंट और कमांडटाइमआउट प्रॉपर्टी द्वारा सेट किया गया है, इसलिए वह भी कोड से संबंधित है और SQL इंजन से संबंधित व्यवहार नहीं है। यह उसी तरह की समस्या है जिसके बारे में मैंने अपनी एक्सटेंडेड इवेंट सीरीज़ में भी इस ब्लॉग पोस्ट में बात की थी:

• अनाथ लेनदेन को डीबग करने के लिए एकाधिक लक्ष्यों का उपयोग करना

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

.NET लेनदेन को समझना

यह सामान्य ज्ञान है कि SQL सर्वर किसी भी डेटा संशोधन को एक लेनदेन में लपेटता है जो स्वचालित रूप से प्रतिबद्ध है जब तक कि IMPLICIT_TRANSACTIONS सेट विकल्प एक सत्र के लिए चालू न हो। यह सत्यापित करने के बाद कि यह उनके कोड के किसी भी हिस्से के लिए चालू नहीं था, यह मान लेना बहुत सुरक्षित था कि एक सत्र के बाद शेष कोई भी लेन-देन स्लीपिंग था, उनके कोड के निष्पादन के दौरान कहीं खुले लेनदेन का परिणाम था। अब बस यह समझने की बात थी कि कब, कहां और सबसे महत्वपूर्ण बात यह है कि इसे तुरंत बंद क्यों नहीं किया जा रहा था। यह कुछ अलग परिदृश्यों में से एक की ओर जाता है जिसे हमें उनके एप्लिकेशन टियर कोड के अंदर देखना होगा:

• एक ऑपरेशन के आसपास TransactionScope () का उपयोग करने वाला एप्लिकेशन
• कनेक्शन पर SqlTransaction() को सूचीबद्ध करने वाला एप्लिकेशन
• ORM कोड किसी लेन-देन में कुछ कॉलों को आंतरिक रूप से लपेटता है जो प्रतिबद्ध नहीं किया जा रहा है

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

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

मुद्दे की जड़

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

स्लीपिंग स्थिति एक खुले लेनदेन के साथ होने जा रही है जिसमें ऑब्जेक्ट्स के .SaveEntity कॉल को पूरा करने और ऑब्जेक्ट्स के लिए कोड जेनरेट कोड में अंतिम प्रतिबद्धता के बीच ताले होते हैं। यदि VM/App सर्वर दबाव या लोड में है, तो इसमें देरी हो सकती है और अवरोधन के साथ समस्याएँ हो सकती हैं, लेकिन समस्या SQL सर्वर में नहीं है, यह ठीक वही कर रहा है जो इसे लेन-देन के दायरे में करना चाहिए। समस्या अंततः आवेदन पक्ष प्रतिबद्ध बिंदु को संसाधित करने में देरी का परिणाम है। स्टेटमेंट के समय को पूरा करना और RPC ने एक्सटेंडेड इवेंट्स के इवेंट्स को डेटाबेस_ट्रांसक्शन_एंड इवेंट टाइमिंग के साथ पूरा किया, यह दर्शाता है कि ओपन कनेक्शन पर ट्रांजेक्शन को बंद करने वाले ऐप टियर से राउंड-ट्रिप देरी। इस मामले में SQL सर्वर में देखा जा रहा सब कुछ एक अतिभारित अनुप्रयोग सर्वर और एक अतिभारित VM होस्ट का शिकार है। एनएलबी या हार्डवेयर लोड संतुलित कॉन्फ़िगरेशन में सर्वरों में एप्लिकेशन लोड को स्थानांतरित/विभाजित करना, ऐसे होस्ट का उपयोग करना जो सीपीयू उपयोग पर अधिक प्रतिबद्ध नहीं हैं, लेनदेन की तत्काल प्रतिबद्धता को तुरंत बहाल कर देंगे और SQL सर्वर में स्लीपिंग सेशन लॉक को हटा देंगे।

फिर भी एक पर्यावरणीय मुद्दे का एक और उदाहरण जो रन-ऑफ-द-मिल ब्लॉकिंग समस्या की तरह दिखता है। यह हमेशा जांच करने के लिए भुगतान करता है कि अवरुद्ध धागा अपने ताले को जल्दी से जारी करने में सक्षम क्यों नहीं है।