sql server 性能調優 資源等待之SOS_SCHEDULER_YIELD

 一.概念

   SOS_SCHEDULER_YIELD等待類型是一個任務自願放棄當前的資源占用，讓給其他任務使用。   這個等待類型與CPU有直接關係，與記憶體與也有間接關係，與CPU有關係是因為在sql server里是通過任務調度SCHEDULER來關聯CPU。 通過SCHEDULER下的Worker線程來處理SQL任務。為什麼跟記憶體有關係呢，是因為獲取的資源需要記憶體來承載。 
　　Yelding的發生：是指SCHEDULER上運行的Worker都是非搶占式的, 在 SCHEDULER上Worker由於資源等待，讓出當前Worker給其它Worker就叫Yielding。 關於SCHEDULER_YIELD產生的原理查看  sqlserver 任務調度與CPU。SOS_SCHEDULER_YIELD 等待的情況可以瞭解到:

　　(1)CPU有壓力

　　(2) SQL Server CPU scheduler 使用得當處理就會效率高。

1.1 從實例級別來查看等待數

select wait_type,
waiting_tasks_count,
wait_time_ms ,
max_wait_time_ms,
signal_wait_time_ms
from sys.dm_os_wait_stats
where wait_type like 'SOS_SCHEDULER_YIELD%' 
order by wait_type

　　查詢如下圖所示: 

　　這個等待類型排名第二，從請求的次數來說有69367060次，也就是說該線程用完了4ms的時間片，主動放棄cpu。如果沒有大量的runnable隊列或者大量的signal wait，證明不一定是cpu問題。因為這兩個指標是cpu壓力的一個體現。需要檢查執行計劃中是否存在大量掃描操作。

1.2 通過dmv scheaduler的描述查看cpu壓力

SELECT scheduler_id, current_tasks_count, runnable_tasks_count, work_queue_count, pending_disk_io_count
FROM sys.dm_os_schedulers
WHERE scheduler_id < 255

　　如下圖所示：

　　如果你註意到runnable_tasks_count計數有兩位數，持續很長時間（一段時間內），你就會知道CPU壓力。兩位數字通常被認為是一件壞事 無法應對當前負荷。另外可以通過性能監視器%Processor Time 來查看CPU的狀況。

1.3 通過案例實時查看sql語句級的資源等待

SELECT * FROM sys.dm_exec_requests  WHERE wait_type LIKE 'SOS_SCHEDULER_YIELD%'

　　-- 或查找資源等待的
　　SELECT session_id ,status ,blocking_session_id
　　,wait_type ,wait_time ,wait_resource
　　,transaction_id
　　FROM sys.dm_exec_requests
　　WHERE status = N'suspended';

　　如下圖所示 運行sys.dm_exec_requests 表，由於欄位多截取了三斷。會話202的sql 語句上一次 等待類型是SOS_SCHEDULER_YIELD。之所以會出現YIELD，是因為SCHEDULER下的Worker已經發起了task 命令，但由於資源等待 如鎖或者磁碟輸入/輸出等，Worker又是非搶占式，所以讓出了當前的Worker。

1.4 減少sos_scheduler_yield 等待

　　正如上面所討論的，這種等待類型與CPU壓力有關。增加更多CPU是簡單的解決方案，然而實現這個解決方案並不容易。當這個等待類型很高時，你可以考慮其他的事情。這裡通過從緩存中找到與CPU相關的最昂貴的SQL語句。

--查詢編譯以來 cpu耗時總量最多的前50條(Total_woker_time) 第一種查詢
select
'total_worker_time(ms)'=(total_worker_time/1000),
q.[text], --DB_NAME(dbid),OBJECT_NAME(objectid),
execution_count,
'max_worker_time(ms)'=(max_worker_time/1000),
'last_worker_time(ms)'=(last_worker_time/1000),
'min_worker_time(ms)'=(min_worker_time/1000),
'max_elapsed_time(ms)'=(max_elapsed_time/1000),
'min_elapsed_time(ms)'=(min_elapsed_time/1000),
'last_elapsed_time(ms)'=(last_elapsed_time/1000),
total_physical_reads,
last_physical_reads,
min_physical_reads,
max_physical_reads,
total_logical_reads,
last_logical_reads,
max_logical_reads,
creation_time,
last_execution_time
from
(select top 50 qs.* from sys.dm_exec_query_stats qs order by qs.total_worker_time desc)
as highest_cpu_queries cross apply sys.dm_exec_sql_text(highest_cpu_queries.plan_handle) as q
order by highest_cpu_queries.total_worker_time DESC