निष्पादित करने में लंबा समय लगने वाले sp_reset_connection के संभावित कारण क्या हैं?


9

sp_reset_connectionSQL Server Profiler के माध्यम से देखे जाने के लिए सिस्टम संग्रहीत प्रक्रिया को निष्पादित करने में कुछ मिलीसेकंड से अधिक समय क्यों लगेगा ?

मैंने SQL सर्वर प्रोफाइलर का उपयोग करके एक उत्पादन प्रणाली से एक सरल ट्रेस लिया और फिर इसका विश्लेषण करने के लिए SqlNexus का उपयोग किया। SqlNexus इंगित करता है कि sp_reset_connection में उच्चतम संचयी अवधि है - कुल ट्रेस का 33%। देखी गई अवधि 0-4 सेकंड (12 से 6,833,270 माइक्रोसेकंड) तक होती है, लेकिन औसत 0.956 से।

मैं समझता हूं कि जब पूल कनेक्शन का पुन: उपयोग किया जाता है, तो sp_reset_connection कहा जा रहा है। मैंने एक सुझाव देखा है कि यह बाहरी निशान के कारण हो सकता है , लेकिन ऐसा नहीं लगता है।

मैंने पढ़ा है कि जब स्प्रो कहा जाता है तो सर्वर क्या कर रहा है, लेकिन मुझे विश्वास नहीं है कि उनमें से कोई भी इस मामले में समस्याग्रस्त होगा - कोड खुले लेनदेन या विशाल अस्थायी तालिकाओं को नहीं छोड़ रहा है जिन्हें साफ करने की आवश्यकता होगी।

मैंने /server/199974/sp-reset-connection-taking-a-long-time-to-run को भी देखा लेकिन यह मददगार नहीं था।

EDIT (2013-12-23): सभी मामलों में, पढ़ता और लिखता है 0 और CPU लगभग हमेशा 0 (गैर-शून्य CPU के केवल दो उदाहरण, दोनों 16ms पर)।


उस घटना को पढ़ने और लिखने के लिए आप किस तरह के मूल्यों को देख रहे हैं?
मार्टिन स्मिथ

क्या आप इस बारे में अधिक जानकारी प्रदान कर सकते हैं कि आप किस प्रकार के प्रश्न चलाते हैं। विशेष रूप से दिलचस्प विवरण, जैसे लंबे या जटिल लेनदेन, एक्सएमएल प्रसंस्करण, अस्थायी तालिकाओं?
एडवर्ड डॉर्टलैंड

@ मर्टिन पढ़ता है और लिखता है 0. अद्यतन सवाल। (सप्ताहांत में डेटा तक पहुंच नहीं थी।)
समग्र डेवलपर

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

@HolisticDeveloper - मैंने एक खुला लेनदेन छोड़ने के साथ प्रयोग किया और गैर शून्य रीड्स देख सकता है और लिखता है इसलिए सहमत हैं कि यह तब ऐसा नहीं दिखता है। क्या यह स्थिति कमोबेश स्थायी है? यदि ऐसा है तो मैं एक विस्तारित ईवेंट ट्रेस कैप्चरिंग चलाऊंगा RPC:Starting, RPC:Completedऔर थोड़े समय के लिए प्रतीक्षा के प्रकार का पता लगाऊंगा, फिर डेटा के माध्यम से देख सकता हूं कि उस समय के दौरान किस प्रकार के स्पिड्स का सामना हो रहा है।
मार्टिन स्मिथ

जवाबों:


9

अंत में अधिक विस्तृत उत्तर लिखने के लिए कुछ समय मिला।

आम तौर पर तीन मुख्य कारण होते हैं जैसे एक सरल प्रक्रिया sp_reset_connectionको चलने में लंबा समय लगेगा।

  1. आप CPU संसाधनों की प्रतीक्षा कर रहे हैं
  2. आप कहीं लॉक पर अवरुद्ध हैं (शायद डीएमएल या प्रतिस्पर्धी लेनदेन के परिणामस्वरूप)
  3. आपका नेटवर्क धीमा है और परिणाम को क्लाइंट को वापस करने में लंबा समय लगता है

