CPU瓶頸(一)


  這些天看了一篇微軟官方發布的MS SQL Server2008性能問題處理及優化的英文文檔,里面知識點介紹地很詳細,在現實工作中也很實用,遂產生了想把它翻譯一下的念頭。翻譯的過程,既可以幫助自己復習一下這些技術,也可以向其他還不熟悉這一塊的朋友介紹一些新的知識,何樂而不為呢。只是這篇文章有點長,我會分成幾篇隨筆去介紹,所以,不光是對我耐性的考驗,也是對你的考驗哦!

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

 

  CPU瓶頸問題可由硬件資源相對於當前負荷不足而導致。 然而,過度的CPU使用率通常可以通過對查詢進行優化(特別是突然出現的增長但並沒有額外的負載或者其它的查詢發生在服務器上)、定位所有可能的應用程序設計因素、優化系統配置去降低。在你匆匆去購買更快、更多的處理器之前,識別出最大的CPU帶寬消耗者,並且去查看下是否可以優化這些查詢語句或者校正那些設計/配置因素。
通常而言,為了確定服務器是否處於CPU限制,性能監視器是的最簡單工具之一。你應該去查看Processor:%Processor Time計數器是否很高;如果每個處理器的平均處理時間持續高於80%,我們通常就可以認為已經遭遇了CPU瓶頸。


  在SQL Server內部,你也可以使用SQL Server自帶的動態管理視圖去檢查CPU瓶頸。SOS_SCHEDULER_YIELD類型的請求等待或者大量的“可被執行”的任務預示着“可被執行”的線程正在等待着被安排執行並且這個處理器上可能存在着CPU瓶頸。如果你已經啟用了數據收集器,Server Activity報表上的SQL Server Waits圖表將會幫助您很方便地隨時追蹤CPU瓶頸。被消耗的CPU以及SOS_SCHEDULER_YIELD等待這兩項被收縮在了報表上的CPU 等待這個類別里, 並且如果你看到了高CPU使用,你可以使用下鑽功能去查看那條SQL語句消耗了最多的資源。


  下面的這個查詢語句幫助你從較高的層級查看當前哪些緩存的批處理或者過程對CPU的占用最高。這個查詢語句對所有語句的CPU消耗時間進行匯總,並且按照plan_handle(意思是說它們屬於同一個批處理或者過程)進行分組。如果結果中有plan_handle對應的語句個數超過了一個的,你可能就不得不更深入地查找是哪個語句造成了最大的CPU占用。

 

  select top 50
         SUM(qs.total_worker_time) as total_cpu_time,
         SUM(qs.execution_count) as total_execution_count,
         COUNT(*) as number_of_statements,
         qs.plan_handle
   from sys.dm_exec_query_stats qs
   group by qs.plan_handle
   order by SUM(qs.total_worker_time) desc

   

  在本章接下來的內容里,我們會討論在SQL Server中通常會遇到的一些CPU密集使用的操作,也會提到對應的檢測及解決方法。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM