ऑब्जर्वर ओवरहेड और प्रतीक्षा प्रकार के लक्षण

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

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

• एसक्यूएल प्रोफाइलर सत्र उपयोग
• सर्वर-साइड ट्रेस उपयोग
• सर्वर-साइड ट्रेस उपयोग, धीमे I/O पथ पर लिखना
• रिंग बफर लक्ष्य के साथ विस्तारित ईवेंट उपयोग
• एक फ़ाइल लक्ष्य के साथ विस्तारित ईवेंट उपयोग
• धीमे I/O पथ पर फ़ाइल लक्ष्य के साथ विस्तारित ईवेंट उपयोग
• बिना किसी घटना हानि के धीमे I/O पथ पर फ़ाइल लक्ष्य के साथ विस्तारित ईवेंट उपयोग

आप विषय पर अन्य विविधताओं के बारे में सोच सकते हैं और मैं आपको इस पोस्ट में एक टिप्पणी के रूप में पर्यवेक्षक ओवरहेड और प्रतीक्षा आँकड़े के बारे में कोई भी दिलचस्प निष्कर्ष साझा करने के लिए आमंत्रित करता हूं।

आधारभूत

परीक्षण के लिए, मैंने चार वीसीपीयू और 4 जीबी रैम के साथ एक वीएमवेयर वर्चुअल मशीन का इस्तेमाल किया। मेरा वर्चुअल मशीन अतिथि OCZ वर्टेक्स SSDs पर था। ऑपरेटिंग सिस्टम Windows Server 2008 R2 Enterprise था और SQL सर्वर का संस्करण 2012, SP1 CU4 है।

जहां तक ​​"वर्कलोड" का सवाल है, मैं 2008 क्रेडिट सैंपल डेटाबेस के विरुद्ध लूप में केवल-पढ़ने के लिए क्वेरी का उपयोग कर रहा हूं, जिसे 10,000,000 बार GO पर सेट किया गया है।

उपयोग [क्रेडिट];जाओ शीर्ष 1 [सदस्य] चुनें।[सदस्य_नहीं], [सदस्य]। ]से [डीबीओ]।[भुगतान]इनर जॉइन [डीबीओ]।[सदस्य] पर [सदस्य]। 

 मैं इस क्वेरी को 16 समवर्ती सत्रों के माध्यम से भी निष्पादित कर रहा हूं। मेरे परीक्षण सिस्टम का अंतिम परिणाम वर्चुअल अतिथि पर सभी vCPU में 100% CPU उपयोग और 2 मिनट की अवधि में प्रति सेकंड औसतन 14,492 बैच अनुरोध है।
 

 घटना अनुरेखण के संबंध में, मैंने प्रत्येक परीक्षण में Showplan XML Statistics Profile का उपयोग किया SQL Profiler और सर्वर-साइड ट्रेस परीक्षणों के लिए - और query_post_execution_showplan विस्तारित घटना सत्रों के लिए। निष्पादन योजना कार्यक्रम बहुत हैं महंगा है, यही कारण है कि मैंने उन्हें चुना ताकि मैं देख सकूं कि चरम परिस्थितियों में मैं प्रतीक्षा प्रकार की थीम प्राप्त कर सकता हूं या नहीं।
 

 परीक्षण अवधि में प्रतीक्षा प्रकार संचय के परीक्षण के लिए, मैंने निम्नलिखित क्वेरी का उपयोग किया। कुछ भी फैंसी नहीं है - केवल आंकड़े साफ़ करना, 2 मिनट प्रतीक्षा करना और फिर डिग्रेडेशन परीक्षण अवधि में SQL सर्वर आवृत्ति के लिए शीर्ष 10 प्रतीक्षा संचय एकत्र करना:
 
