Linux CPU負載過高問題排查
- 2019 年 10 月 30 日
- 筆記
1、排查思路
1.1 定位高負載進程
首先登錄到服務器使用top命令確認服務器的具體情況,根據具體情況再進行分析判斷。
通過觀察load average,以及負載評判標準(8核),可以確認服務器存在負載較高的情況;
CPU負載過高異常排查實踐與總結CPU負載過高異常排查實踐與總結
觀察各個進程資源使用情況,可以看出進程id為682的進程,有着較高的CPU佔比
1.2 定位具體的異常業務
這裡咱們可以使用 pwdx 命令根據 pid 找到業務進程路徑,進而定位到負責人和項目:
CPU負載過高異常排查實踐與總結CPU負載過高異常排查實踐與總結
可得出結論:該進程對應的就是數據平台的web服務。
1.3 定位異常線程及具體代碼行
傳統的方案一般是4步:
- top oder by with P:1040 // 首先按進程負載排序找到 maxLoad(pid)
- top -Hp 進程PID:1073 // 找到相關負載 線程PID
- printf 「0x%xn」線程PID: 0x431 // 將線程PID轉換為 16進制,為後面查找 jstack 日誌做準備
- jstack 進程PID | vim +/十六進制線程PID – // 例如:jstack 1040|vim +/0x431 –
但是對於線上問題定位來說,分秒必爭,上面的 4 步還是太繁瑣耗時了,之前介紹過淘寶的oldratlee 同學就將上面的流程封裝為了一個工具:show-busy-java-threads.sh,可以很方便的定位線上的這類問題:
CPU負載過高異常排查實踐與總結CPU負載過高異常排查實踐與總結
可得出結論:是系統中一個時間工具類方法的執行cpu佔比較高,定位到具體方法後,查看代碼邏輯是否存在性能問題。
※ 如果線上問題比較緊急,可以省略 2.1、2.2 直接執行 2.3,這裡從多角度剖析只是為了給大家呈現一個完整的分析思路。
2、根因分析
經過前面的分析與排查,最終定位到一個時間工具類的問題,造成了服務器負載以及cpu使用率的過高。
- 異常方法邏輯:是把時間戳轉成對應的具體的日期時間格式;
- 上層調用:計算當天凌晨至當前時間所有秒數,轉化成對應的格式放入到set中返回結果;
- 邏輯層:對應的是數據平台實時報表的查詢邏輯,實時報表會按照固定的時間間隔來,並且在一次查詢中有多次(n次)方法調用。
那麼可以得到結論,如果現在時間是當天上午10點,一次查詢的計算次數就是 106060n次=36,000n次計算,而且隨着時間增長,越接近午夜單次查詢次數會線性增加。由於實時查詢、實時報警等模塊大量的查詢請求都需要多次調用該方法,導致了大量CPU資源的佔用與浪費。
3、解決方案
定位到問題之後,首先考慮是要減少計算次數,優化異常方法。排查後發現,在邏輯層使用時,並沒有使用該方法返回的set集合中的內容,而是簡單的用set的size數值。確認邏輯後,通過新方法簡化計算(當前秒數-當天凌晨的秒數),替換調用的方法,解決計算過多的問題。上線後觀察服務器負載和cpu使用率,對比異常時間段下降了30倍,恢復至正常狀態,至此該問題得已解決。
CPU負載過高異常排查實踐與總結CPU負載過高異常排查實踐與總結
4、總結
- 在編碼的過程中,除了要實現業務的邏輯,也要注重代碼性能的優化。一個業務需求,能實現,和能實現的更高效、更優雅其實是兩種截然不同的工程師能力和境界的體現,而後者也是工程師的核心競爭力。
- 在代碼編寫完成之後,多做 review,多思考是不是可以用更好的方式來實現。
- 線上問題不放過任何一個小細節!細節是魔鬼,技術的同學需要有刨根問題的求知慾和追求卓越的精神,只有這樣,才能不斷的成長和提升。