"服務不可用"怎么排查？講了100遍還是記不住？

程序員的成長之路

互聯(lián)網(wǎng)/程序員/技術/資料共享?

閱讀本文大概需要 2.4 分鐘。

來自：https://urlify.cn/Q3Ar6z

下面是線上機器的cpu使用率，可以看到從4月8日開始，隨著時間cpu使用率在逐步增高，最終使用率達到100%導致線上服務不可用，后面重啟了機器后恢復。

1、排查思路

簡單分析下可能出問題的地方，分為5個方向：

• 系統(tǒng)本身代碼問題
• 內(nèi)部下游系統(tǒng)的問題導致的雪崩效應
• 上游系統(tǒng)調(diào)用量突增
• http請求第三方的問題
• 機器本身的問題

2、開始排查

1. 查看日志，沒有發(fā)現(xiàn)集中的錯誤日志，初步排除代碼邏輯處理錯誤。
2. 首先聯(lián)系了內(nèi)部下游系統(tǒng)觀察了他們的監(jiān)控，發(fā)現(xiàn)一起正常。可以排除下游系統(tǒng)故障對我們的影響。
3. 查看provider接口的調(diào)用量，對比7天沒有突增，排除業(yè)務方調(diào)用量的問題。
4. 查看tcp監(jiān)控，TCP狀態(tài)正常，可以排除是http請求第三方超時帶來的問題。
5. 查看機器監(jiān)控，6臺機器cpu都在上升，每個機器情況一樣。排除機器故障問題。即通過上述方法沒有直接定位到問題。

3、解決方案

1、重啟了6臺中問題比較嚴重的5臺機器，先恢復業(yè)務。保留一臺現(xiàn)場，用來分析問題。

2、查看當前的tomcat線程pid。

3、查看該pid下線程對應的系統(tǒng)占用情況。top -Hp 384

4、發(fā)現(xiàn)pid?4430?4431?4432?4433?線程分別占用了約40%的cpu

5、將這幾個pid轉(zhuǎn)為16進制，分別為114e?114f?1150?1151

6、下載當前的java線程棧?sudo -u tomcat jstack -l 384>/1.txt

7、查詢5中對應的線程情況，發(fā)現(xiàn)都是gc線程導致的

8、dump java堆數(shù)據(jù)

sudo -u tomcat jmap -dump:live,format=b,file=/dump201612271310.dat 384

9、使用MAT加載堆文件，可以看到javax.crypto.JceSecurity對象占用了95%的內(nèi)存空間，初步定位到問題。

MAT下載地址：

http://www.eclipse.org/mat/

10、查看類的引用樹，看到BouncyCastleProvider對象持有過多。即我們代碼中對該對象的處理方式是錯誤的，定位到問題。

4、代碼分析

我們代碼中有一塊是這樣寫的

這是加解密的功能，每次運行加解密都會new一個BouncyCastleProvider對象,放倒Cipher.getInstance()方法中。

看下Cipher.getInstance()的實現(xiàn)，這是jdk的底層代碼實現(xiàn)，追蹤到JceSecurity類中

verifyingProviders每次put后都會remove,verificationResults只會put，不會remove.

看到verificationResults是一個static的map，即屬于JceSecurity類的。所以每次運行到加解密都會向這個map put一個對象，而這個map屬于類的維度，所以不會被GC回收。這就導致了大量的new的對象不被回收。

5、代碼改進

將有問題的對象置為static，每個類持有一個，不會多次新建。

6、本文總結(jié)

遇到線上問題不要慌，首先確認排查問題的思路：

1. 查看日志
2. 查看CPU情況
3. 查看TCP情況
4. 查看java線程，jstack
5. 查看java堆，jmap
6. 通過MAT分析堆文件，尋找無法被回收的對象

推薦閱讀：

ARM M1芯片的MacBook搞開發(fā)香嗎？

請勿過度依賴 Redis 的過期監(jiān)聽

5T技術資源大放送！包括但不限于：C/C++，Linux，Python，Java，PHP，人工智能，單片機，樹莓派，等等。在公眾號內(nèi)回復「2048」，即可免費獲取！！

微信掃描二維碼，關注我的公眾號

朕已閱?