-- प्रतीक्षा आँकड़े साफ़ करना DBCC SQLPERF('waitstats', clear); WAITFOR DELAY '00:02:00'; GO SELECT TOP 10 [wait_type], [waiting_tasks_count], [wait_time_ms]FROM sys.[dm_os_wait_stats] AS [ws]ORDER BY [wait_time_ms] DESC;
 

 ध्यान दें कि मैं नहीं हूं पृष्ठभूमि प्रतीक्षा प्रकारों को फ़िल्टर करना जो आम तौर पर फ़िल्टर किए जाते हैं, और ऐसा इसलिए है क्योंकि मैं सामान्य रूप से सौम्य कुछ को खत्म नहीं करना चाहता था - लेकिन इस परिस्थिति में वास्तव में आगे की जांच के लिए एक वास्तविक क्षेत्र की ओर इशारा करता है।
 
एसक्यूएल प्रोफाइलर सत्र
 

 निम्न तालिका स्थानीय SQL Profiler ट्रेस ट्रैकिंग Showplan XML Statistics Profile को सक्षम करते समय प्रति सेकंड पहले और बाद के बैच अनुरोध दिखाती है (SQL सर्वर इंस्टेंस के समान VM पर चल रहा है):
 
बेसलाइन बैच अनुरोध प्रति सेकेंड
(2 मिनट औसत)
 
एसक्यूएल प्रोफाइलर सत्र बैच अनुरोध प्रति सेकेंड
(2 मिनट औसत)
 
 
14,492
 
1,416
 
 
 
 

 आप देख सकते हैं कि SQL Profiler ट्रेस थ्रूपुट में महत्वपूर्ण गिरावट का कारण बनता है।
 

 उसी अवधि में संचित प्रतीक्षा समय के लिए, शीर्ष प्रतीक्षा प्रकार इस प्रकार थे (जैसा कि इस आलेख में बाकी परीक्षणों के साथ, मैंने कुछ परीक्षण रन किए और आउटपुट आम तौर पर संगत था):
 
प्रतीक्षा_प्रकार
 
वेटिंग_टास्क_काउंट
 
प्रतीक्षा_समय_एमएस
 
 
ट्रेसराइट 
 
67,142
 
1,149,824
 
 
FT_IFTS_SCHEDULER_IDLE_WAIT 
 
4
 
237,003
 
 
SLEEP_TASK 
 
313
 
180,449
 
 
REQUEST_FOR_DEADLOCK_SEARCH 
 
24
 
120,111
 
 
HADR_FILESTREAM_IOMGR_IOCOMPLETION 
 
240
 
120,086
 
 
LAZYWRITER_SLEEP 
 
120
 
120,059
 
 
DIRTY_PAGE_POLL 
 
1,198
 
120,038
 
 
HADR_WORK_QUEUE 
 
12
 
120,015
 
 
LOGMGR_QUEUE 
 
937
 
120,011
 
 
SQLTRACE_INCREMENTAL_FLUSH_SLEEP 
 
30
 
120,006
 
 
 
 

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

 वह एसक्यूएल प्रोफाइलर के लिए था, लेकिन सर्वर-साइड ट्रेस ओवरहेड के बारे में क्या? किसी फ़ाइल में स्थानीय सर्वर-साइड ट्रेस लेखन को सक्षम करते समय निम्न तालिका प्रति सेकंड पहले और बाद के बैच अनुरोध दिखाती है:
 
बेसलाइन बैच अनुरोध प्रति सेकेंड
(2 मिनट औसत)
 
एसक्यूएल प्रोफाइलर बैच अनुरोध प्रति सेकेंड
(2 मिनट औसत)
 
 
14,492
 
4,015
 
 
 
 

 शीर्ष प्रतीक्षा प्रकार इस प्रकार थे (मैंने कुछ परीक्षण रन किए और आउटपुट सुसंगत था):
 
प्रतीक्षा_प्रकार
 
वेटिंग_टास्क_काउंट
 
प्रतीक्षा_समय_एमएस
 
 
FT_IFTS_SCHEDULER_IDLE_WAIT 
 
