Database
 sql >> डेटाबेस >  >> RDS >> Database

विस्तारित घटनाओं के साथ घटना हानि को समझना

मेरे सहयोगी, एरिन स्टेलेटो ने हाल ही में मुझसे एक प्रश्न पूछा कि विस्तारित ईवेंट के साथ ईवेंट हानि कहाँ और क्यों हो सकती है। यह सवाल किसी उस टिप्पणी का नतीजा था जो किसी ने उसके ब्लॉग पोस्ट पर की थी जिसमें दावा किया गया था कि showplan_xml घटनाओं को एक्सई प्रोफाइलर द्वारा या सर्वर से घटनाओं की "लाइव" स्ट्रीम के माध्यम से एकत्र नहीं किया जा सकता है। मुझे पता चला है कि यह सही नहीं है क्योंकि मैंने UI में ईवेंट जोड़कर और इसे लाइव डेटा देखकर उत्पादन कार्यभार के विरुद्ध post_query_execution_showplan ईवेंट का उपयोग करने के नकारात्मक प्रदर्शन प्रभावों को नियमित रूप से प्रदर्शित किया है, इसलिए इसने गहराई से चर्चा शुरू की इस बारे में कि कैसे और कब विस्तारित ईवेंट डेटा संग्रह के दौरान उत्पन्न किए गए ईवेंट को छोड़ देंगे।

इवेंट का आकार मायने रखता है

विस्तारित ईवेंट ईवेंट सत्र के लिए आंतरिक मेमोरी बफ़र स्थान को कॉन्फ़िगर करता है, जब इसे प्रारंभ में सर्वर पर प्रारंभ किया जाता है, और ईवेंट सत्र विकल्पों का कॉन्फ़िगरेशन निर्धारित करता है कि मेमोरी बफ़र्स कितने बड़े हैं, और अधिकतम आकार ईवेंट जिसे ईवेंट सत्र एकत्र कर सकता है। जबकि एक्सटेंडेड इवेंट्स द्वारा उत्पन्न अधिकांश ईवेंट बाइनरी प्रारूप में अपेक्षाकृत हल्के और छोटे होते हैं, विशिष्ट ईवेंट डेटा का एक बहुत बड़ा पेलोड उत्पन्न कर सकते हैं जिसे बफर करना पड़ता है। डिफ़ॉल्ट ईवेंट सत्र विकल्प के परिणामस्वरूप 1,441,587 बाइट आकार वाले ईवेंट रखने के लिए तीन आंतरिक मेमोरी बफ़र्स के साथ एक सत्र कॉन्फ़िगरेशन होता है। किसी ईवेंट सत्र के लिए मेमोरी बफ़र्स का आकार और संख्या sys.dm_xe_sessions DMV में पाया जा सकता है जबकि सत्र STATE=START सर्वर पर:

चुनें s.name, s.total_regular_buffers, s.regular_buffer_size, s.total_large_buffers, s.large_buffer_size, s.total_buffer_sizeFROM sys.dm_xe_session AS s;

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

घटना हानि को नियंत्रित करना

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

ईवेंट सत्र बनाएं [ताले] सर्वर पर जोड़ें ईवेंट sqlserver.lock_acquired, EVENT जोड़ें sqlserver.lock_releasedADD TARGET package0.event_file(SET filename=N'Locks',max_file_size=(5),max_rollover_files=(4)) साथ =4096 KB,MEMORY_PARTITION_MODE=NONE,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_EVENT_SIZE=0 KB);

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

अगर हम इस सत्र को शुरू करते हैं और फिर मेरे ब्लॉग पर उपलब्ध एडवेंचरवर्क्स बुक्स ऑनलाइन वर्कलोड जनरेटर को SQL सर्वर की आवृत्ति के खिलाफ चलाते हैं, तो सत्र तेजी से ईवेंट बनाना शुरू कर देगा और इवेंट_फाइल लक्ष्य पर बफर फ्लशिंग में देरी के कारण तेजी से ईवेंट छोड़ना शुरू हो जाएगा। जिसे कॉन्फ़िगर किया गया है। यदि ईवेंट सत्र विकल्प EVENT_RETENTION_MODE =ALLOW_SINGLE_EVENT_LOSS के साथ कॉन्फ़िगर किए गए हैं, तो ईवेंट सत्र द्वारा छोड़े गए ईवेंट की संख्या को sys.dm_xe_sessions DMV में ट्रैक किया जा सकता है। यदि ईवेंट सत्र को EVENT_RETENTION_MODE=ALLOW_MULTIPLE_EVENT_LOSS के साथ कॉन्फ़िगर किया गया है, तो ईवेंट के संपूर्ण मेमोरी बफ़र्स को छोड़ा जा सकता है और यह केवल यह गिनता है कि कितने बफ़र्स गिराए गए थे और प्रत्येक बफ़र में अलग-अलग ईवेंट की संख्या नहीं थी।

