2013-09-06 7 views
13

मेरे पास एक साइट है जो एक सफेद लेबल (उसी साइट के एकाधिक संस्करण) है जिसे मैंने हाल ही में लॉन्च किया है। अभी तक बहुत अधिक ट्रैफिक नहीं है - मुख्य रूप से बॉट्स लेकिन प्रति दिन शायद 800 उपयोगकर्ता। यह गैर-एज़ूर सर्वर पर स्थित एक व्यवस्थापक पैनल के अतिरिक्त Azure डेटाबेस के साथ Azure पर होस्ट किया जाता है। दोनों साइटें एक ही Azure डेटाबेस से कनेक्ट हैं। डेटा की प्रक्रिया करने के लिए कुछ कार्यकर्ता भूमिकाएं चल रही हैं - 99% जब वे कुछ भी नहीं कर रहे हैं, लेकिन वे नियमित रूप से जांच करते हैं।Azure SQL डेटाबेस कनेक्टिविटी मुद्दे - बहुत सारे कनेक्शन?

मैं हमेशा इस तरह के रूप यादृच्छिक त्रुटियों जो कुछ ही सेकंड पिछले और उसे फिर से ठीक है, अनुभव किया है:

A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

आज सुबह, तथापि, हम एक और अधिक गंभीर समस्या थी। यह शुरू कर दिया साथ:

System.ComponentModel.Win32Exception: An existing connection was forcibly closed by the remote host

यह जबकि बॉट (गूगल, Baidu, AhrefsBot & Wiseguys.nl) साइट अनुक्रमणिका बना रहे थे हुई। मुझे इनमें से एक या अधिक त्रुटियां मिलीं। तब मुझे मिला:

System.Data.SqlClient.SqlException: The service has encountered an error processing your request. Please try again. Error code 40143. A severe error occurred on the current command. The results, if any, should be discarded.

यह एक निष्पादक चरण चरण के दौरान था।

10 मिनट बाद, वास्तविक समस्या आई - जिसका मतलब था कि कोई भी व्यवस्थापक इंटरफ़ेस में लॉग इन नहीं कर सकता था, लेकिन जब मैंने परीक्षण किया तो Azure होस्ट की गई वेबसाइट ठीक दिखाई दी, हालांकि बॉट अभी भी त्रुटियां ला रहे थे। समस्या थी:

System.ComponentModel.Win32Exception: The wait operation timed out

यह यादृच्छिक कनेक्शन के साथ लगभग एक घंटे तक चालू और बंद रहता है। तब मैं एक और समस्या मारा:

System.Data.SqlClient.SqlException: Resource ID : 1. The request limit for the database is 180 and has been reached. See ' http://go.microsoft.com/fwlink/?LinkId=267637 ' for assistance.

यह चालू और बंद हुआ पिछले एक घंटे के लिए - मुख्य रूप से कार्यकर्ता की भूमिका निभाने के लिए। मैं तो पता लगाने के लिए क्या इन अनुरोधों के सभी अप ले रहा था की कोशिश की और मैं इस आदेश मिला:

SELECT * FROM sys.dm_exec_requests

यह केवल 1 या 2 अनुरोध लौटे जब मैं इसे अधिक से अधिक चल रहा था।

तो मेरे प्रश्न हैं: 1) क्या कोई और अपेक्षाकृत नियमित (एक बार, दिन में दो बार) अनुभव करता है Azure पर होस्ट किए गए सर्वर से एक अस्थायी डिस्कनेक्ट? 2) क्या उपर्युक्त घटनाओं की सूची एक विशेष समस्या का संकेत देती है? यह सब तब हुआ जब बहुत से व्यवस्थापक एक साथ लॉग इन कर रहे थे। 3) 180 सीमा संदेश प्राप्त करते समय डेटाबेस में अनुरोधों की संख्या को बेहतर तरीके से डीबग कैसे कर सकता हूं?

अग्रिम धन्यवाद।

उत्तर

6

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

एज़ूर में मूल्य निर्धारण स्तर हैं जिनमें प्रदर्शन में काफी नाटकीय अंतर हैं। इसे प्राप्त करने के लिए, वे बहुत सारे प्रदर्शन मीट्रिक को थ्रॉटल करते हैं, उदा। सीपीयू पावर, अनुरोध प्रति मिनट, आदि

इसका मतलब है कि यदि आप अपने स्तर पर दबाव डाल रहे हैं, तो आपके अनुरोधों को कतारबद्ध करना शुरू हो जाएगा क्योंकि CPU की शक्ति/अनुरोधों की मात्रा प्रक्रिया के लिए बहुत अधिक है। इसका परिणाम टाइमआउट में होता है और फिर अनुरोध सीमा बढ़ जाती है क्योंकि अनुरोध संसाधित होने की प्रतीक्षा करते हैं। आखिरकार, यह उस बिंदु तक पहुंच जाता है जहां डेटाबेस अनिवार्य रूप से नीचे चला जाता है।

मेरा अनुभव यह है कि निम्न डेटाबेस स्तर, जैसे कि S0 और S1, वास्तव में कम-संचालित हैं और इन्हें विकास या बहुत बुनियादी साइटों के अलावा किसी अन्य चीज़ के लिए उपयोग नहीं किया जाना चाहिए।

Azure पोर्टल में कुछ बेहतरीन टूल हैं जो आपको अपने डेटाबेस के साथ क्या चल रहा है, जैसे सीपीयू ग्राफ, इंडेक्स सलाहकार और क्वेरी प्रदर्शन अंतर्दृष्टि डीबग करने की अनुमति देता है।

0

ऐसा लगता है कि आप इस dm_exec_requests DMV को देखने में सही रास्ते पर हैं। मुझे संदेह है कि आपने इसे पहले ही देखा है, लेकिन 180 थ्रॉटल सीमा पर एक और अधिक जानकारी है जो documented here है और इसके लिए कुछ महत्वपूर्ण कारण बताती है।

यदि यह आपकी रूचि है तो हमारे पास Cotega नामक एक सेवा है जो आपके दोनों प्रश्नों के लिए उपयोगी हो सकती है। पहला यह है कि हम आपको अपने डीबी का विश्लेषण करने में मदद करने के लिए क्या हो रहा है यह दिखाने के लिए सभी कुंजी DMV's against your database चला सकते हैं और जब आप अपने throttling limits के करीब पहुंचना शुरू करते हैं तो हम आपको सूचित भी कर सकते हैं (ईमेल, एसएमएस)।

0

A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

और

System.ComponentModel.Win32Exception: An existing connection was forcibly closed by the remote host

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

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

संबंधित मुद्दे