4
 
237,015
 
 
SLEEP_TASK 
 
253
 
180,871
 
 
SQLTRACE_INCREMENTAL_FLUSH_SLEEP 
 
30
 
120,046
 
 
HADR_WORK_QUEUE 
 
12
 
120,042
 
 
REQUEST_FOR_DEADLOCK_SEARCH 
 
24
 
120,021
 
 
XE_DISPATCHER_WAIT 
 
3
 
120,006
 
 
प्रतीक्षा करें 
 
1
 
120,000
 
 
LOGMGR_QUEUE 
 
931
 
119,993
 
 
DIRTY_PAGE_POLL 
 
1,193
 
119,958
 
 
XE_TIMER_EVENT 
 
55
 
119,954
 
 
 
 

 इस बार हमें TRACEWRITE दिखाई नहीं दे रहा है (अब हम एक फ़ाइल प्रदाता का उपयोग कर रहे हैं) और अन्य ट्रेस-संबंधित प्रतीक्षा प्रकार, अनिर्दिष्ट SQLTRACE_INCREMENTAL_FLUSH_SLEEP ऊपर चढ़ गया - लेकिन पहले परीक्षण की तुलना में, बहुत समान संचित प्रतीक्षा समय (120,046 बनाम 120,006) है - और मेरे सहयोगी एरिन स्टेलाटो (@erinstellato) ने अपनी पोस्ट में इस विशेष प्रतीक्षा प्रकार के बारे में बात की थी जब प्रतीक्षा सांख्यिकी अंतिम बार समाप्त हुई थी . तो अन्य प्रतीक्षा प्रकारों को देखते हुए, कोई भी विश्वसनीय लाल झंडे के रूप में बाहर नहीं निकल रहा है।
 
सर्वर-साइड ट्रेस को धीमे I/O पथ पर लिखना
 

 यदि हम सर्वर-साइड ट्रेस फ़ाइल को स्लो डिस्क पर रखते हैं तो क्या होगा? निम्न तालिका एक स्थानीय सर्वर-साइड ट्रेस को सक्षम करते समय प्रति सेकंड पहले और बाद में बैच अनुरोध दिखाती है जो एक यूएसबी स्टिक पर एक फ़ाइल को लिखता है:
 
बेसलाइन बैच अनुरोध प्रति सेकेंड
(2 मिनट औसत)
 
एसक्यूएल प्रोफाइलर बैच अनुरोध प्रति सेकेंड
(2 मिनट औसत)
 
 
14,492
 
260
 
 
 
 

 जैसा कि हम देख सकते हैं - पिछले परीक्षण की तुलना में भी प्रदर्शन में काफी गिरावट आई है।
 

 शीर्ष प्रतीक्षा प्रकार इस प्रकार थे:
 
प्रतीक्षा_प्रकार
 
वेटिंग_टास्क_काउंट
 
प्रतीक्षा_समय_एमएस
 
 
SQLTRACE_FILE_BUFFER 
 
357
 
351,174
 
 
SP_SERVER_DIAGNOSTICS_SLEEP 
 
2,273
 
299,995
 
 
SLEEP_TASK 
 
240
 
194,264
 
 
FT_IFTS_SCHEDULER_IDLE_WAIT 
 
2
 
181,458
 
 
REQUEST_FOR_DEADLOCK_SEARCH 
 
25
 
125,007
 
 
LAZYWRITER_SLEEP 
 
63
 
124,437
 
 
LOGMGR_QUEUE 
 
941
 
120,559
 
 
HADR_FILESTREAM_IOMGR_IOCOMPLETION 
 
67
 
120,516
 
 
प्रतीक्षा करें 
 
1
 
120,515
 
 
DIRTY_PAGE_POLL 
 
1,204
 
