Inside SQL Server 讀書隨筆：簡單的CPU效能瓶頸和檢查

 N久之前看了技術內幕的關於CPU分析的一節，寫得一篇，還沒寫完就有事情去了。後來以為自己發表了，結果今天在草稿箱裡看看見了。

整理了一下，發表。。。

對於CPU利用的分析，著重在考察CPU瓶頸，編譯和反編譯。

  1.CPU瓶頸

     可以通觀察PERFMON中的Processor:% Processor Time計數器，來確定是否存在硬性的瓶頸。如果值一值偏高（大於80%），則可以認為需要提升CPU效能了。

     也可以通查詢DMV：sys.dm_os_schedulers來查看。scheduler_id=255是的DAC調度，scheduler_id>255的是SQL Server內部使用調度。如果runnable_tasks_count不為0，

   則說明有任務需要等待時間切片來執行，則可以認為需要提升CPU效能了。

select scheduler_id,current_tasks_count,runnable_tasks_count 
from sys.dm_os_schedulers 
where scheduler_id <255

 

--也可以通如下查詢瞄一下當前最耗時的查詢和處理

selecttop20sum(qs.total_worker_time) as total_cpu_time, 
sum(qs.execution_count) as total_execution_count,
count(*) as  number_of_statements, qs.plan_handle,st.text
from sys.dm_exec_query_stats qs 
cross apply sys.dm_exec_sql_text(qs.plan_handle) as st
groupby qs.plan_handle ,st.text
orderbysum(qs.total_worker_time) des

 當然CPU不是說加就加的，價格貴，申請難，安裝時可能還需要停機時間。

2. 編譯和反編譯

   編譯和反編譯也是一個非常耗CPU的處理，現有系統會因為一些變動（schema,statistics,set屬性,暫存資料表等等的變化），也出現大量的編譯和反編譯,導致CPU使用上升。

   可以通觀察PERFMON中的

        SQL Server: SQL Statistics: Batch Requests/sec，

        SQL Server: SQL Statistics: SQL Compilations/sec，

        SQL Server: SQL Statistics: SQL Recompilations/sec，

   顧名思義，後面兩個計數指標的值越低越好。如果不幸後兩者的數值很高，我們就需要使用Profiler來跟蹤，找出導致大量的編譯和反編譯的語句和對象。

   在定義跟蹤事件時，SQL Server 2005，個人認為只要跟蹤SQL:StmtRecompile即可。

  

   將trace檔案儲存下來，讀取其中資料分析出其中頻繁編譯和反編譯對象。分析的方法可以多種多樣，重點和痛點是按Textdata進行資料彙總，得到符合實際的分析結果。

   因為同一個語句可能因為參數不一樣就會被sqlServer識別為不同語句。

select spid,StartTime,Textdata,EventSubclass,ObjectID,
DatabaseID,SQLHandle ,CPU
from fn_trace_gettable(N'D:\workload_20110707\workload_20110707.trc',1)
orderby CPU desc

　Inside sqlServer裡有提到使用一個微軟工程寫的一個函數來處理，有興趣可以去瞭解使用一下。個人認為：做系統性，長時間的，並且儲存到資料庫來做資料分析的操作，

 應該按書所說來做。但是對於一般情況下（不推薦做法），看來看去就那麼幾條語句會排在前面（要是很多語句都有嚴重的編譯和反編譯情況，那麼就topic應該是:如何處理cpu 100%之  類），可以用Substring來截取前20或者80個字元來Group By,應該就能知道最嚴重的那幾條語句。

 

--------------------------------------------

如蒙轉載或引用，請保留以下內容：
Joe's Blog:http://www.cnblogs.com/Joe-T/