鍍金池/ 問答/Java  C/ 線上FullGC頻繁,old區(qū)下不去

線上FullGC頻繁,old區(qū)下不去

問題:
線上一個(gè)服務(wù),跑了一個(gè)月挺正常的,這兩天突然頻繁FULLGC報(bào)警,因?yàn)閒gc頻繁會(huì)影響服務(wù)使用,而且報(bào)警太頻繁了我就先重啟系統(tǒng)了。下面是我自己排查過程的一些記錄截圖:
首先我先看了下系統(tǒng)內(nèi)存和負(fù)載概況:
200327_uNx7_2320871.png

然后看一下我應(yīng)用啟動(dòng)參數(shù):
200517_4FTh_2320871.png

重要的是JAVA_OPS, 文字放一下:-Xms4g -Xmx4g -Xmn2g -Xss1024K -XX:MetaspaceSize=64m -XX:MaxMetaspaceSize=256m -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseCMSCompactAtFullCollection -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 -XX:CMSInitiatingOccupancyFraction=80 -XX:+PrintGCDetails -XX:+PrintGCDateStamps

jstat -gc 看了一下(因?yàn)椴]有打印gc日志到文件中,所以只能通過這種方式觀察了)
201020_2nrj_2320871.png

可以看到最后倒數(shù)第三列是FGC的次數(shù),幾秒鐘之內(nèi)確實(shí)長得比較快,按理說fgc應(yīng)該一天都不會(huì)出現(xiàn)幾次的。第八列是老年代使用的情況(截圖的時(shí)候已經(jīng)過了一段時(shí)間了實(shí)際上1400000 多的時(shí)候FGC就開始漲了),F(xiàn)GC次數(shù)上漲而已使用空間不下降,說明FGC并沒有有效的釋放內(nèi)存。

map -heap 的狀態(tài):

201539_5REO_2320871.png

網(wǎng)上說對(duì)象太多,看看都是什么對(duì)象太大了,于是我又jmap -histo了一下,發(fā)現(xiàn)[C占得比重最大(這個(gè)是字符數(shù)組吧,其實(shí)就應(yīng)該是字符串吧):

201953_uWtR_2320871.png

這個(gè)服務(wù)是操作elasticsearch的rpc服務(wù),(不是dubbo,公司內(nèi)部的一個(gè)rpc框架),調(diào)用方通過我的接口對(duì)es增刪改查。我將返回的數(shù)據(jù)通過fastjson解析最后返回給調(diào)用方。代碼里沒有靜態(tài)集合(類似static Map<String,Object> 這種對(duì)象),qps高峰期達(dá)到370/s,晚上低峰期也就30-50/s.之前出現(xiàn)過一次高頻fullgc,我去掉了一些多余的日志輸出,結(jié)果還是出來了。

求解決辦法,還要從哪里著手排查呢

回答
編輯回答
愛是癌

sf上難得的好問題,你貼的信息還不夠全,在發(fā)生full gc的時(shí)候,登上機(jī)器用top -H找到最忙的線程pid,再用jstack dump當(dāng)時(shí)的線程快照,把這個(gè)貼上來,還有開啟gc.log會(huì)有更多的現(xiàn)場信息,看看具體是哪塊不夠觸發(fā)了fullgc。單純的看你描述的問題來看,有點(diǎn)像某些邏輯存在內(nèi)存泄露,就算fullgc了也趕不上內(nèi)存增長的速度。

2017年7月3日 07:49
編輯回答
萌吟

對(duì)了順便說一下,gc日志我這個(gè)應(yīng)用沒打,但是看別的應(yīng)用是有的,我就看了一下發(fā)現(xiàn)他們的應(yīng)用通過jstat -gc 觀察到 FGC這一列也出現(xiàn)了幾百次了(跑了幾個(gè)月的),但是gc.log日志里面絲毫沒有fullgc的字樣,只有一些 cms-current-sweep-start 這種,有點(diǎn)糊涂,F(xiàn)GC這一列到底是不是代表著fullgc次數(shù)呢?

2017年7月29日 22:45
編輯回答
不二心

跟我們之前用solr好像 一個(gè)問題 關(guān)注下 可以在方法中將es查詢出來的對(duì)象手動(dòng)賦值null 試試

2017年1月3日 19:57