120,513
 
 
 
 

 एक प्रतीक्षा प्रकार जो इस परीक्षण के लिए कूदता है वह है अनिर्दिष्ट SQLTRACE_FILE_BUFFER . इस पर बहुत कुछ प्रलेखित नहीं है, लेकिन नाम के आधार पर, हम एक शिक्षित अनुमान लगा सकते हैं (विशेषकर इस विशेष परीक्षण के विन्यास को देखते हुए)।
 
इवेंट को रिंग बफ़र लक्ष्य तक बढ़ाया
 

 इसके बाद विस्तारित ईवेंट सत्र समकक्षों के निष्कर्षों की समीक्षा करते हैं। मैंने निम्नलिखित सत्र परिभाषा का उपयोग किया:
 
ईवेंट सत्र बनाएं [एप्लिकेशनXYZ] सर्वर पर ईवेंट जोड़ें 

 निम्न तालिका रिंग बफ़र लक्ष्य के साथ XE सत्र को सक्षम करते समय प्रति सेकंड पहले और बाद के बैच अनुरोधों को दिखाती है (query_post_execution_showplan को कैप्चर करना) घटना):
 
बेसलाइन बैच अनुरोध प्रति सेकेंड
(2 मिनट औसत)
 
एसक्यूएल प्रोफाइलर बैच अनुरोध प्रति सेकेंड
(2 मिनट औसत)
 
 
14,492
 
4,737
 
 
 
 

 शीर्ष प्रतीक्षा प्रकार इस प्रकार थे:
 
प्रतीक्षा_प्रकार
 
वेटिंग_टास्क_काउंट
 
प्रतीक्षा_समय_एमएस
 
 
SP_SERVER_DIAGNOSTICS_SLEEP 
 
612
 
299,992
 
 
FT_IFTS_SCHEDULER_IDLE_WAIT 
 
4
 
237,006
 
 
SLEEP_TASK 
 
240
 
181,739
 
 
LAZYWRITER_SLEEP 
 
120
 
120,219
 
 
HADR_WORK_QUEUE 
 
12
 
120,038
 
 
DIRTY_PAGE_POLL 
 
1,198
 
120,035
 
 
REQUEST_FOR_DEADLOCK_SEARCH 
 
24
 
120,017
 
 
SQLTRACE_INCREMENTAL_FLUSH_SLEEP 
 
30
 
120,011
 
 
LOGMGR_QUEUE 
 
936
 
120,008
 
 
प्रतीक्षा करें 
 
1
 
120,001
 
 
 
 

 एक्सई-संबंधित के रूप में कुछ भी नहीं निकला, केवल पृष्ठभूमि कार्य "शोर"।
 
इवेंट को एक फ़ाइल लक्ष्य तक बढ़ाया
 

 रिंग बफ़र लक्ष्य के बजाय फ़ाइल लक्ष्य का उपयोग करने के लिए सत्र को बदलने के बारे में क्या? निम्न तालिका रिंग बफ़र लक्ष्य के बजाय फ़ाइल लक्ष्य के साथ XE सत्र को सक्षम करते समय प्रति सेकंड पहले और बाद के बैच अनुरोध दिखाती है:
 
बेसलाइन बैच अनुरोध प्रति सेकेंड
(2 मिनट औसत)
 
एसक्यूएल प्रोफाइलर बैच अनुरोध प्रति सेकेंड
(2 मिनट औसत)
 
 
14,492
 
4,299
 
 
 
 

 शीर्ष प्रतीक्षा प्रकार इस प्रकार थे:
 
प्रतीक्षा_प्रकार
 
वेटिंग_टास्क_काउंट
 
प्रतीक्षा_समय_एमएस
 
 
SP_SERVER_DIAGNOSTICS_SLEEP 
 
2,103
 
299,996
 
 
FT_IFTS_SCHEDULER_IDLE_WAIT 
 
4
 
237,003
 
 
SLEEP_TASK 
 
253
 
180,663
 
 
LAZYWRITER_SLEEP 
 
