हम व्यवसाय के मामले को सुलझाने के लिए अपने परिवेश में सेवा देने वाले ब्रोकर को काम पर लाने की कोशिश कर रहे हैं। मुझे नहीं पता कि क्या संदेश शीर्षक एक अच्छा है, लेकिन मेरा सवाल नीचे है। लेकिन यह एक अच्छा सवाल नहीं हो सकता है, इसलिए इसके बाद हम क्या कर रहे हैं और मुझे लगता है कि यह सही सवाल है।
बातचीत समाप्त करने से पहले कितने संदेशों को वार्तालाप पर भेजा जाना चाहिए?
हम परिणाम तालिका को अतुल्यकालिक रूप से अपडेट करने के लिए सर्विस ब्रोकर का उपयोग करना चाहते हैं। परिणाम तालिका चपटा और तेज है। हमारे पास बेस टेबल पर ट्रिगर है जो उनकी टेबल और प्राथमिक कुंजी के साथ एक संदेश भेजते हैं। हमारी तीन कतारें हैं:
- कम विलंबता - उद्देश्य प्रक्रिया के लिए 15 सेकंड है। यह उन वस्तुओं को संभालता है जो किसी विशिष्ट वस्तु से संबंधित परिवर्तन करते हैं।
- बल्क कतार - उद्देश्य प्रक्रिया के लिए 5 मिनट है। यह तब बदलता है जब कुछ परिवर्तन वस्तुओं के कई सौ (या हजारों) को प्रभावित करता है। यह उन वस्तुओं की सूची को तोड़ देता है जो प्रभावित थीं और उन्हें डिफर्ड लो लेटेंसी क्यू को खिलाती हैं
- आस्थगित कम विलंबता - उद्देश्य प्रक्रिया के लिए 30 मिनट का है। यह आइटम संसाधित करता है लेकिन केवल बल्क कतार से।
मूल रूप से, यदि ग्राहक की जानकारी अपडेट होती है; यह कई उत्पादों को प्रभावित करता है ताकि धीमी प्रसंस्करण के लिए थोक कतार में भेजा जाए। हालाँकि, यदि कोई उत्पाद अद्यतन हो जाता है, तो उसे निम्न विलंबता कतार में भेज दिया जाता है।
हम रेमुस रुसानू के ब्लॉग http://rusanu.com/2007/04/25/reuse-conversations/ के समान बातचीत का पुन: उपयोग करते हैं , इस अपवाद के साथ कि हम इसे प्राथमिक कुंजी के मापांक के आधार पर करते हैं। प्राथमिक कुंजी के डी-डुप्लीकेशन में सहायता करने का यह साइड इफेक्ट है।
इसलिए, हम बातचीत का पुनः उपयोग कर रहे हैं और हमारे दिशानिर्देशों के भीतर हैं। दो थ्रेड्स के साथ, मैं 125 संदेशों / सेकंड (कई हजार संदेशों के कृत्रिम ड्रॉप) के माध्यम से जलने में सक्षम था, जो उत्पादन (प्लस 15 संदेश / सेकंड) को बनाए रखने में सक्षम से अधिक है।
हालाँकि, जो समस्या हम अनुभव कर रहे हैं, वह यह है कि समय की अवधि के बाद, ~ 4 घंटे या 120K संदेश, हमने ब्लॉक और उच्च विवाद को सिससेंड और कतार तालिका पर देखना शुरू कर दिया। ताले LCK_M_U हैं और प्रमुख ताले हैं। कभी-कभी हेस विशिष्ट कतार तालिका (कतार_) के लिए सिससेंडेंड और अन्याइमों का समाधान करता है।
हमारे पास एक ऐसी प्रक्रिया है जो पहले से ही 24 घंटे या 30 मिनट की निष्क्रियता के बाद बातचीत को समाप्त कर देगी, इसलिए हम बातचीत से पहले साइकिल चलाने से पहले समय बढ़ा सकते हैं।
हम SQL 2016 एंटरप्राइज़ (13.0.4001.0) का उपयोग कर रहे हैं
- ट्रिगर आग (कम विलंबता या बल्क को भेजें)
- वार्तालाप हैंडल देखें या बनाएं।
- मेसेज भेजें
- कतार सक्रिय प्रक्रिया
- परिणाम तालिका अपडेट करें
क्लीनअप प्रक्रिया हर 10 मिनट में यह देखने के लिए चलती है कि क्या कोई निष्क्रिय वार्तालाप है। यदि यह उन्हें लगातार तीन बार से अधिक पाता है, तो यह इसे निष्क्रिय के रूप में चिह्नित करता है और बातचीत समाप्त करता है।
कृपया मुझे बताएं कि क्या कोई अतिरिक्त विवरण है जो फायदेमंद हो सकता है। मुझे सेवा ब्रोकर के साथ बहुत अनुभव नहीं है, इसलिए मुझे नहीं पता कि हमारे संदेश / सेकंड कम, उच्च या उदासीन हैं या नहीं।
अपडेट करें
इसलिए हमने आज फिर से कोशिश की और उसी समस्या का सामना किया। हमने वार्तालाप को 2 घंटे में बदल दिया और इसका कोई प्रभाव नहीं पड़ा। तो हमने फिर 150 चाल को लागू किया; जिसका एक ही मुद्दा था।
SENSdesend की प्रतीक्षा में, SEND CONVERSATION पर प्रतीक्षा कर रहा है। क्या किसी के पास कोई और विचार है?
अद्यतन २
हमने आज अधिक समय तक परीक्षण चलाया और 17 मिनट के नमूने में से एक के लिए, हमने 4 वार्तालाप हैंडल पर 41K संदेशों को संसाधित किया। सिसेंडेंड और कतार की मेज पर ताले बहुत अधिक हो गए और हम उसे रोकने से पहले पीछे पड़ने लगे। हमें लगता है कि कोई समस्या प्रसंस्करण संदेश नहीं है, कतार में प्रवेश करने वाली चीजों के बिना, हम उन्हें खींच सकते हैं और उन्हें कम से कम 5x उस गति से संसाधित कर सकते हैं। संदेश जोड़ने के आधार पर हमारी गति सीमित प्रतीत होती है।
बाद के परीक्षण में, हमने उन ट्रिगर्स में से एक को हटा दिया जिसमें 80% संदेशों का हिसाब था। इतना कम भार होने के बावजूद, हमने वही इंतजार करना शुरू कर दिया।
अद्यतन 3
धन्यवाद, आपकी सलाह के लिए रेमुस (और इस विषय पर इस तरह के उत्कृष्ट ब्लॉग लेखों को पोस्ट करने के लिए धन्यवाद, वे इस बिंदु पर पहुंचने में महत्वपूर्ण भूमिका निभाई)।
हमने इसे आज फिर से चलाया और बेहतर किया (जैसा कि हम वेट देखने से पहले गए थे और इससे पहले कि यह हमें अपंग कर देता है)। तो, विवरण।
हमने बदल दिया: * प्रति थ्रेड 1: 2 से 1: 2 तक बनाए रखा वार्तालापों की संख्या में वृद्धि। मूल रूप से, हमारे पास 4 थ्रेड्स के लिए 8 वार्तालाप हैंडल थे।
- कम, बड़े संदेशों में समेकित करने के लिए बल्क कतार (क्योंकि एक आने वाला संदेश सैकड़ों आउटगोइंग संदेशों का मतलब हो सकता है) को समेकित करता है।
इस प्रयास के बारे में नोट्स:
लक्ष्य कतार सक्रियण प्रक्रिया को अक्षम करना। अवरुद्ध करने में कोई बदलाव नहीं (हमने 5 मिनट इंतजार किया) और संदेश sys.transmission_queues को भेजे गए।
मॉनिटरिंग sys.conversation_endpoints। यह संख्या बहुत जल्दी से 0 13K से चली गई, और फिर ~ 5 घंटे के बाद लगभग 25K तक समाप्त होने वाले पूरे दिन में और अधिक धीरे-धीरे बढ़ी। 16K +/- तक पहुंचने तक अवरोध उत्पन्न नहीं हुआ
मैं DAC में गया और कबीरों के लिए DBREINDEX कमांड चलाए, हालांकि एक क्वेरी से, भूत का रिकॉर्ड कभी भी 200 या उससे ऊपर नहीं आया, इससे पहले कि सफाई साथ आए और गिनती 0 पर गिरा दी।
जब मैंने परीक्षण समाप्त किया तब sysdesend और sysdercv की समान संख्या 24,932 थी।
हमने 5 घंटों में ~ 310K संदेशों को संसाधित किया।
हम चीजों को गिराने से पहले इतने लंबे समय तक चले गए कि मुझे वास्तव में लगा कि हम इसे इस बार बनाएंगे। कल हम वायर के माध्यम से संदेश भेजने की कोशिश करेंगे।
sys.conversation_endpointsकि परीक्षण के दौरान पंक्तियों की संख्या क्या है (निरंतर या बढ़ती जा रही है, और अवरुद्ध होने पर यह कितना बड़ा है)। 2) जब ब्लॉकिंग होती है, तो लक्ष्य कतार को अक्षम करने से SEND ब्लॉकिंग में फर्क पड़ता है (कतार को अक्षम करने के लिए SEND को sys.transmission_queue पर रूट करना चाहिए)। और 3) तार पर जाने के लिए संदेश भेजने के लिए, यहां तक कि स्थानीय रूप से (एसएसबी समापन बिंदु, मार्गों को जोड़ने के लिए) लंबे समय में व्यवहार में परिवर्तन करता है
ALTER QUEUE ... REBUILDएक बार ब्लॉकिंग शुरू होने से फर्क पड़ता है?
we started seeing blocks and high contention on sysdesend and the queue table.-> प्रतीक्षा प्रकार क्या है -PAGELATCH_EX/SH and WRITELOG? क्या आपने 150 चाल का उपयोग किया है ? यदि सिस्टम टेबल आपके कंटेस्टेंट पॉइंट हैं, तो 150 ट्रिक अत्यधिक उपयोगी होगी।