背景
最近系统的用户使用越来越多，随之而来的情况导致系统在运行一段时间后开始出现fgc（频次大约1天2次），cms作为高响应速度的collector，一般我们会尽量避免出现remark或者尽量减低remark的时间（remark阶段会出现stop the world）
我们关注一下zabbix的内存监控图
注:系统为jdk7
162655_foJz_871390.png
162705_NxBD_871390.png
如上两张图分别对应堆内存的使用和老年代的使用
从上图可以看出，基本上minor gc比较频繁（第一张的锯齿），并没有出现内存泄露（第一张图在fgc的回收下内存占用几乎不变）
那么出现一次较大的fgc的原因是什么呢？
我们参看一下当前系统的情况
162718_sfvm_871390.png
小知识，cms在一次remark前后各算一次fgc
162724_9Aio_871390.png
基本看出老年代使用并不高，而年轻代比较小，伊甸园去仅为209m ，幸存者区域约为26m（换句话说，一次晋升最多可能晋升26+209M）
162738_9vQ6_871390.png
我们看到此次晋升失败，而老年代从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的内存使用图如下（最后一天）
163057_YoLY_871390.png
基本上可以在老年代达到一定容量时就回收掉，同时stw时间明显降低
163118_3JFr_871390.png
原来统计从运行3天暂停8s降低 到运行1天 暂停0.082s
younggc的频率也有所下降，时间也缩短。
网友评论