又是一個(gè)百無聊賴的早晨,我在快樂地摸魚,工作群響了:離線系統(tǒng)登錄不上了。我第一反應(yīng)是不科學(xué)啊,系統(tǒng)已經(jīng)很久改動(dòng)過了...趕緊上生產(chǎn)環(huán)境看看,CPU高達(dá)1200%。接著又是熟練地敲出那幾行排查CPU過高的命令
top-H-ppid查看java占用率最高的幾條線程 jstackpid>xxx.txt打印線程快照 jmap-heappid查看堆內(nèi)存情況top命令 jstack命令 jmap命令
看這玩意啥都看不出來,感覺是系統(tǒng)對(duì)象沒有釋放,在瘋狂GC,但是因?yàn)镕ULL GC的時(shí)候已經(jīng)STW了,所以無法查看到底是哪個(gè)線程出了問題。然后過了10分鐘系統(tǒng)突然又好了....堵塞的操作已經(jīng)完成,gc能正常回收了。
然后過了兩分鐘又卡死了,我先重啟了系統(tǒng),后面再分析分析。
等系統(tǒng)沒什么人用的時(shí)候,我再試著重現(xiàn)一下問題,打開系統(tǒng)一頓亂點(diǎn),結(jié)果是點(diǎn)開某個(gè)功能的詳情時(shí)系統(tǒng)卡住了,CPU又飚上去了,喜聞樂見~問題定位到了,再實(shí)錘一下之前是不是這個(gè)問題,我看了一下localhost_access_log日志發(fā)現(xiàn),確實(shí)是這個(gè)接口卡了一千多秒。
nginx日志
因?yàn)殡x線沒什么人使用,所以問題過了很久再暴露出來。看了一下代碼,主要是同事業(yè)務(wù)邏輯問題,有個(gè)參數(shù)沒傳進(jìn)去,導(dǎo)致 sql 走了全表掃描,數(shù)據(jù)很多,要查很久,查到了幾百萬的數(shù)據(jù),gc 也無法回收。
還好內(nèi)存夠大,要不然早就 OOM 了。
復(fù)盤
一開始我以為是某個(gè)接口調(diào)了很多次并發(fā)太高導(dǎo)致的,沒想到點(diǎn)一下詳情系統(tǒng)就掛了。。我們可以看到CPU在GC回收的時(shí)候STW,是沒有線程能占用到CPU的,所以top -H -p pid 只能看到CPU全被GC線程占用了。如果是某個(gè)接口并發(fā)太高導(dǎo)致的,我們可以看jstack線程快照,里面是會(huì)有這個(gè)接口在執(zhí)行的記錄。
還有一個(gè)問題就是說系統(tǒng)GC卡了10-20分鐘,卻沒有報(bào)OOM,還是一直在堵塞狀態(tài),后面還正常了一小會(huì),這個(gè)是需要看堆內(nèi)存的情況...
因?yàn)楸容^難排查所以只是通過現(xiàn)象知道GC還是可以回收一點(diǎn)點(diǎn)垃圾的
總結(jié)
1、CPU100%的時(shí)候可以打印線程快照jstack pid,查看是哪個(gè)線程占用了CPU,一般都是某個(gè)業(yè)務(wù)線程阻塞無法進(jìn)行GC回收導(dǎo)致。
2、可以查看localhost_access_log查看系統(tǒng)接口用時(shí),一般用時(shí)很久的都是有問題的接口。
3、同事的業(yè)務(wù)代碼參數(shù)沒有傳,導(dǎo)致全表掃描直接卡死系統(tǒng)。
審核編輯:湯梓紅
-
cpu
+關(guān)注
關(guān)注
68文章
10854瀏覽量
211587 -
內(nèi)存
+關(guān)注
關(guān)注
8文章
3019瀏覽量
74005 -
命令
+關(guān)注
關(guān)注
5文章
683瀏覽量
22011 -
代碼
+關(guān)注
關(guān)注
30文章
4779瀏覽量
68525 -
nginx
+關(guān)注
關(guān)注
0文章
149瀏覽量
12170
原文標(biāo)題:點(diǎn)一下詳情系統(tǒng)掛了,CPU 100%
文章出處:【微信號(hào):芋道源碼,微信公眾號(hào):芋道源碼】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論