linux环境mule JVM短生命周期对象性能调整

最近，在一项目上，发现后端mule es  cpu耗用高。经过jstat -gcutil jvm进程号 1000 10分析，发现FGC次数，较多。

根据gc观察，O老生代，经过达到80% 以上。而新生代survior s1,s2内存空间比较小。判断有新生代对象没经过几次gc，就进入了老生代。

修改mule/conf/wrapper.conf .增加如下选择。

wrapper.java.additional.5=-XX:+PrintGCDetails
wrapper.java.additional.6=-XX:+PrintGCDateStamps
wrapper.java.additional.7=-verbose:gc
wrapper.java.additional.8=-Xloggc:gc.log
wrapper.java.additional.9=-XX:ParallelGCThreads=10
wrapper.java.additional.10=-XX:+UseConcMarkSweepGC
wrapper.java.additional.11=-XX:+UseParNewGC
wrapper.java.additional.12=-XX:NewRatio=3
wrapper.java.additional.13=-Xss256K
wrapper.java.additional.14=-XX:SurvivorRation=2
wrapper.java.additional.15=-XX:TargetSurvivorRatio=8

NewRatio=3属性增加新生代大小。年轻代(Eden和两个Survivor与年老代的比值），年轻代为堆的1/4大小。

-XX:SurvivorRatio=2      Eden区与Survivor区的大小比值。代表Eden区为2/10，survivor是8/10.survivor存储Eden快速回收后的数据，survivor适当调高有利于缓解经几次fast gc后，才会回收的对象，这些对象经过几次gc,是可以回收掉的。如果survior太小，则经过一两次回收，由于survivor空间过小，则会直接进入Old代。如果适中，在经过几次gc后，回收掉。不用在放入old代。经几次回收才能释放的对象，可以理解为中短期生命周期对象，它是有机会回收，但需要其它依赖释放引用。

参考文献：

 JVM实用参数（五）新生代垃圾回收

http://ifeve.com/useful-jvm-flags-part-5-young-generation-garbage-collection