大家好，我是烤鴨：

???最近沒怎么寫技術(shù)文章，還是得回歸下初心，正好前幾天出現(xiàn)個線上問題，記錄下排查過程。

問題描述

某個時間點(diǎn)，接收到接口響應(yīng)慢報警。

過一會收到服務(wù)器cpu可用率低(<10%)報警。

去cat上查看發(fā)現(xiàn)younggc次數(shù)頻繁。

排查思路

• 業(yè)務(wù)代碼近期沒改動和發(fā)版，出現(xiàn)問題大概率是中間件或者環(huán)境問題(服務(wù)器硬件或網(wǎng)絡(luò))。

• 嘗試回滾代碼和擴(kuò)容機(jī)器。

• 輸出堆棧日志和gc快照，調(diào)整jvm參數(shù)。

排查結(jié)果

• 中間件和網(wǎng)絡(luò)：

  使用到的中間件包括 es、redis、mysql，分別去監(jiān)控和連接查看，沒問題。

  網(wǎng)絡(luò)也在機(jī)器上測試，沒問題。

• 回滾和擴(kuò)容

  嘗試回滾到上一個穩(wěn)定版本和增加擴(kuò)容機(jī)器。

  還是有問題。

• 輸出堆棧日志和gc快照，調(diào)整jvm參數(shù)。

  其實(shí)堆棧日志是可以解決問題的，不過當(dāng)天晚上排查的時候，沒有過度關(guān)注業(yè)務(wù)方法，導(dǎo)致錯過了問題根源。

  gc快照分析結(jié)果，發(fā)現(xiàn)是tomcat的一個初始化對象占有較多（跟問題無關(guān)）。

總結(jié)

cpu升高和gc頻繁，其實(shí)是兩個問題，都可能會引起服務(wù)不可用。

單純的cpu升高，基本確認(rèn)是死循環(huán)問題，抓到對應(yīng)的堆棧信息即可。

#抓取進(jìn)程中cpu消耗高的線程 top -Hp pid #線程id轉(zhuǎn)成十六進(jìn)制 printf '%x\n' tid #抓取java線程堆棧 jstak-l pid

而gc頻需要查看gc日志，是否引起oom。

實(shí)時查看gc情況，每隔5s打印一下gc情況。

jstat -gcutil pid 5000

輸出gc快照。

jmap -dump:format=b,file=/data/dump.hprof pid

然后使用eclipse mat 或者 jprofiler 進(jìn)行分析。

血淚教訓(xùn)

當(dāng)天忽略了堆棧日志，過多的關(guān)注在gc上。

排查問題的思維定式，排查思路和實(shí)際執(zhí)行不嚴(yán)謹(jǐn)，以致于錯過問題根源。

運(yùn)行了幾年的代碼都沒出問題，不代表代碼本身沒問題，以堆棧日志和gc日志為準(zhǔn)。

根本原因就是數(shù)據(jù)庫臟數(shù)據(jù)觸發(fā)了代碼中一個死循環(huán)bug(運(yùn)行了一年才發(fā)現(xiàn)，也是醉了)

總結(jié)

以上是生活随笔為你收集整理的记一次线上cpu飙升100%的排查过程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。