我去，Linux 系統 CPU 100% 打滿了！

昨天下午，我突然收到了維運部門的郵件警報，顯示資料平台伺服器的CPU利用率高達98.94%。最近一段時間，這個利用率持續在70%以上。乍一看，似乎是硬體資源到達了瓶頸，需要擴容。但仔細思考後，我發現我們的業務系統並不是一個高並發或CPU密集的應用。這個利用率實在太誇張了，硬體瓶頸不可能這麼快就到達。肯定是某處的業務代碼邏輯出現了問題。

2、檢查思路

##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 ”線程PID： 0x431 // 將線程PID轉換為 16進制，為後面查找 jstack 日誌做準備

4、jstack 程序PID | vim /十六進位執行緒PID – // 例如：jstack 1040|vim /0x431 –

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

可下結論：是系統中一個時間工具類別方法的執行cpu佔比較高，定位到具體方法後，查看程式碼邏輯是否有效能問題。

※ 如果線上問題比較緊急，可以省略 2.1、2.2 直接執行 2.3，這裡從多角度剖析只是為了給大家呈現一個完整的分析思路。

3、根因分析

#經過前面的分析與排查，最後定位到一個時間工具類別的問題，造成了伺服器負載以及cpu使用率的過高。

• 異常方法邏輯：是把時間戳轉成對應的具體的日期時間格式；
• 上層呼叫：計算當天凌晨至目前時間所有秒數，轉換成對應的格式放入到set中傳回結果；
• 邏輯層：對應的是資料平台即時報表的查詢邏輯，即時報表會按照固定的時間間隔來，並且在一次查詢中有多次（n次）方法呼叫。

那麼可以得到結論，如果現在時間是當天上午10點，一次查詢的計算次數就是106060n次=36,000n次計算，而且隨著時間成長，越接近午夜單次查詢次數會線性增加。由於即時查詢、即時警報等模組大量的查詢請求都需要多次呼叫該方法，導致了大量CPU資源的佔用與浪費。

4、解決方案

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

![昨天下午，我突然收到了維運部門的郵件警報，顯示數據平台伺服器的CPU利用率高達98.94%。最近一段時間，這個利用率持續在70%以上。乍一看，似乎是硬體資源到達了瓶頸，需要擴容。但仔細思考後，我發現我們的業務系統並不是一個高並發或CPU密集的應用。這個利用率實在太誇張了，硬體瓶頸不可能這麼快就到達。肯定是某處的業務代碼邏輯出現了問題。

2、檢查思路

##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 ”線程PID： 0x431 // 將線程PID轉換為 16進制，為後面查找 jstack 日誌做準備

4、jstack 程序PID | vim /十六進位執行緒PID – // 例如：jstack 1040|vim /0x431 –

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

可下結論：是系統中一個時間工具類別方法的執行cpu佔比較高，定位到具體方法後，查看程式碼邏輯是否有效能問題。

※ 如果線上問題比較緊急，可以省略 2.1、2.2 直接執行 2.3，這裡從多角度剖析只是為了給大家呈現一個完整的分析思路。

3、根因分析

#經過前面的分析與排查，最後定位到一個時間工具類別的問題，造成了伺服器負載以及cpu使用率的過高。

• 異常方法邏輯：是把時間戳轉成對應的具體的日期時間格式；
• 上層呼叫：計算當天凌晨至目前時間所有秒數，轉換成對應的格式放入到set中傳回結果；
• 邏輯層：對應的是資料平台即時報表的查詢邏輯，即時報表會按照固定的時間間隔來，並且在一次查詢中有多次（n次）方法呼叫。

那麼可以得到結論，如果現在時間是當天上午10點，一次查詢的計算次數就是106060n次=36,000n次計算，而且隨著時間成長，越接近午夜單次查詢次數會線性增加。由於即時查詢、即時警報等模組大量的查詢請求都需要多次呼叫該方法，導致了大量CPU資源的佔用與浪費。

4、解決方案

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

5、總結

• # 在編碼的過程中，除了實現業務的邏輯，也要注重程式碼效能的最佳化。一個業務需求，能實現，和能實現的更有效率、更優雅其實是兩種截然不同的工程師能力和境界的體現，而後者也是工程師的核心競爭力。
• 在程式碼寫完成之後，多做 review，多思考是不是可以用更好的方式來實現。
• 線上問題不放過任何一個小細節！細節是魔鬼，技術的同學需要有刨根問題的求知慾和追求卓越的精神，只有這樣，才能不斷的成長和提升。

以上是我去，Linux 系統 CPU 100% 打滿了！的詳細內容。更多資訊請關注PHP中文網其他相關文章！