120
 
120,187
 
 
HADR_WORK_QUEUE 
 
12
 
120,029
 
 
SQLTRACE_INCREMENTAL_FLUSH_SLEEP 
 
30
 
120,019
 
 
REQUEST_FOR_DEADLOCK_SEARCH 
 
24
 
120,011
 
 
प्रतीक्षा करें 
 
1
 
120,001
 
 
XE_TIMER_EVENT 
 
59
 
119,966
 
 
LOGMGR_QUEUE 
 
935
 
119,957
 
 
 
 

 XE_TIMER_EVENT . के अपवाद के साथ कुछ नहीं , एक्सई-संबंधित के रूप में बाहर कूद गया। बॉब वार्ड की प्रतीक्षा प्रकार रिपोजिटरी इसे तब तक अनदेखा करने के लिए सुरक्षित के रूप में संदर्भित करती है जब तक कि कुछ संभव गलत न हो - लेकिन वास्तव में क्या आप इस सामान्य-सौम्य प्रतीक्षा प्रकार को नोटिस करेंगे यदि यह प्रदर्शन में गिरावट के दौरान आपके सिस्टम पर 9 स्थान पर था? और क्या होगा यदि आप इसे सामान्य रूप से सौम्य प्रकृति के कारण पहले से ही फ़िल्टर कर रहे हैं?
 
इवेंट को धीमे I/O पथ फ़ाइल लक्ष्य तक बढ़ाया
 

 अब क्या होगा यदि मैं फ़ाइल को धीमे I/O पथ पर रखूं? निम्न तालिका USB स्टिक पर फ़ाइल लक्ष्य के साथ XE सत्र को सक्षम करते समय प्रति सेकंड पहले और बाद के बैच अनुरोधों को दिखाती है:
 
बेसलाइन बैच अनुरोध प्रति सेकेंड
(2 मिनट औसत)
 
एसक्यूएल प्रोफाइलर बैच अनुरोध प्रति सेकेंड
(2 मिनट औसत)
 
 
14,492
 
4,386
 
 
 
 

 शीर्ष प्रतीक्षा प्रकार इस प्रकार थे:
 
प्रतीक्षा_प्रकार
 
वेटिंग_टास्क_काउंट
 
प्रतीक्षा_समय_एमएस
 
 
FT_IFTS_SCHEDULER_IDLE_WAIT 
 
4
 
237,046
 
 
SLEEP_TASK 
 
253
 
180,719
 
 
HADR_FILESTREAM_IOMGR_IOCOMPLETION 
 
240
 
120,427
 
 
LAZYWRITER_SLEEP 
 
120
 
120,190
 
 
HADR_WORK_QUEUE 
 
12
 
120,025
 
 
SQLTRACE_INCREMENTAL_FLUSH_SLEEP 
 
30
 
120,013
 
 
REQUEST_FOR_DEADLOCK_SEARCH 
 
24
 
120,011
 
 
प्रतीक्षा करें 
 
1
 
120,002
 
 
DIRTY_PAGE_POLL 
 
1,197
 
119,977
 
 
XE_TIMER_EVENT 
 
59
 
119,949
 
 
 
 

 फिर से, XE_TIMER_EVENT . के अलावा XE से संबंधित कुछ भी बाहर नहीं निकल रहा है ।
 
इवेंट को धीमे I/O पथ फ़ाइल लक्ष्य तक बढ़ाया, कोई ईवेंट हानि नहीं
 

 निम्न तालिका USB स्टिक पर फ़ाइल लक्ष्य के साथ XE सत्र को सक्षम करते समय प्रति सेकंड पहले और बाद के बैच अनुरोधों को दिखाती है, लेकिन इस बार घटना हानि (EVENT_RETENTION_MODE=NO_EVENT_LOSS) की अनुमति के बिना - जो अनुशंसित नहीं है और आप देखेंगे परिणामों में ऐसा क्यों हो सकता है:
 
