4.3 CPU性能偵測
CPU的性能問題在日常使用中很常見，但是表現形式幾乎只有一種，就是在任務管理
器中看到CPU的使用率居高不下。這時候需要偵測問題的根源并選擇對應的處理方式。
4 .3 .1 偵測CPU壓力
偵測CPU問題通?？梢允褂眯阅鼙O視器、SQL Trace和DMVs等。下面簡要介紹一下。
1 .性能監視器
性能監視器（PerfMon)可能是偵測問題的第一個工具（任務管理器不算，因為它不能 找到存在什么問題)。這是一個Windows上的工具，可用于分離問題，找到究竟是由操作系 統本身導致的還是由SQL Server導致的問題。比如對于CPU高利用率，在使用性能監視器 時可以重點關注下面的計數器。
□ Processor/ %Privileged Time: 花費在執行Windows內核命令上的處理器時間的百分比。 □ Processor/ %User Time：花費在處理應用程序如SQL Server上的處理器時間百分比。 □ Process (sqlservr.exe)/ %Processor Time：每個處理器上所有進程的總處理時間。
然后，把上面的計數器加人監視器并進行監控，如圖4-2所示。

?

除了上面3 個計數器以外，還可以用SQL Statistics計數器來監控。
□ SQL Server:SQL Statistics/Auto-Param Attempts/sec □ SQL Server:SQL Statistics/Failed Auto-params/sec □ SQL Server:SQL Statistics/Batch Requests/sec □ SQL Server:SQL Statistics/SQL Compilations/sec □ SQL Server:SQL Statistics/SQL Re-Compilations/sec □ SQL Server:Plan Cache/Cache hit Ratio
這 4 種計數器本身并沒有好與壞的區別，但是不同情況下會有一些建議值或者提醒相
對明顯的異常情況。

2. SQL Trace
可以用Profiler來生成腳本并用于SQL Trace。對于周期性發生的問題，SQL Trace非
常有用，因為作為圖形化操作的Profiler—直開著并不合理，有時候反而會給已經處于壓力 底下的服務器帶來新一輪壓力。使用SQL Trace最重要的目的是獲取消耗最多CPU的查詢， 這部分稍后演示。
3. DMV
相比前面兩種工具，DMV更加快速和便捷，不需要進行過多的預備工作。下面是常規
步驟：
1 ) 使用sys.dm_os_wait_stats檢査信號等待（在第7 章介紹)，檢查是否存在CPU壓力。 2 ) 根據等待類型，通過 sys.dm_os_wait_stats 和 sys.dm_os_schedulers 確定 CPU 問題
的種類。
3 ) 通過 sys.dm_exec_query_stats 和 sys.dm_exec_sql_text 找出計劃緩存中 CPU 消耗最
高的查詢。
4 ) 通過sys.dm os waiting tasks找到當前等待任務中CPU相關的等待類型最髙的任務。 5 ) 從 sys.dm exec requests中找到當前査詢中資源使用最高的查詢。

4 .3 .2 研究CPU相關的等待信息
當一個請求由于某些原因產生等待時，SQL Server會把相關信息存放在sys.dm_os_ wait_stats這個DMV中。很多第三方工具都是通過分析這個DMV中的信息進行問題偵測 的，下面來看個例子。
比如可以用下面語句檢查等待類型中等待時間最長的10個類型。

SELECT TOP ( 10 )
wait_type ,
waiting_tasks_count ,
( wait_time_ms - signal_wait_time_ms ) AS resource_wait_time ,
max_wait_time_ms ,
CASE waiting_tasks_count
WHEN 0 THEN 0
ELSE wait_time_ms / waiting_tasks_count
END AS avg_wait_time
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE '%SLEEP%' -- 去除不相關的等待類型
AND wait_type NOT LIKE 'XE%'
AND wait_type NOT IN -- 去除系統類型
( 'KSOURCE_WAKEUP', 'BROKER_TASK_STOP', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
'SQLTRACE_BUFFER_FLUSH', 'CLR_AUTO_EVENT', 'BROKER_EVENTHANDLER',
'BAD_PAGE_PROCESS', 'BROKER_TRANSMITTER', 'CHECKPOINT_QUEUE',
'DBMIRROR_EVENTS_QUEUE', 'SQLTRACE_BUFFER_FLUSH', 'CLR_MANUAL_EVENT',
'ONDEMAND_TASK_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'LOGMGR_QUEUE',
'BROKER_RECEIVE_WAITFOR', 'PREEMPTIVE_OS_GETPROCADDRESS',
'PREEMPTIVE_OS_AUTHENTICATIONOPS', 'BROKER_TO_FLUSH' )
ORDER BY wait_time_ms DESC

通過上面的査詢，可以看到自上一次SQL Server啟動之后，所有非系統等待信息中總 等待時間排名最久的10個等待類型。根據這些等待類型，可以粗略地找到一個進一步查看
問題的切人點。
對于CPU壓力，通常相關的等待類型有SOS_SCHEDULER_Y1ELD、CXPACKET和
CMEMTHREAD。這部分將在第7 章中詳細介紹

1. SOS_SCHEDULER_YIELD
如果在sys.dm_exec_requests或者sys.dm_os_waiting_tasks中看到這個等待類型的等待
時間很長，意味著這個查詢消耗了很多CPU,首要任務就是優化這個查詢。
2. CXPACKET
當查詢出現并行操作時，這種等待類型可能就會出現。在OLTP系統中，并行執行往
往意味著查詢不夠優化，需要進一步的優化。
3. CMEMTHREAD
表示等待著同步內存中的對象，一些內存對象會同時被多個線程使用，當多線程訪問
時，有些對象會因為某些原因無法響應請求，導致產生這種類型的等待，不過這種類型相
對較少。

轉載于:https://www.cnblogs.com/zhouwansheng/p/9247830.html

總結

以上是生活随笔為你收集整理的4.3 CPU性能侦测的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。