CPU 100% 異常排查實踐與總結

一、問題背景

昨天下午忽然收到運維郵件報警，顯示數據平臺服務器cpu利用率達到了98.94%，並且最近一段時間一直持續在70%以上，看起來像是硬件資源到瓶頸須要擴容了，但仔細思考就會發現我們的業務系統並非一個高併發或者CPU密集型的應用，這個利用率有點太誇張，硬件瓶頸應該不會這麼快就到了，必定是哪裏的業務代碼邏輯有問題。

二、排查思路

2.1 定位高負載進程 pid

首先登陸到服務器使用top命令確認服務器的具體狀況，根據具體狀況再進行分析判斷。

經過觀察load average，以及負載評判標準（8核），能夠確認服務器存在負載較高的狀況；

觀察各個進程資源使用狀況，能夠看出進程id爲682的進程，有着較高的CPU佔比

2.2 定位具體的異常業務

這裏我們可使用 pwdx 命令根據 pid 找到業務進程路徑，進而定位到負責人和項目：

可得出結論：該進程對應的就是數據平臺的web服務。

2.3 定位異常線程及具體代碼行

傳統的方案通常是4步：

1. top oder by with P：1040 // 首先按進程負載排序找到  maxLoad(pid)
2. top -Hp 進程PID：1073    // 找到相關負載 線程PID
3. printf 「0x%x\n」線程PID： 0x431  // 將線程PID轉換爲 16進制，爲後面查找 jstack 日誌作準備
4. jstack  進程PID | vim +/十六進制線程PID -        // 例如：jstack 1040|vim +/0x431 -

可是對於線上問題定位來講，分秒必爭，上面的 4 步仍是太繁瑣耗時了，以前介紹過淘寶的oldratlee 同窗就將上面的流程封裝爲了一個工具：show-busy-java-threads.sh，能夠很方便的定位線上的這類問題：

可得出結論：是系統中一個時間工具類方法的執行cpu佔比較高，定位到具體方法後，查看代碼邏輯是否存在性能問題。

※ 若是線上問題比較緊急，能夠省略 2.一、2.2 直接執行 2.3，這裏從多角度剖析只是爲了給你們呈現一個完整的分析思路。

三、根因分析

通過前面的分析與排查，最終定位到一個時間工具類的問題，形成了服務器負載以及cpu使用率的太高。

• 異常方法邏輯：是把時間戳轉成對應的具體的日期時間格式；
• 上層調用：計算當天凌晨至當前時間全部秒數，轉化成對應的格式放入到set中返回結果；
• 邏輯層：對應的是數據平臺實時報表的查詢邏輯，實時報表會按照固定的時間間隔來，而且在一次查詢中有屢次（n次）方法調用。

那麼能夠獲得結論，若是如今時間是當天上午10點，一次查詢的計算次數就是 10*60*60*n次=36,000*n次計算，並且隨着時間增加，越接近午夜單次查詢次數會線性增長。因爲實時查詢、實時報警等模塊大量的查詢請求都須要屢次調用該方法，致使了大量CPU資源的佔用與浪費。

四、解決方案

定位到問題以後，首先考慮是要減小計算次數，優化異常方法。排查後發現，在邏輯層使用時，並無使用該方法返回的set集合中的內容，而是簡單的用set的size數值。確認邏輯後，經過新方法簡化計算（當前秒數-當天凌晨的秒數），替換調用的方法，解決計算過多的問題。上線後觀察服務器負載和cpu使用率，對比異常時間段降低了30倍，恢復至正常狀態，至此該問題得已解決。

五、總結

• 在編碼的過程當中，除了要實現業務的邏輯，也要注重代碼性能的優化。一個業務需求，能實現，和能實現的更高效、更優雅實際上是兩種大相徑庭的工程師能力和境界的體現，然後者也是工程師的核心競爭力。
• 在代碼編寫完成以後，多作 review，多思考是否是能夠用更好的方式來實現。
• 線上問題不放過任何一個小細節！細節是魔鬼，技術的同窗須要有刨根問題的求知慾和追求卓越的精神，只有這樣，才能不斷的成長和提高。

Refer：

[1] 線上服務 CPU 100%？一鍵定位 so easy！

https://my.oschina.net/leejun2005/blog/1524687

[2] 又一次生產 CPU 高負載排查實踐

http://bit.ly/31Ffizi

[3] linux 系統監控、診斷工具之 top 詳解

https://my.oschina.net/leejun2005/blog/157910