Expert 診斷優化系列------------------你的CPU高麼？

　　　　如今不少用戶被數據庫的慢的問題所困擾，又苦於花錢請一個專業的DBA成本過高。軟件維護人員對數據庫的瞭解又不是那麼深刻，因此致使問題遲遲不能解決，或只能暫時解決不能獲得根治。開發人員解決數據問題基本又是搜遍百度各類方法嘗試個遍，可能錯過診斷問題的最佳時機又可能嘗試一堆方法最後無奈放棄。

　　　　怎麼樣讓雜事纏身的程序維護人員，用最快的方式解決數據庫出現的問題？怎麼讓咱們程序員的痛苦下降到最小...天天喝喝茶水，看看新聞平安度過一天呢？本系列重要經過Expert for sqlserver 工具講解下數據庫遇到的各類問題的表象及致使這樣問題的根本緣由，讓定位問題更準確，解決問題思路更清晰！！

　　　　數據庫的性能好壞，對於最終用戶來講表現爲點擊的操做是否可以快速響應，那麼反應到數據庫上就是語句執行時間是否夠短！

　　　　對用運維人員數據庫性能的表現，簡單可能當作CPU 、內存、磁盤三巨頭指標是否正常，那麼今天咱們就從CPU 下手，看看CPU可以看出哪些問題！

 

廢話很少說，直接開整---------------------------------------------------------------------------------------------------

　　主要用到的性能計數器（不知道什麼是性能計數器的，請自行百度）

　　就用兩個~

1. %Process Time　全實例　 （主要用於查看當前服務器的CPU 狀況）
2. %Process Time　sqlservr （主要用於查看數據庫使用的CPU狀況 ）

排除應用影響CPU　　　　　　　　　　　　　　　　　　　　　　　

 

　　　　

　　　　

　　

　　綜合這兩個計數器 在同一時間點能夠診斷出CPU 是不是被服務器其餘的應用所消耗的，如圖中17:10 左右的  「%Process Time　全實例（紅線）」 忽然升高，而SQL 服務的（綠線）並沒有明顯升高，這也就說明，在這個時間段的CPU 壓力不是有數據庫致使的！

　　這個紅線的明顯升高時，由於我在數據庫所在的服務器上作了一次文件壓縮！相似文件壓縮這種操做會使用大量CPU，對數據庫性能形成衝擊！

 

CPU 問題分析　　　　　　　　　　　　　　　　　　　　　　　　

 　　　CPU很高或者達到100%必定是你業務壓力很大？CPU 不能知足你的需求麼？在下結論前請仔細分析，一個草率的定論可能換來，老闆一個安慰「世界那麼大你該出去走走了！」

　　　下面咱們用幾個典型的場景，分析下問題，並給出最佳實踐~

高峯時段CPU 持續很高

　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　圖中是服務器幾天的CPU狀況

　　　　不少人看到這張圖，是否是看到了本身的服務器？是否有一種親切感呢~下面咱們來分析下這種表象可能存在的問題！

　　　　首先明確一點90%的問題可能集中在10%的場景，這種CPU 持續持續很高的狀況請注意下面兩點：

1. 你的數據庫並行度是否調整？
2. 你的數據庫是否缺乏索引，致使頻繁的查詢消耗很高的CPU資源？　　　　

　　　　最大並行度是什麼？簡單的能夠理解爲執行一條語句最多可使用多少個CPU。看起來固然是使用的越多越好啦，使用的越多語句確定越快呀！ 這個答案是大寫的 「NO」，使用過多的CPU會致使線程協同工做產生的時間較長，直接致使語句很慢，並且消耗的CPU時間不少，致使CPU使用高，進而成爲瓶頸！

　　看一個數據語句持續時間也就是執行時間，可是看看CPU的時間，這就是沒有設置並行度，一個並行計劃會產生大量的CPU消耗，另外會讓語句執行的更慢！　　　　

　　

　　　　那麼是否是使用的越少越好呢？任何事情沒有絕對的，視狀況而定，若是系統有比較大數據量的操做需求，並行使用多個CPU會有很大的提高。

　　　　通常建議系統若是超過32個CPU 那麼設置成8或者4，若是系統中都是特別短小且頻繁的語句建議設置成1（取消語句並行，要慎重真的符合你的場景纔好）

 

　　　　注：不少時候並行度設置和你的服務器CPU配置有關，好比有幾路、幾核、是否超線程，通常來講不要跨物理CPU爲好。

 

　　　　並行開銷的閥值，主要控制SQL優化器什麼時候選用並行計劃，建議默認值，此值設置的越小優化器越容易選擇並行計劃。

