點一下詳情系統(tǒng)掛了,CPU100%

你知道的越多，不知道的就越多，業(yè)余的像一棵小草！

你來，我們一起精進(jìn)！你不來，我和你的競爭對手一起精進(jìn)！

編輯：業(yè)余草

來源：juejin.cn/post/7233307834456129593

推薦：h ttps://www.xttblog.com/?p=5364

自律才 能自由！讓進(jìn)步發(fā)生！

又是一個百無聊賴的早晨，我在快樂地摸魚，工作群響了：離線系統(tǒng)登錄不上了。我第一反應(yīng)是不科學(xué)啊，系統(tǒng)已經(jīng)很久改動過了...趕緊上生產(chǎn)環(huán)境看看，CPU高達(dá)1200%。接著又是熟練地敲出那幾行排查CPU過高的命令

      
      top?-H?-p??pid查看java占用率最高的幾條線程
jstack?pid?>??xxx.txt???打印線程快照
jmap?-heap?pid???查看堆內(nèi)存情況

    

看這玩意啥都看不出來，感覺是系統(tǒng)對象沒有釋放，在瘋狂GC，但是因為FULL GC的時候已經(jīng)STW了，所以無法查看到底是哪個線程出了問題。然后過了10分鐘系統(tǒng)突然又好了....堵塞的操作已經(jīng)完成，gc能正?；厥樟恕?/p>

然后過了兩分鐘又卡死了，我先重啟了系統(tǒng)，后面再分析分析。

等系統(tǒng)沒什么人用的時候，我再試著重現(xiàn)一下問題，打開系統(tǒng)一頓亂點，結(jié)果是點開某個功能的詳情時系統(tǒng)卡住了，CPU又飚上去了，喜聞樂見~問題定位到了，再實錘一下之前是不是這個問題，我看了一下localhost_access_log日志發(fā)現(xiàn)，確實是這個接口卡了一千多秒。

因為離線沒什么人使用，所以問題過了很久再暴露出來。看了一下代碼，主要是同事業(yè)務(wù)邏輯問題，有個參數(shù)沒傳進(jìn)去，導(dǎo)致 sql 走了全表掃描，數(shù)據(jù)很多，要查很久，查到了幾百萬的數(shù)據(jù)，gc 也無法回收。

還好內(nèi)存夠大，要不然早就 OOM 了。

復(fù)盤

一開始我以為是某個接口調(diào)了很多次并發(fā)太高導(dǎo)致的，沒想到點一下詳情系統(tǒng)就掛了。。我們可以看到CPU在GC回收的時候STW，是沒有線程能占用到CPU的，所以top -H -p pid 只能看到CPU全被GC線程占用了。如果是某個接口并發(fā)太高導(dǎo)致的，我們可以看jstack線程快照，里面是會有這個接口在執(zhí)行的記錄。

還有一個問題就是說系統(tǒng)GC卡了10-20分鐘，卻沒有報OOM，還是一直在堵塞狀態(tài)，后面還正常了一小會，這個是需要看堆內(nèi)存的情況...

因為比較難排查所以只是通過現(xiàn)象知道GC還是可以回收一點點垃圾的

總結(jié)

1、CPU100%的時候可以打印線程快照jstack pid，查看是哪個線程占用了CPU，一般都是某個業(yè)務(wù)線程阻塞無法進(jìn)行GC回收導(dǎo)致。

2、可以查看localhost_access_log查看系統(tǒng)接口用時，一般用時很久的都是有問題的接口。

3、同事的業(yè)務(wù)代碼參數(shù)沒有傳，導(dǎo)致全表掃描直接卡死系統(tǒng)。