背景

最近系统的用户使用越来越多，随之而来的情况导致系统在运行一段时间后开始出现fgc（频次大约1天2次），cms作为高响应速度的collector，一般我们会尽量避免出现remark或者尽量减低remark的时间（remark阶段会出现stop the world）

我们关注一下zabbix的内存监控图

注:系统为jdk7

如上两张图分别对应堆内存的使用和老年代的使用

从上图可以看出，基本上minor gc比较频繁（第一张的锯齿），并没有出现内存泄露（第一张图在fgc的回收下内存占用几乎不变）

那么出现一次较大的fgc的原因是什么呢？

我们参看一下当前系统的情况

小知识，cms在一次remark前后各算一次fgc

基本看出老年代使用并不高，而年轻代比较小，伊甸园去仅为209m ，幸存者区域约为26m（换句话说，一次晋升最多可能晋升26+209M）

我们看到此次晋升失败，而老年代从2.3g直接fullgc到了500m，存在1.8g的内存回收。中断时间约为2.69s

初步考虑内存分配不合理导致年轻代过小，出现多次的minor gc（minor gc的频率直接决定了对象的年龄，而年龄又决定了晋升到老年代的时机）-XX:MaxTenuringThreshold 最大为15

查看一下我们的jvm参数

/usr/java/jdk1.7.0_80/bin/java -Djava.util.logging.config.file=/mnt/apache-tomcat-7.0.70-erp/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djdk.tls.ephemeralDHKeySize=2048 -Xms2048m -Xmx3072m -XX:PermSize=128m -XX:MaxNewSize=256m -XX:MaxPermSize=256m -XX:ParallelGCThreads=4 -XX:+UseConcMarkSweepGC -Xloggc:/mnt/apache-tomcat-7.0.70-erp/logs/gc.log -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+DisableExplicitGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/mnt/apache-tomcat-7.0.70-erp -Djava.endorsed.dirs=/mnt/apache-tomcat-7.0.70-erp/endorsed -classpath /mnt/apache-tomcat-7.0.70-erp/bin/bootstrap.jar:/mnt/apache-tomcat-7.0.70-erp/bin/tomcat-juli.jar -Dcatalina.base=/mnt/apache-tomcat-7.0.70-erp -Dcatalina.home=/mnt/apache-tomcat-7.0.70-erp -Djava.io.tmpdir=/mnt/apache-tomcat-7.0.70-erp/temp org.apache.catalina.startup.Bootstrap start复制代码

WTF 居然设置了-XX:MaxNewSize为256m，那么默认的surviorRatio为8 也就是 s0=25.6m s1=25.6m eden=204.8m

为了减低cms在gc时remark时间考虑调大年轻代，这样对象分配时在年轻代，由于年轻代足够大，不会频繁发生minor gc，这样对象的年龄不会变大的太快。所以需要设置合理的newRatio。

export CATALINA_OPTS="$CATALINA_OPTS -Xms2048m -Xmx3072m -XX:PermSize=128m -XX:NewRatio=3 -XX:MaxPermSize=256m -XX:CMSInitiatingOccupancyFraction=72 -XX:ParallelGCThreads=4 -XX:+UseConcMarkSweepGC -Xloggc:/mnt/apache-tomcat-7.0.70-erp/logs/gc.log -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+DisableExplicitGC  -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/mnt/apache-tomcat-7.0.70-erp"复制代码

将年轻代设置为512m~768m

同时加上-XX:CMSInitiatingOccupancyFraction

该参数表示在老年代达到72%时将强行发生fgc，优先回收内存，以防止出现年轻代晋升失败的情况。

年轻代晋升失败条件如下（不考虑内存碎片）：

幸存者+伊甸园区<老年代剩余

采用默认比例 surviorRatio 为8

此处newRatio为3

公式为

    (1+surviorRatio)/(2+surviorRatio)*new <=old*(1-CMSInitiatingOccupancyFraction/100) 复制代码

得出CMSInitiatingOccupancyFraction约为70 此处使用72(经验值)

原先设置年轻代大小应该是老的jvm参数，当修改了xmx之后没有更新该值，导致年轻代过小

因此此处考虑使用ratio

以观后效

经过改造目前zabbix的内存使用图如下（最后一天）

基本上可以在老年代达到一定容量时就回收掉，同时stw时间明显降低

原来统计从运行3天暂停8s降低到运行1天暂停0.082s

younggc的频率也有所下降，时间也缩短。