　　　　並行度的設置是針對實例級別的設置（2016中能夠對單獨數據庫設置）

　　　　怎麼設置並行度和閥值，請看下圖: 系統默認的並行度 爲0，閥值默認爲5

　　　　

　　

　　　　並行度的調整可謂誰用誰知道啊，下面咱們說說系統老大難的問題--語句致使CPU高

　　　　語句致使CPU高也是很常見的問題之一，那麼語句怎麼調優下降CPU 消耗呢？ 這裏只作一些簡單的說明，具體的語句調優、參數化減小語句編譯，請看後面的系列文章。

　　　　語句調優的方式不少種，這裏介紹和CPU相關最爲經常使用：

1. 添加索引下降語句開銷，執行須要的資源消耗少了消耗的CPU 天然相對就少了。
2. 下降語句複雜度，讓SQL Server執行高效（一樣也是下降資源消耗的方法）。
3. 分析語句是否能夠採用串行計劃。
4. 前端程序儘可能參數化減小語句的編譯消耗。

CPU 規律波動

　　　　拿到CPU的監控數據不要盲目下結論，數據每每是最能反映問題，給你提供思路的！

　　　　

 

　　　　若是你是系統維護人員，看到相似這樣的CPU數據指標，若是你還不能有一些思路，請你好好熟悉下你親愛的系統。

　　　　這張圖很清晰地反映出系統每半小時一次的CPU升高，那麼別忙着去找對應時間點的語句，咱們最少要好好想一下，系統中有什麼操做半小時執行一直？SQL JOB？計劃任務？前臺定時處理？等等等

　　　　這個規律的定時處理是否有異常？是否最近有什麼改動？執行的結果是否是和你想的同樣？

　　　　也許問題就這麼清晰的定位了......

CPU 忽然飆高

 　　　　

　　　　　　　　　　　　　　　　　　　　圖中 9點CPU由平均20幾飆升到100%

　　　　CPU忽然飆高多是偶然的現象，也許你能夠認爲沒有關係，但當你判斷爲偶然以前，你是否作過下面的分析：

1. 是否分析過系統日誌，CPU飆高時間點是否有異常？
2. 是否檢查服務器上有什麼特殊應用？
3. 是否檢查了數據庫狀態？
4. 是否詢問過相關業務人員？
5. 是否立刻開啓監控爲下一次突發狀況的到來作好準備？

　　　　若是沒有你的判斷真是毫無根據...也錯過了一次發現問題，學習知識的機會！

　　　　排除上述異常，最有可能的緣由就是數據庫中，在那一刻有一個或多個語句運行異常，或很是不優化。若是這狀況真的由於語句問題，並且只出現一次，那麼這可能不是問題，咱們儘可能找到當時的語句，查看問題。找到當時的語句能夠經過系統視圖sys.dm_exec_query_stats 查看CPU消耗以及運行時間，或者由本身的監控工具獲得。

　　　　找到對應的時間點看看究竟是什麼語句在運行~

　　　　

　　　　

　　　　對這條語句進行分析究竟是爲何！

 

 

CPU 真高

　　　　通過各類分析優化，若是依然CPU壓力明顯，真心是硬件不能支撐業務了，那麼咱們就要選擇更高大上的方式了，好比修改程序設計垂直/水平拆分，添加硬件，讀寫分離分擔壓力，組建集羣負載均衡等等手段......

 

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

　　總結：對於CPU壓力的解決，大部分的用戶能夠經過調整並行度和系統語句的優化來解決。

　　　　  另外對系統的監控和分析在診斷問題及解決問題中起到相當重要的做用。

　　　　  在下結論前必定要通過仔細的分析研究，一個想固然的決定可能形成嚴重的影響。

　　　　　你的系統真的須要加硬件，或高大上的方案麼？　　　　　

　　　　

-----------------------給出一些CPU相關的文章鏈接-----------------------------------------------------

樺仔的  SQLSERVER排查CPU佔用高的狀況

高大俠的  深刻解析SQL Server並行執行原理及實踐(下)

careyson的 談一談SQL Server中的執行計劃緩存（上）

 經常使用 監控SQLSERVER性能計數器

 

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

注：此文章爲原創，歡迎轉載，請在文章頁面明顯位置給出此文連接！
若您以爲這篇文章還不錯請點擊下右下角的推薦，很是感謝！

　　引用高大俠的一句話 ：「拒絕SQL Server背鍋，從我作起!」

 

 

爲了方便閱讀給出系列文章的導讀連接：

SQL SERVER全面優化-------Expert for SQL Server 診斷系列