SQL ट्रेस बनाम विस्तारित ईवेंट के "ऑब्जर्वर ओवरहेड" को मापना

SQL सर्वर सर्वर के विरुद्ध निष्पादित कार्यभार के बारे में नैदानिक ​​और समस्या निवारण डेटा एकत्र करने के दो तरीके प्रदान करता है:SQL ट्रेस और विस्तारित ईवेंट। SQL सर्वर 2012 में शुरू, विस्तारित ईवेंट कार्यान्वयन SQL ट्रेस को तुलनीय डेटा संग्रह क्षमता प्रदान करता है और इन दो सुविधाओं द्वारा किए गए ओवरहेड की तुलना के लिए उपयोग किया जा सकता है। इस लेख में हम "ऑब्जर्वर ओवरहेड" की तुलना करने पर एक नज़र डालेंगे जो कि विभिन्न कॉन्फ़िगरेशन में SQL ट्रेस और विस्तारित ईवेंट का उपयोग करते समय होता है ताकि प्रदर्शन प्रभाव का निर्धारण किया जा सके जो डेटा संग्रह एक रीप्ले वर्कलोड के उपयोग के माध्यम से हमारे कार्यभार पर हो सकता है। कैप्चर और वितरित रीप्ले।

परीक्षा परिवेश

परीक्षण वातावरण में छह वर्चुअल मशीन, एक डोमेन नियंत्रक, एक SQL सर्वर 2012 एंटरप्राइज़ संस्करण सर्वर और चार क्लाइंट सर्वर शामिल हैं, जिन पर वितरित रीप्ले क्लाइंट सेवा स्थापित है। इस आलेख के लिए अलग-अलग होस्ट कॉन्फ़िगरेशन का परीक्षण किया गया था और समान परिणाम तीन अलग-अलग कॉन्फ़िगरेशन से प्राप्त हुए थे जिन्हें प्रभाव के अनुपात के आधार पर परीक्षण किया गया था। SQL सर्वर एंटरप्राइज़ संस्करण सर्वर 4 vCPU और 4GB RAM के साथ कॉन्फ़िगर किया गया है। शेष पांच सर्वर 1 वीसीपीयू और 1 जीबी रैम के साथ कॉन्फ़िगर किए गए हैं। वितरित रीप्ले नियंत्रक सेवा SQL Server 2012 एंटरप्राइज़ संस्करण सर्वर पर चलाई गई थी क्योंकि इसे फिर से चलाने के लिए एक से अधिक क्लाइंट का उपयोग करने के लिए एंटरप्राइज़ लाइसेंस की आवश्यकता होती है।

कार्यभार का परीक्षण करें

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

फिर से चलाएं कॉन्फ़िगरेशन

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

<?xml version="1.0" encoding="utf-8"?>
<Options>
  <ReplayOptions>
    <Server>SQL2K12-SVR1</Server>
    <SequencingMode>stress</SequencingMode>
    <ConnectTimeScale>1</ConnectTimeScale>
    <ThinkTimeScale>1</ThinkTimeScale>
    <HealthmonInterval>60</HealthmonInterval>
    <QueryTimeout>3600</QueryTimeout>
    <ThreadsPerClient>255</ThreadsPerClient>
    <EnableConnectionPooling>Yes</EnableConnectionPooling>
    <StressScaleGranularity>spid</StressScaleGranularity>
  </ReplayOptions>
  <OutputOptions>
    <ResultTrace>
      <RecordRowCount>No</RecordRowCount>
      <RecordResultSet>No</RecordResultSet>
    </ResultTrace>
  </OutputOptions>
</Options>

प्रत्येक रीप्ले ऑपरेशन के दौरान, निम्नलिखित काउंटरों के लिए पांच सेकंड के अंतराल में प्रदर्शन काउंटर एकत्र किए गए थे:

• प्रोसेसर\% प्रोसेसर समय\_कुल
• एसक्यूएल सर्वर\एसक्यूएल सांख्यिकी\बैच अनुरोध/सेकंड

इन काउंटरों का उपयोग समग्र सर्वर लोड और तुलना के लिए प्रत्येक परीक्षण की थ्रूपुट विशेषताओं को मापने के लिए किया जाएगा।

कॉन्फ़िगरेशन का परीक्षण करें

