收集等待統計資訊
我們目前使用一個監控工具，它通過等待任務的數量或總等待時間向我們顯示我們的最高等待統計資訊。以下是按等待任務數量以及每個任務等待時間的等待統計資訊。
我們有使用者抱怨系統速度變慢，但伺服器的指標在磁碟 IO、記憶體和 CPU 方面似乎很好。有誰知道 PREEMPTIVE 等待是否是一個問題？
Number of waiting tasks SOS_SCHEDULER_YIELD PAGELATCH_EX PAGELATCH_SH PREEMPTIVE_XE_CALLBACKEXECUTE PREEMPTIVE_XE_GETTARGETSTATE PREEMPTIVE_XE_SESSIONCOMMIT Average wait per task PAGEIOLATCH_SH PREEMPTIVE_XE_GETTARGETSTATE更新：
我從 Paul Randal 進行了與您發布的內容類似的查詢，並得到以下資訊：
WaitType Wait_S Resource_S Signal_S WaitCount Percentage AvgWait_S AvgRes_S AvgSig_S PREEMPTIVE_XE_GETTARGETSTATE 9704.81 9704.81 0.00 604647 44.60 0.0161 0.0161 0.0000我知道這排列得不是很好，但基本上這種等待類型已佔所有等待類型的 %44.60。此外，由於此類型沒有信號等待，因此這表明沒有 CPU 壓力，而是等待其他資源。但是，不確定我如何推斷該資源是什麼。
這也是 SQL 2012 SP1
此處請求的Update2 AS 是您查詢的結果。關於擴展事件，唯一執行的會話是我剛剛注意到的預設 system_health 1 和 2 SharePoint 會話，它們必須預設放置在那裡。我可能會關閉這些我想知道這些是否導致問題。
有趣的是，我的 PREEMPTIVE_XE_GETTARGETSTATE 似乎不在此列表中。
wait_type wait_time_ms signal_wait_time_ms resource_wait_time_ms percent_total_waits percent_total_signal_waits percent_total_resource_waits SP_SERVER_DIAGNOSTICS_SLEEP 300014 355508314 0 24.621089361251698 99.883069863550302 0.000000000000000 MSQL_XP 96782 0 4268999 0.295653861591811 0.000000000000000 0.295653861591811 ASYNC_IO_COMPLETION 56193 64 345552 0.023935987107964 0.000017981341700 0.023931554722962 BACKUPTHREAD 41100 6850 265025 0.018828979257262 0.001924565478840 0.018354575549998 LCK_M_U 40500 71 41030 0.002846491499596 0.000019948050948 0.002841574322484 PWAIT_ALL_COMPONENTS_INITIALIZED 31422 0 94205 0.006524262955146 0.000000000000000 0.006524262955146 XE_LIVE_TARGET_TVF 28050 0 33458 0.002317167771915 0.000000000000000 0.002317167771915 LCK_M_X 4027 50 29195 0.002025392177944 0.000014047923203 0.002021929377161 SQLTRACE_INCREMENTAL_FLUSH_SLEEP 4018 613 355390660 24.612983567922965 0.000172227538471 24.612941113985366 CXPACKET 3756 1 14755 0.001021941767062 0.000000280958464 0.001021872511047
SQL Server 在非搶占模式下工作，這意味著如果 SQLOS 要求它讓步，因為它從 Windows 作業系統獲得了請求，它會要求 SQL Server 讓步，SQL Server 將聽它並會按照 SQLOS 的要求做. 這是因為 SQL Server 作為應用程序執行，並由 Windows O 監控的 SQLOS 分配資源。當 SQL Server 正在執行任務並被作業系統中斷並要求放棄它正在使用的執行緒時，就會發生搶先等待類型，以便可以分配給其他任務，SQL 會做。它將產生並等待執行緒可用，這種等待將在 PREEMTIVE-XXX 等待下進行。
這裡的 SQL Server 版本是什麼，它已修補到最新的 Service Pack，SQL Server 2008 中存在一個錯誤，指出搶先等待類型的值不正確。
您能否執行sys.dm_exec_requests DMV 並查看獲取搶占等待類型的程序是否已掛起或正在執行。
您能否發布以下查詢的輸出（由 Jonathan Kehayias 提供）以擷取等待統計資訊
SELECT TOP 10 wait_type , max_wait_time_ms wait_time_ms , signal_wait_time_ms , wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms , 100.0 * wait_time_ms / SUM(wait_time_ms) OVER ( ) AS percent_total_waits , 100.0 * signal_wait_time_ms / SUM(signal_wait_time_ms) OVER ( ) AS percent_total_signal_waits , 100.0 * ( wait_time_ms - signal_wait_time_ms ) / SUM(wait_time_ms) OVER ( ) AS percent_total_resource_waits FROM sys.dm_os_wait_stats WHERE wait_time_ms > 0 -- remove zero wait_time AND wait_type NOT IN -- filter out additional irrelevant waits ( 'SLEEP_TASK', 'BROKER_TASK_STOP', 'BROKER_TO_FLUSH', 'SQLTRACE_BUFFER_FLUSH','CLR_AUTO_EVENT', 'CLR_MANUAL_EVENT', 'LAZYWRITER_SLEEP', 'SLEEP_SYSTEMTASK', 'SLEEP_BPOOL_FLUSH', 'BROKER_EVENTHANDLER', 'XE_DISPATCHER_WAIT', 'FT_IFTSHC_MUTEX', 'CHECKPOINT_QUEUE', 'FT_IFTS_SCHEDULER_IDLE_WAIT', 'BROKER_TRANSMITTER', 'FT_IFTSHC_MUTEX', 'KSOURCE_WAKEUP', 'LOGMGR_QUEUE', 'ONDEMAND_TASK_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BAD_PAGE_PROCESS', 'DBMIRROR_EVENTS_QUEUE', 'BROKER_RECEIVE_WAITFOR', 'PREEMPTIVE_OS_GETPROCADDRESS', 'PREEMPTIVE_OS_AUTHENTICATIONOPS', 'WAITFOR', 'DISPATCHER_QUEUE_SEMAPHORE', 'XE_DISPATCHER_JOIN', 'RESOURCE_QUEUE' ) ORDER BY wait_time_ms DES系統上正在執行的其他程序是 OS 在負載下系統有多少 CPU 核心？
編輯：使用者粘貼輸出後
輸出沒有給出，具體圖片使用我的查詢。您是否還在執行擴展事件跟踪，因為我可以看到 XE 等待類型。我認為這種等待類型是有害的，而且您似乎沒有遇到問題。監控工具有時會反應過度，因此對於您發布的結果，我只會認為它是正常行為。
EDIT2：我沒有發現您發布的等待統計輸出有任何問題。我還假設您的伺服器最近沒有重新啟動，否則等待統計資訊將無用。