बेसलाइन बैच अनुरोध प्रति सेकेंड
(2 मिनट औसत)
 
एसक्यूएल प्रोफाइलर बैच अनुरोध प्रति सेकेंड
(2 मिनट औसत)
 
 
14,492
 
539
 
 
 
 

 शीर्ष प्रतीक्षा प्रकार इस प्रकार थे:
 
प्रतीक्षा_प्रकार
 
वेटिंग_टास्क_काउंट
 
प्रतीक्षा_समय_एमएस
 
 
XE_BUFFERMGR_FREEBUF_EVENT 
 
8,773
 
1,707,845
 
 
FT_IFTS_SCHEDULER_IDLE_WAIT 
 
4
 
237,003
 
 
SLEEP_TASK 
 
337
 
180,446
 
 
LAZYWRITER_SLEEP 
 
120
 
120,032
 
 
DIRTY_PAGE_POLL 
 
1,198
 
120,026
 
 
HADR_WORK_QUEUE 
 
12
 
120,009
 
 
REQUEST_FOR_DEADLOCK_SEARCH 
 
24
 
120,007
 
 
SQLTRACE_INCREMENTAL_FLUSH_SLEEP 
 
30
 
120,006
 
 
प्रतीक्षा करें 
 
1
 
120,000
 
 
XE_TIMER_EVENT 
 
59
 
119,944
 
 
 
 

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

 प्रतीक्षा प्रकार एक तरफ, यह ध्यान रखना दिलचस्प था कि बैच अनुरोधों को संसाधित करने की हमारे कार्यभार की क्षमता पर प्रत्येक अवलोकन पद्धति का क्या प्रभाव पड़ा:
 

 
प्रति सेकंड बैच अनुरोधों पर विभिन्न अवलोकन विधियों का प्रभाव 
 

 सभी दृष्टिकोणों के लिए, हमारे बेसलाइन (कोई अवलोकन नहीं) की तुलना में एक महत्वपूर्ण - लेकिन चौंकाने वाला नहीं - हिट था; सबसे अधिक दर्द, हालांकि, प्रोफाइलर का उपयोग करते समय, धीमे I/O पथ पर सर्वर-साइड ट्रेस का उपयोग करते समय, या धीमे I/O पथ पर फ़ाइल लक्ष्य के लिए विस्तारित ईवेंट का उपयोग करते समय महसूस किया गया था - लेकिन केवल तब जब कोई ईवेंट हानि के लिए कॉन्फ़िगर किया गया हो। घटना हानि के साथ, यह सेटअप वास्तव में एक फ़ाइल लक्ष्य के साथ एक तेज़ I/O पथ के बराबर प्रदर्शन करता है, संभवतः क्योंकि यह बहुत अधिक घटनाओं को छोड़ने में सक्षम था।
 
सारांश
 

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

 इसे देखते हुए आप क्या कर सकते हैं? स्पष्ट या स्पष्ट लक्षणों के बिना प्रदर्शन में गिरावट के लिए, मैं निशान और XE सत्रों के बारे में पूछने के लिए दायरे को चौड़ा करने की सलाह देता हूं (एक तरफ के रूप में - यदि सिस्टम वर्चुअलाइज्ड है या गलत पावर विकल्प हो सकता है तो मैं आपके दायरे को चौड़ा करने की भी सलाह देता हूं)। उदाहरण के लिए, किसी सिस्टम के समस्या निवारण के भाग के रूप में, sys.[traces] . की जांच करें और sys.[dm_xe_sessions] यह देखने के लिए कि क्या सिस्टम पर कुछ ऐसा चल रहा है जो अप्रत्याशित है। यह एक अतिरिक्त परत है जिसके बारे में आपको चिंता करने की आवश्यकता है, लेकिन कुछ त्वरित सत्यापन करने से आपका काफी समय बच सकता है।