डिस्ट्रीब्यूटेड रीप्ले के साथ कुल सात अलग-अलग कॉन्फ़िगरेशन का परीक्षण किया गया:

• आधारभूत
• सर्वर-साइड ट्रेस
• सर्वर पर प्रोफाइलर
• दूरस्थ रूप से प्रोफाइलर
• इवेंट_फाइल तक विस्तारित ईवेंट
• इवेंट को रिंग_बफ़र तक बढ़ाया
• इवेंट_स्ट्रीम तक विस्तारित ईवेंट

प्रत्येक परीक्षण को यह सुनिश्चित करने के लिए तीन बार दोहराया गया था कि परिणाम विभिन्न परीक्षणों में सुसंगत थे और तुलना के लिए परिणामों का औसत सेट प्रदान करते थे। प्रारंभिक बेसलाइन परीक्षणों के लिए, SQL सर्वर इंस्टेंस के लिए कोई अतिरिक्त डेटा संग्रह कॉन्फ़िगर नहीं किया गया था, लेकिन SQL सर्वर 2012 के साथ शिप करने वाले डिफ़ॉल्ट डेटा संग्रह को सक्षम छोड़ दिया गया था:डिफ़ॉल्ट ट्रेस और system_health ईवेंट सत्र। यह अधिकांश SQL सर्वरों के सामान्य विन्यास को दर्शाता है, क्योंकि आमतौर पर यह अनुशंसा नहीं की जाती है कि डेटाबेस प्रशासकों को उनके द्वारा प्रदान किए जाने वाले लाभों के कारण डिफ़ॉल्ट ट्रेस या system_health सत्र को अक्षम कर दिया जाए। इस परीक्षण का उपयोग उन परीक्षणों की तुलना के लिए समग्र आधार रेखा निर्धारित करने के लिए किया गया था जहां अतिरिक्त डेटा संग्रह किया जा रहा था। शेष परीक्षण TSQL_SPs टेम्पलेट पर आधारित होते हैं जो SQL सर्वर प्रोफाइलर के साथ शिप करता है और निम्नलिखित घटनाओं को एकत्रित करता है:

• सुरक्षा ऑडिट\ऑडिट लॉगिन
• सुरक्षा ऑडिट\ऑडिट लॉगआउट
• सत्र\मौजूदा कनेक्शन
• संग्रहीत प्रक्रियाएं\RPC:प्रारंभ
• संग्रहीत प्रक्रियाएं\SP:पूरा हो गया
• संग्रहीत प्रक्रियाएं\SP:प्रारंभ
• संग्रहीत प्रक्रियाएं\SP:StmtStarting
• टीएसक्यूएल\एसक्यूएल:बैचस्टार्टिंग

इस टेम्प्लेट का चयन परीक्षणों के लिए उपयोग किए गए कार्यभार के आधार पर किया गया था, जो कि मुख्य रूप से SQL बैच हैं जिन्हें SQL:BatchStarting द्वारा कैप्चर किया जाता है। ईवेंट, और फिर hierarchyid . के विभिन्न तरीकों का उपयोग करते हुए कई ईवेंट , जो SP:Starting . द्वारा कैप्चर किए जाते हैं , SP:StmtStarting , और SP:Completed आयोजन। SQL सर्वर प्रोफाइलर में निर्यात कार्यक्षमता का उपयोग करके टेम्पलेट से एक सर्वर-साइड ट्रेस स्क्रिप्ट उत्पन्न की गई थी, और स्क्रिप्ट में किए गए एकमात्र परिवर्तन maxfilesize सेट करना था। 500MB के लिए पैरामीटर, ट्रेस फ़ाइल रोलओवर सक्षम करें, और एक फ़ाइल नाम प्रदान करें जिसमें ट्रेस लिखा गया था।

तीसरे और चौथे परीक्षणों ने SQL सर्वर प्रोफाइलर का उपयोग सर्वर-साइड ट्रेस के समान घटनाओं को एकत्र करने के लिए किया ताकि प्रोफाइलर एप्लिकेशन का उपयोग करके ट्रेसिंग के प्रदर्शन ओवरहेड को मापने के लिए किया जा सके। ये परीक्षण SQL सर्वर पर स्थानीय रूप से SQL Profiler का उपयोग करके और एक अलग क्लाइंट से दूरस्थ रूप से चलाए गए थे ताकि यह पता लगाया जा सके कि Profiler के स्थानीय या दूरस्थ रूप से चलने से ओवरहेड में कोई अंतर था या नहीं।

