SQL Server 2008 R2 效能調教課程筆記 #3 識別效能瓶頸 – CPU

在效能調教的過程中,利用工具找出最影響效能的癥結點,進而去改善效能問題,效能調教是沒有辦法說已經調教到最好,只能說在這個狀況下是不是能夠比之前發揮出更多硬體的效能,而當調教花費的成本比改善硬體更高的時候,就會選擇改善硬體規格。

怎麼辨識CPU效能瓶頸

  • Processor:% Processor Time 每一個CPU持續高達 75~80% 以上
    • 並非當 Processor 使用率很高的狀況下就是 CPU 瓶頸,使用率很高其實也是發揮出硬體原有的效能,只是平均高達 80% 而且長時間持續突破的情況下可以考慮由這方向查證。
  • Process: % Processor Time for sqlservr Process 數值高(除以CPU個數)
    • 當 CPU 使用率很高,而且大部分的 CPU 效能都是被 SQL SERVER 使用,如果 CPU 使用很高,但是 SQL SERVER 使用的很少,或許要檢查 Server 上面是不是有掛載其他程式使用掉了,固定的執行排程,又抑或是防毒軟體。
  • System: Processor queue length > 2
    • 執行的等待時間持續大於 2 ,幾乎可以斷定是 CPU 瓶頸,每個執行都必須等待兩個以上。
  • Wait Type 中的 CXPACKET 數值非常高
  • DMV 語法中的 runnable_tasks_count 數值持續不為0

造成CPU使用率高的原因

  • 大量並同時的批次作業造成系統無法負荷
    • 在半夜執行的批次作業可以錯開時間

image

  • 查詢的執行計畫(Execution plan)沒有效率
    • 可能是因為索引的關係原本少數資料的 Index Seek 必須要由 Index Scan 來執行
  • 過度的編譯(Compilations)及重新編譯(Recompilations)發生
    • 高比率的(SQL Recompilations/sec)/(Batch Requests/sec)指出重新編譯是導致CPU使用率高的原因,利用參數式查詢,避免每次動態語法重新編譯。
  • 不正確使用平行處理計畫(Intra-query parallelism)
    • 在多 CPU 的 Server 上,SQL Server 在預設行為下遇到需要大量 CPU 的語法執行時候,會自動執行平行計算使用所有的 CPU ,因此可能讓某一項需要長時間運算影響到整體 Server 。OPTION (MAXDOP  1) 可以設定使用單一 CPU 處理單一語法,避免因為一個怪獸級的動作消耗掉全部的效能。
  • 不正確使用伺服器端游標(Server side cursors),影響SQL Server效能

SQL Server 2008 (R2) 效能調教及工具應用專班!!

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *