使用 man ascii 来查看 ASCII 表。

gc异常 : survivor区溢出,gc一直打印日志

Elasticsearch | 作者 jzy_10086 | 发布于2019年12月06日 | 阅读数:2476

ES版本:
6.3.1服务器配置: 
4个node* 8核32G,2T/6T的磁盘使用量。 
jvm配置:
-Xmx16g  -Xms16g 其它配置不变
GC类型:
CMS
问题综述:
年轻代和老年代都没有溢出,就是年轻代中的survior区一直处于溢出状态,并且gc一直在打印日志。
已经尝试过的失败方法如下:
1. 更换GC类型从 cms -> G1GC, 问题依旧存在。
2. 提升年轻代和survivor区的大小,从64MB依次提升到200MB和600MB,发现问题依旧存在,不是提高存活区大小可以解决的,说明问题不简单。
【具体错误日志如下图】分别为ES日志和GC日志

1575628604(1).jpg

 
查看ES日志发现: 年轻和老年代GC回收都正常,但是存活区出现异常。

1575628811(1).jpg

 
查看GC日志发现: 无论如何提高存活区的内存大小,都会出现溢出的情况。
 
这个问题困扰了很久了。希望有大佬能够给出解决思路和方案。
有偿请教。可以加我微信 w63594021
 
已邀请:

huangmingzhi - 90后 搜索

赞同来自:

不能算溢出吧  看起来比较像生成对象比较大  在年轻代回收的时候放不下  放到老年代了

hapjin

赞同来自:

从ES打印的日志看,是正常的。
就拿你用红线框出来的那条记录,内存总量是15.8G(Xms=Xmx=16G) ES进程使用了11.9G内存,发生了一次YGC后,ES进程使用11.3G,回收了0.6G
这次YGC后:
新生代从1.3G回收之后,剩下 30.8M(容量是1.6G),其中一个survivor区内存使用不变,还是204.7M,说明没有回收这个survivor区,而不是survivor区溢出了。
老年代从原来的10.4G变成了11G,说明有些对象晋升到老年代去了。
 
PS:新生代=eden+s1+s2。
 
找到你的ES进程,然后 jmap -heap ES_PID   看看你的suvivor区容量是多大,使用了多少?

要回复问题请先登录注册