जब मैं प्रतीक्षा कर रहा हूं कि sp_BlitzFirst से प्रतीक्षा कर रहा हूं, तो मुझे यह विवरण मिल गया है:
<?ClickToSeeDetails --
For 20 seconds over the last 5 seconds, SQL Server was waiting on this
particular bottleneck.
-- ?>क्या उसे "पिछले 5 सेकंड में 20 बार पढ़ना चाहिए?" ढूँढना CLR_SEMAPHORE था।
जवाबों:
नहीं - प्रतीक्षा आँकड़े (और अधिक बार नहीं की तुलना में) सर्वर के लिए खर्च किए गए भौतिक समय की तुलना में कुल होगा।
ऐसी स्थिति की कल्पना करें जहां 2 अलग-अलग धागे कुछ संसाधन के लिए एक ही प्रतीक्षा में खर्च करते हैं - आपके पास घड़ी के समय के 1 सेकंड के लिए प्रतीक्षा समय के 2 सेकंड होंगे।
प्रत्येक थ्रेड का अपना स्वयं का इंतजार है - संदेश आपको बता रहा है कि उस विशेष संसाधन के लिए प्रतीक्षा समय के 20 सेकंड घड़ी समय के अंतिम 5 सेकंड में हुए।
या इसे दूसरे तरीके से रखने के लिए, प्रत्येक कोर एक ही समय में कई प्रश्न चला रहा हो सकता है, और कई कोर और भी अधिक प्रतीक्षा कर सकते हैं। जो कहना है, इकाई वास्तव में थ्रेड · सेकंड है, सेकंड नहीं।
यह एक उदाहरण के माध्यम से काम करने में मददगार हो सकता है। एक कार्यकर्ता के लिए तीन सबसे आम राज्यों पर विचार करें :
रनिंग = वर्कर वर्तमान में या तो अनपेक्षित रूप से या प्रीमेच्योर रूप से चल रहा है।
RUNNABLE = कार्यकर्ता शेड्यूलर पर चलने के लिए तैयार है।
SUSPENDED = कार्यकर्ता को वर्तमान में निलंबित कर दिया गया है, जो किसी घटना के संकेत के लिए प्रतीक्षा कर रहा है।
राज्य के साथ श्रमिक RUNNINGप्रतीक्षा समय उत्पन्न कर सकते हैं। उदाहरण के लिए, यदि कार्यकर्ता को SQLOS के बजाय OS में कोड चलाने की आवश्यकता होती है, तो यह प्रीमेप्टिव या बाहरी प्रतीक्षा में प्रवेश कर सकता है। उस समय के दौरान यह अपने संबंधित सीपीयू पर कोड चला रहा होगा लेकिन यह अभी भी प्रतीक्षा समय पैदा कर रहा है।
राज्य के साथ श्रमिक RUNNABLEप्रतीक्षा समय उत्पन्न कर सकते हैं (जहां तक मुझे पता है कि वे हमेशा करते हैं)। यदि कार्यकर्ता को संकेत दिया गया था कि एक संसाधन उपलब्ध था, तो यह अंतिम प्रतीक्षा के आधार पर सिग्नल प्रतीक्षा समय जमा कर सकता है। यदि कार्यकर्ता अपने पिछले 4 एमएस क्वांटम को समाप्त कर देता है तो यह SOS_SCHEDULER_YIELDप्रतीक्षा समय जमा कर सकता है ।
राज्य के साथ श्रमिक SUSPENDEDप्रतीक्षा समय उत्पन्न कर सकते हैं। एक कार्यकर्ता पर विचार करें जो ताला का इंतजार कर रहा है। यह प्रतीक्षा समय उत्पन्न करेगा जब तक कि यह संकेत नहीं दिया जाता है कि ताला संसाधन की आवश्यकता है। कुछ निलंबित कर्मचारी प्रतीक्षा समय उत्पन्न नहीं करते हैं, जिनमें एक कार्य के साथ जुड़े नहीं हैं।
मेरे डेस्कटॉप में चार तार्किक कोर हैं, इसलिए डिफ़ॉल्ट अधिकतम कार्यकर्ता संख्या 512 है । यह लगभग निश्चित रूप से अव्यावहारिक है, लेकिन इस मशीन पर मैं सैद्धांतिक रूप से प्रति सेकंड 512 सेकंड प्रतीक्षा समय उत्पन्न कर सकता हूं अगर मैं हर कार्यकर्ता को एक बार में कुछ इंतजार करने में कामयाब रहा। जैसा कि कोर / वर्कर मायने रखता है कि संख्या और भी अधिक बढ़ सकती है।
आप प्रति सेकंड एक सेकंड से अधिक इंतजार कर सकते हैं यहां तक कि आप SQL सर्वर के खिलाफ कोई भी प्रश्न नहीं चला रहे हैं। मेरी मशीन पर, निम्नलिखित क्वेरी 9-14 पंक्तियों के बीच उत्पन्न होती है:
SELECT [state], last_wait_type, wait_started_ms_ticks
FROM sys.dm_os_workers
WHERE [state] IN ('SUSPENDED', 'RUNNABLE')
AND task_address IS NOT NULL
AND wait_started_ms_ticks <> 0
AND wait_started_ms_ticks >= start_quantum;मैं सर्वर को दोबारा शुरू करने के बाद से कुल प्रतीक्षा समय का एक स्नैपशॉट ले सकता हूं और दस सेकंड के इंतजार के बाद एक नए कुल से तुलना कर सकता हूं:
DECLARE @start_wait_time_ms BIGINT;
SELECT @start_wait_time_ms = SUM(wait_time_ms)
FROM sys.dm_os_wait_stats
WHERE wait_type <> 'WAITFOR';
WAITFOR DELAY '00:00:10';
SELECT SUM(wait_time_ms) - @start_wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type <> 'WAITFOR';कभी-कभी गणित से काम चल जाता है। पिछली बार जब मैंने इसे चलाया था तो डेल्टा 101339 एमएस था। दूसरे शब्दों में, मेरे पास सिस्टम कार्यों से प्रति सेकंड 10 सेकंड से अधिक इंतजार था।