hhg-2015

现状:

k8s 的一个pod 有32G内存,每秒产生新对象的峰值在900Mb ---- 1900Mb(根据jstat计算Eden区获得) 。

修改之前的参数

 

就一个命令行参数是-Xmx31g;

我修改为:

-Xms:30g

-Xmx:30g

-Xmn:15g

-XX:SurvivorRatio=6

以上目的是为了减少年轻代GC频率(由6秒1次 增加到10+秒一次),让Queue队列中的大对象在to区停留的更长。同时,由于队列的大对象紧到不死,通常存活的对象空间就>to区(s0、s1)空间,被移到了老年代。 不过,结果还是失败了,如下两图:

 

 

 

 

 

 

 理论上来说,图1中pod启动后就存在4次fgc,9万秒后进行正经的第一次fgc,居然没有作用,直接OOM。

再改为简单的:

-Xms:30g

-Xmx:30g

其默认O区20G,N区10G。继续观察,这一次fgc成功了,但O区有剩余空间后仍然显示因OOM重启服务。

 

 

 

我只好推测是:虚拟机的问题,parallel gc 在回收时应该stw, 回收后有空间的,jvm那一瞬间却认为没有。

特喵的跟我理论知识冲突了/ 进入知识盲区了,说好的fgc 有效呢,最大=最小堆内存 有助于降低性能消耗……。

在官网VM Options 没有找到Old达到一定70%阈值使用率时,触发1次OOM的参数。 CMS回收器倒是有,可不适合我们高吞吐量的服务器需要。

 

于是我修改为:

-Xms:30g

-Xmx:15g

作用几乎没有,最多减少因初始512M堆内存 面对大量新对象重启后没几分钟直接OOM的次数。

 一次失败的处理,只让我加深了各JVM参数的印象。

 

各位达者,若有什么建议请留言下方。

 

分类:

Java

技术点:

相关文章: