總結一次CPU占用1600%問題的定位過程

這篇文章主要講解了“總結一次CPU占用1600%問題的定位過程”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“總結一次CPU占用1600%問題的定位過程”吧！

起因

1. 經過一次稍微大的改版后，系統上線，上線后測試沒發現問題，第二天反饋系統卡頓，下線。

2. 檢查系統問題 ,優化接口速度 上線，上線后發現沒問題，第二天依舊出現卡頓。此時觀察CPU占用1600%.此時想到的時先回滾。沒有保留現場。

3. 測試環境測試，發現cpu空閑時占用100% 找到問題 修復。但是可以確定，這里100%不是引起1600%的原因。

4. 再次上線，人工實時監控cpu占用率。此時出現了1600%的情況。此時占用cpu 1600%的進程對應的線程如下.

6619 6625 等是占用最高的進程Id.

對JVM棧信息進行打印 并輸出到文件。

6619轉成16進制后為19db 根據進程號在棧文件中搜 如下圖所示

最后發現占用cpu高的全部為gc進程 ，此時可以判定。有部分代碼邏輯內存占用過高。或者出現內存泄漏。

尋找問題

此時已經連續三次上線失敗，沒辦法在從線上測試。那么想的是在灰度環境模擬這個現象 然后dump堆信息 這樣肯定可以找到原因。

1. 第一天 轉移很少一部其他系統流量，以及很少一部分用戶流量過去，沒發現問題。

2. 第二天 其他系統請求的流量保持不變，增加更多的用戶流量，沒有復現問題。

3. 第三天 增加部分其他系統請求的流量，沒有復現問題。

4. 第n天 增加其他系統請求的流量 內存調整小，沒有復現問題。

5. 第n+1天 灰度環境服務與正式環境平分流量，繼續增加用戶量。沒出現問題。

此時核心流程代碼修改過的部分 已經檢查了n遍 沒發現問題。

那么 需要思考一下，為什么灰度環境沒有問題。而線上有問題。他們的用戶有什么不同？

此時發現灰度環境全是權限最低的用戶，而管理員沒有在灰度環境上工作，想到這里 問題已經離真相很近了。可以說已經定位到問題所在了，只需要驗證一下自己的猜想。

其中有個功能，是查看自己所管理人的數據，這個功能因為不是核心功能 ，并且請求的量很小很小，起初并沒有向這個方向考慮。
邏輯是 ： 查找自己下一級別，如果有數據，在繼續查找，恰好 數據庫有一條異常的數據 ，他的下一級就是自己！ 導致產生了死循環，導致內存里的數據越來越多。

并且 只有那一個異常用戶才會引起這個問題！

又因為是IO密集的操作，所以 這個循環占用的cpu很低。在線程棧中并沒有發現他。

解決問題

找到問題解決就是很容易的事情了，不再詳細描述。

反思

第一次系統出現卡頓，正確的處理方式大概應該如下

1. 發現cpu占用高，查看該進程對應的線程在執行什么操作

2. 發現大量的線程在執行gc操作，此時應該dump堆信息

3. 使用jmap等工具查看哪些對象占用內存占用高

4. 找到對應代碼 解決問題

這種bug不應該存在，即使存在了出現問題也不要太慌 應該快速的保留能保留下來的信息。

大的改動上線前需要灰度發布，少量用戶先使用。

感謝各位的閱讀，以上就是“總結一次CPU占用1600%問題的定位過程”的內容了，經過本文的學習后，相信大家對總結一次CPU占用1600%問題的定位過程這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！