चुनें s.name, s.total_regular_buffers, s.regular_buffer_size, s.total_large_buffers, s.large_buffer_size, s.dropped_event_count, s.dropped_buffer_count, s.largest_event_dropped_sizePre_x ASesions; 

यहां, हम देख सकते हैं कि 100,521 घटनाओं को गिरा दिया गया था और एक घटना का सबसे बड़ा आकार जो गिराया गया था वह 176 बाइट्स था, जो हमारे नियमित बफर स्पेस के आकार से छोटा है, इसलिए हम सामान्य बफर मेमोरी स्पेस दबाव को मार रहे हैं। हालांकि, अगर हम एक इवेंट सेशन बनाते हैं जो शोप्लान इवेंट्स में से दो को इकट्ठा करता है (इस लेख को देखें कि यह प्रदर्शन को नकारात्मक रूप से प्रभावित क्यों करेगा और इसे प्रोडक्शन सर्वर पर नहीं किया जाना चाहिए), साथ ही बैच के शुरू होने और पूरा होने वाले इवेंट और कुछ बड़े उत्पन्न होते हैं। योजनाएँ, हम ईवेंट के आकार के कारण ईवेंट हानि को ट्रिगर कर सकते हैं।

सर्वर पर
ईवेंट सत्र बनाएं [ड्रॉप्सइवेंट] ईवेंट जोड़ें sqlserver.query_post_execution_showplan, ईवेंट जोड़ें 

यहां, हम देख सकते हैं कि सबसे बड़ा_इवेंट_ड्रॉप्ड_साइज़ हमारे रेगुलर_बफ़र_साइज़ से बड़ा है, इसलिए इसका मतलब है कि हमें अपने सेशन बफ़र्स के कॉन्फ़िगरेशन को बदलने की आवश्यकता है। यदि हम ईवेंट सत्र के लिए MAX_MEMORY बढ़ाते हैं, तो यह हमारे नियमित बफ़र्स के आकार को बढ़ा सकता है। डिफ़ॉल्ट मान केवल 4MB है, जो कि ऊपर दिखाया गया 1.4MB बफर आकार से आता है। यदि हम इसे इवेंट सत्र के लिए 64MB में बदलते हैं, तो Regular_buffer_size का आकार 22.4MB होगा जो हमारे 3.7MB गिराए गए ईवेंट को समायोजित करेगा। दूसरा विकल्प MAX_EVENT_SIZE विकल्प सेट करना है जो बड़े इवेंट के लिए big_buffer_size प्रदान करता है और सत्र के लिए दो से विभाजित होता है।

सर्वर पर
ईवेंट सत्र बनाएं [कलेक्ट्स इवेंट] इवेंट जोड़ें 

तो यहाँ हम 33.6MB आकार के साथ दो बड़े बफ़र्स देख सकते हैं और उसी योजना को चलाने के बाद फिर से कार्यभार उत्पन्न करने के बाद हमारे पास हमारे नए कलेक्ट्सइवेंट्स सत्र के लिए कोई ड्रॉप इवेंट नहीं है, लेकिन हमने डिफॉल्ट्स का उपयोग करके अपने ड्रॉप्सएवेन्ट्स सत्र के लिए गिराए गए ईवेंट को दोगुना कर दिया है।

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


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. एसक्यूएल सीटीई के बारे में आपको जो कुछ भी जानना है वह एक ही स्थान पर है

  2. Django की नई पोस्टग्रेज़ सुविधाओं के साथ मज़ा

  3. डेटाबेस ट्रिगर पसंद नहीं है? आप बस यह नहीं जानते कि उनके साथ कैसे काम करना है!

  4. TimescaleDB के लिए बैकअप प्रबंधन युक्तियाँ

  5. एसएसआईएस का उपयोग करके ईटीएल प्रदर्शन में सुधार करने के लिए शीर्ष 10 तरीके