昨天下午,我突然收到了維運部門的郵件警報,顯示資料平台伺服器的CPU利用率高達98.94%。最近一段時間,這個利用率持續在70%以上。乍一看,似乎是硬體資源到達了瓶頸,需要擴容。但仔細思考後,我發現我們的業務系統並不是一個高並發或CPU密集的應用。這個利用率實在太誇張了,硬體瓶頸不可能這麼快就到達。肯定是某處的業務代碼邏輯出現了問題。
先登入伺服器使用top指令確認伺服器的具體情況,根據具體情況再進行分析判斷。
透過觀察load average,以及負載評判標準(8核心),可以確認伺服器存在負載較高的情況;
觀察各個進程資源使用情況,可以看出進程id為682的進程,有著較高的CPU佔比
這裡咱們可以使用 pwdx 指令根據 pid 找到業務進程路徑,進而定位到負責人和專案:
可下結論:此進程對應的就是資料平台的web服務。
傳統的方案一般是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,這裡從多角度剖析只是為了給大家呈現一個完整的分析思路。
#經過前面的分析與排查,最後定位到一個時間工具類別的問題,造成了伺服器負載以及cpu使用率的過高。
那麼可以得到結論,如果現在時間是當天上午10點,一次查詢的計算次數就是106060n次=36,000n次計算,而且隨著時間成長,越接近午夜單次查詢次數會線性增加。由於即時查詢、即時警報等模組大量的查詢請求都需要多次呼叫該方法,導致了大量CPU資源的佔用與浪費。
定位到問題之後,首先考慮是要減少計算次數,優化異常方法。排查後發現,在邏輯層使用時,並沒有使用此方法傳回的set集合中的內容,而是簡單的用set的size數值。確認邏輯後,透過新方法簡化計算(當前秒數-當天凌晨的秒數),取代呼叫的方法,解決計算過多的問題。上線後觀察伺服器負載和cpu使用率,對比異常時間段下降了30倍,恢復至正常狀態,至此問題得已解決。
![昨天下午,我突然收到了維運部門的郵件警報,顯示數據平台伺服器的CPU利用率高達98.94%。最近一段時間,這個利用率持續在70%以上。乍一看,似乎是硬體資源到達了瓶頸,需要擴容。但仔細思考後,我發現我們的業務系統並不是一個高並發或CPU密集的應用。這個利用率實在太誇張了,硬體瓶頸不可能這麼快就到達。肯定是某處的業務代碼邏輯出現了問題。
先登入伺服器使用top指令確認伺服器的具體情況,根據具體情況再進行分析判斷。
透過觀察load average,以及負載評判標準(8核心),可以確認伺服器存在負載較高的情況;
觀察各個進程資源使用情況,可以看出進程id為682的進程,有著較高的CPU佔比
這裡咱們可以使用 pwdx 指令根據 pid 找到業務進程路徑,進而定位到負責人和專案:
可下結論:此進程對應的就是資料平台的web服務。
傳統的方案一般是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,這裡從多角度剖析只是為了給大家呈現一個完整的分析思路。
#經過前面的分析與排查,最後定位到一個時間工具類別的問題,造成了伺服器負載以及cpu使用率的過高。
那麼可以得到結論,如果現在時間是當天上午10點,一次查詢的計算次數就是106060n次=36,000n次計算,而且隨著時間成長,越接近午夜單次查詢次數會線性增加。由於即時查詢、即時警報等模組大量的查詢請求都需要多次呼叫該方法,導致了大量CPU資源的佔用與浪費。
定位到問題之後,首先考慮是要減少計算次數,優化異常方法。排查後發現,在邏輯層使用時,並沒有使用此方法傳回的set集合中的內容,而是簡單的用set的size數值。確認邏輯後,透過新方法簡化計算(當前秒數-當天凌晨的秒數),取代呼叫的方法,解決計算過多的問題。上線後觀察伺服器負載和cpu使用率,對比異常時間段下降了30倍,恢復至正常狀態,至此問題得已解決。
以上是我去,Linux 系統 CPU 100% 打滿了!的詳細內容。更多資訊請關注PHP中文網其他相關文章!