विज्ञापन 1) यदि आप सीपीयू संसाधनों की प्रतीक्षा कर रहे हैं, तो इसे सिग्नल प्रतीक्षा के रूप में दिखाना चाहिए। यदि यह समस्या है तो निदान करने के बारे में अपने प्रश्न पर मेरी टिप्पणी देखें

विज्ञापन 2) यदि आप किसी लॉक का इंतजार कर रहे हैं, तो इसके दो स्नैपशॉट की तुलना करके सबसे अच्छा निदान किया जाता है sys.dm_os_wait_stats। यह करने के लिए इस लेख को देखें:

यदि आप LCK_ [कुछ] के लिए लंबे समय तक प्रतीक्षा करते हैं, तो sys.dm_tran_locksयह ट्रैक करने के लिए क्वेरी करें कि किन वस्तुओं को लॉक किया जा रहा है। आपके मामले में, मैं SCH- [कुछ] के कुछ रूपों को देखने की उम्मीद करूंगा।

विज्ञापन 3) सबसे पहले OLEDB और ASYNC_NETWORK_IO के लिए नेटवर्क समस्याओं के निदान का सबसे आसान तरीका चरण 2 में प्रतीक्षा करता है (यदि आप नेटवर्क के लिए लंबे समय तक प्रतीक्षा करते हैं, तो उनमें से एक शो होता है)। यदि वे प्रतीक्षा अधिक हैं, xperf -on latencyतो अपनी विलंबता की जांच करने के लिए नेटमोन या वायरशार्क जैसे नेटवर्क निगरानी कार्यक्रम का उपयोग करें। यदि नेटवर्क धीमा दिखता है, तो यह कॉलिंग एप्लिकेशन सर्वर द्वारा रिसाईकल किए जा रहे कनेक्शन के लिए तेजी से प्रतिक्रिया नहीं देने के कारण भी हो सकता है।


मैंने अभी तक इस समस्या को नहीं देखा है इसलिए मैं इस बिंदु पर और निदान करने के लिए दिए गए उत्तर का उपयोग नहीं कर सकता। हालाँकि, मैं SQL सर्वर प्रदर्शन विशेषज्ञ के रूप में आपकी प्रतिष्ठा के आधार पर उत्तर स्वीकार कर रहा हूं।
होलिस्टिक डेवलपर

2

मैं बस एक बग के लिए एक KB लेख आया था जो इस मुद्दे से संबंधित हो सकता है। में सुधार: प्रदर्शन समस्याओं जब एसक्यूएल सर्वर में डेटाबेस ताला गतिविधि वृद्धि होती है (KB 2,926,217), लक्षणों में से एक का वर्णन किया है कि sp_reset_connectionएक लंबे समय के पूरा करने के लिए लग सकता है। हॉटफ़िक्स को निम्न अपडेट में शामिल किया गया है:

  • SQL Server 2008 SP3 के लिए संचयी अद्यतन 17
  • SQL Server 2008 R2 SP2 के लिए संचयी अद्यतन 13
  • SQL Server 2012 SP1 के लिए संचयी अद्यतन 9
  • SQL Server 2014 के लिए संचयी अद्यतन 1

जिस सर्वर पर मैंने इस व्यवहार को देखा, वह संचयी अद्यतन 5 के साथ SQL Server 2008 SP3 चला रहा था, इसलिए यह संभव है कि यह इस बग का अनुभव कर रहा था। मैंने अभी तक संचयी अद्यतन की कोशिश नहीं की है (समस्या हर समय पुनरावृत्ति नहीं करती है) इसलिए मैं यह सत्यापित नहीं कर सकता कि यह ठीक होगा या नहीं। हालाँकि, मैं यह जानकारी प्रदान करना चाहता था कि किसी को भी समान लक्षण हों।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.