cpu load太高問題排查

load average的概念

top命令中load average顯示的是最近1分鐘、5分鐘和15分鐘的系統平均負載。

系統平均負載被定義爲在特定時間間隔內運行隊列中(在CPU上運行或者等待運行多少進程)的平均進程數。若是一個進程知足如下條件則其就會位於運行隊列中：

• 它沒有在等待I/O操做的結果
• 它沒有主動進入等待狀態(也就是沒有調用’wait’)
• 沒有被中止(例如：等待終止)

在Linux中，進程分爲三種狀態，一種是阻塞的進程blocked process，一種是可運行的進程runnable process，另外就是正在運行的進程running process。

進程可運行狀態時，它處在一個運行隊列run queue中，與其餘可運行進程爭奪CPU時間。 系統的load是指正在運行和準備好運行的進程的總數。好比如今系統有2個正在運行的進程，3個可運行進程，那麼系統的load就是5。load average就是必定時間內的load數量。

通常來講只要每一個CPU的當前活動進程數不大於3那麼系統的性能就是良好的，若是每一個CPU的任務數大於5，那麼就表示這臺機器的性能有嚴重問題。

CPU使用率高並不老是意味着CPU工做繁忙，它有多是正在等待其餘子系統。在進行性能分析時，將全部子系統當作一個總體來看是很是重要的，由於在子系統中可能會出現瀑布效應。衡量CPU 系統負載的指標是load,load 就是對計算機系統可以承擔的多少負載的度量,簡單的說是進程隊列的長度。簡單的例子好比食堂有五個窗口，當有小於五個學生來打飯，五個窗口都能及時處理，可是當學生個數超過5個，必然會出現等待的學生。請求大於當前的處理能力，會出現等待，引發load升高。
Load Average 就是一段時間(1min,5min,15min)內平均Load。平均負載的最佳值是1，這意味着每一個進程均可以在一個完整的CPU 週期內完成。

cpu load高的排查思路

1. 首先排查哪些進程cpu佔用率高。 經過命令 ps ux

2.  查看對應java進程的每一個線程的CPU佔用率。經過命令：ps -Lp 15047  cu

3.  追蹤線程內部，查看load太高緣由。經過命令：jstack 15047。

或者打印線程 jstack pidof java > stack.out

查找到對應的threadid, 再反查代碼。

通常經驗

cpu load的飆升，一方面可能和full gc的次數增大有關，一方面可能和死循環有關係

數據庫系統load高的通常緣由

    1 業務併發調用全表掃描/帶有order by 排序的SQL語句.
    2 SQL語句沒有合適索引/執行計劃出錯/update/delete where掃描全表,阻塞其餘訪問相同表的sql執行.
    3 存在秒殺相似的業務好比聚划算10點開團或者雙十一秒殺,瞬時海量訪問給數據庫帶來衝擊。
    4 數據庫作邏輯備份(須要全表掃描)或者多實例的壓縮備份(壓縮時須要大量的cpu計算,會致使系統服務器load飆高)
    5 磁盤寫入方式改變 好比有writeback 變爲 write through
       RAID卡都有寫cache(Battery Backed Write Cache),寫cache對IO性能的提高很是明顯,由於掉電會丟失數據,因此必須由電池提供支持。
       電池會按期充放電,通常爲90天左右,當發現電量低於某個閥值時,會將寫cache策略從writeback置爲writethrough,至關於寫cache會失效,這時若是系統有大量的IO操做,可能會明顯感受到IO響應速度變慢,cpu 隊列堆積系統load 飆高。

判別和處理load高問題

通常根據cpu數量去判斷,也就是Load平均要小於CPU的數量,負載的正常值在不一樣的系統中有着很大的差異。在單核處理器的工做站中,1或2都是能夠接受的。多核處理器的服務器(好比24核)上,load 會到達20 ，甚至更高。

a) 數據庫層面
     1 top -u mysql -c 檢查當前佔用cpu資源最多的進程命令。-c 是爲了顯示出進程對應的執行命令語句，方便查看是什麼操做致使系統load飆高。
     2 根據不一樣的狀況獲取pid 或者MySQL的端口號
     3 若是是MySQL 數據庫服務致使laod 飆高，則可使用以下命令
         show processlist;
         SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND <> 'sleep' AND TIME>100;
        或
         orzdba 工具檢查邏輯讀/thread active的值。用法orzdba --help
         orztop 工具檢查當前正在執行的慢sql,用法orztop -P $port
     4 獲取異常的sql以後，剩下的比較好解決了。結合第一部分中的幾條緣由
        a 選擇合適的索引
        b 調整sql 語句 好比對應order by 分頁採用延遲關聯
        c 業務層面增長緩存，減小對數據庫的直接訪問等
b) OS 系統層面 檢查系統IO

    使用iostat 命令查看r/s(讀請求),w/s(寫請求),avgrq-sz(平均請求大小),await(IO等待), svctm(IO響應時間)

    r/s ,w/s是每秒讀/寫請求的次數。

   util是設備的利用率。若是它接近100%，一般說明設備能力趨於飽和(並不絕對，好比設備有寫緩存)。有時候可能會出現大於100%的狀況，這多半是計算時四捨五入引發的。
    svctm是平均每次請求的服務時間。這裏有一個公式：(r/s+w/s)*(svctm/1000)=util。舉例子：若是util達到100%，那麼此時  svctm=1000/(r/s+w/s)，假設IOPS是1000，則svctm大概在1毫秒左右，若是長時間大於這個數值，說明系統出了問題。
   await是平均每次請求的等待時間。這個時間包括了隊列時間和服務時間，也就是說，通常狀況下，await大於svctm，它們的差值越小，隊列時間越短，反之差值越大，隊列時間越長，說明系統出了問題。
avgqu-sz是平均請求隊列的長度。毫無疑問，隊列長度越短越好。

 

 

參考資料

http://blog.csdn.net/u011183653/article/details/19489603

http://blog.itpub.net/22664653/viewspace-1262635/