विस्तारित ईवेंट का उपयोग करने वाले अंतिम परीक्षणों ने SQL सर्वर 2012 के लिए मेरे ट्रेस टू एक्सटेंडेड ईवेंट रूपांतरण स्क्रिप्ट का उपयोग करके बनाए गए ईवेंट सत्र के आधार पर समान ईवेंट और समान कॉलम एकत्र किए। परीक्षणों में Event_file, ring_buffer, और SQL सर्वर में नए स्ट्रीमिंग प्रदाता का मूल्यांकन शामिल था। 2012 अलग से ओवरहेड निर्धारित करने के लिए जो प्रत्येक लक्ष्य सर्वर के प्रदर्शन पर लगा सकता है। इसके अतिरिक्त, ईवेंट सत्र को डिफ़ॉल्ट मेमोरी बफर विकल्पों के साथ कॉन्फ़िगर किया गया था, लेकिन इसे NO_EVENT_LOSS निर्दिष्ट करने के लिए बदल दिया गया था। EVENT_RETENTION_MODE . के लिए एक फ़ाइल के साथ सर्वर-साइड ट्रेस के व्यवहार से मेल खाने के लिए Event_file और ring_buffer परीक्षणों के लिए विकल्प, जो किसी भी घटना के नुकसान की गारंटी भी नहीं देता है।

परिणाम

एक अपवाद के साथ, परीक्षणों के परिणाम आश्चर्यजनक नहीं थे। बेसलाइन परीक्षण तेरह मिनट और पैंतीस सेकंड में रीप्ले कार्यभार को पूरा करने में सक्षम था, और परीक्षणों के दौरान प्रति सेकंड औसतन 2345 बैच अनुरोध करता था। सर्वर-साइड ट्रेस चलने के साथ, रीप्ले ऑपरेशन 16 मिनट और 40 सेकंड में पूरा हुआ, जो कि प्रदर्शन में 18.1% की गिरावट है। Profiler Traces का प्रदर्शन सबसे खराब था, और जब Profiler को सर्वर पर स्थानीय रूप से चलाया जाता था, तब 149 मिनट की आवश्यकता होती थी, और जब Profiler को दूरस्थ रूप से चलाया जाता था, तो 123 मिनट और 20 सेकंड की आवश्यकता होती थी, क्रमशः प्रदर्शन में 90.8% और 87.6% की गिरावट होती थी। विस्तारित ईवेंट परीक्षण सर्वश्रेष्ठ प्रदर्शन करने वाले थे, जिसमें इवेंट_फाइल के लिए 15 मिनट और 15 सेकंड और रिंग_बफ़र लक्ष्य के लिए 15 मिनट और 40 सेकंड का समय लगा, जिसके परिणामस्वरूप प्रदर्शन में 10.4% और 11.6% गिरावट आई। सभी परीक्षणों के औसत परिणाम तालिका 1 में प्रदर्शित किए गए हैं और चित्र 2 में चार्ट किए गए हैं:

तालिका 1 - सभी परीक्षणों के औसत परिणाम

चित्र 2 - परिणामों का चार्ट

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

चित्र 3 - परिणामों में ज़ूम किया गया

इसके लिए स्पष्टीकरण SQL सर्वर 2012 में नए विस्तारित ईवेंट स्ट्रीमिंग लक्ष्य के डिज़ाइन में पाया गया है। यदि Event_stream के लिए आंतरिक मेमोरी बफ़र्स भरते हैं और क्लाइंट एप्लिकेशन द्वारा पर्याप्त तेज़ी से खपत नहीं होते हैं, तो डेटाबेस इंजन एक डिस्कनेक्ट को बाध्य करेगा event_stream सर्वर के प्रदर्शन को गंभीर रूप से प्रभावित करने से रोकने के लिए। यह SQL सर्वर 2012 प्रबंधन स्टूडियो में चित्र 4 में त्रुटि के समान त्रुटि उत्पन्न करता है:

चित्र 4 - event_stream सर्वर द्वारा डिस्कनेक्ट किया गया

निष्कर्ष

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

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