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

?

除了上面3 個(gè)計(jì)數(shù)器以外，還可以用SQL Statistics計(jì)數(shù)器來監(jiān)控。
□ 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 種計(jì)數(shù)器本身并沒有好與壞的區(qū)別，但是不同情況下會有一些建議值或者提醒相
對明顯的異常情況。

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

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

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%' -- 去除不相關(guān)的等待類型
AND wait_type NOT LIKE 'XE%'
AND wait_type NOT IN -- 去除系統(tǒng)類型
( '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啟動之后，所有非系統(tǒng)等待信息中總 等待時(shí)間排名最久的10個(gè)等待類型。根據(jù)這些等待類型，可以粗略地找到一個(gè)進(jìn)一步查看
問題的切人點(diǎn)。
對于CPU壓力，通常相關(guān)的等待類型有SOS_SCHEDULER_Y1ELD、CXPACKET和
CMEMTHREAD。這部分將在第7 章中詳細(xì)介紹

1. SOS_SCHEDULER_YIELD
如果在sys.dm_exec_requests或者sys.dm_os_waiting_tasks中看到這個(gè)等待類型的等待
時(shí)間很長，意味著這個(gè)查詢消耗了很多CPU,首要任務(wù)就是優(yōu)化這個(gè)查詢。
2. CXPACKET
當(dāng)查詢出現(xiàn)并行操作時(shí)，這種等待類型可能就會出現(xiàn)。在OLTP系統(tǒng)中，并行執(zhí)行往
往意味著查詢不夠優(yōu)化，需要進(jìn)一步的優(yōu)化。
3. CMEMTHREAD
表示等待著同步內(nèi)存中的對象，一些內(nèi)存對象會同時(shí)被多個(gè)線程使用，當(dāng)多線程訪問
時(shí)，有些對象會因?yàn)槟承┰驘o法響應(yīng)請求，導(dǎo)致產(chǎn)生這種類型的等待，不過這種類型相
對較少。

轉(zhuǎn)載于:https://www.cnblogs.com/zhouwansheng/p/9247830.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。