JVM调优的几种方式（转）

JVM参数调优是一个很头痛的问题，可能和应用有关系，别人说可以的对自己不一定管用。下面是本人一些JVM调优的实践经验，希望对读者能有帮助，环境LinuxAS4,resin2.1.17,JDK6.0,2CPU,4G内存，dell2950服务器。
JVM调优
一：JVM调优之串行垃圾回收
也就是默认配置，完成10万request用时153秒。JVM参数配置如下：

    $JAVA_ARGS.=“-Dresin.home=$SERVER_ROOT-server
    
    -Xms2048M-Xmx2048M-Xmn512M
    
    -XX:PermSize=256M-XX:MaxPermSize=256M
    
    -XX:MaxTenuringThreshold=7-XX:GCTimeRatio=19
    
    -Xnoclassgc-Xloggc:log/gc.log
    
    -XX:+PrintGCDetails-XX:+PrintGCTimeStamps”;

这种配置一般在resin启动24小时内似乎没有大问题，网站可以正常访问，但查看日志发现，在接近24小时时，FullGC执行越来越频繁，大约每隔3分钟就有一次FullGC,每次FullGC系统会停顿6秒左右，作为一个网站来说，用户等待6秒恐怕太长了，所以这种方式有待改善。MaxTenuringThreshold=7表示一个对象如果在救助空间移动7次还没有被回收就放入年老代，GCTimeRatio=19表示java可以用5%的时间来做垃圾回收，1/（1+19）=1/20=5%.

二：JVM调优之并行回收

完成10万request用时117秒，配置如下：

$JAVA_ARGS.=“-Dresin.home=$SERVER_ROOT-server-Xmx2048M

-Xms2048M-Xmn512M-XX:PermSize=256M-XX:MaxPermSize=256M

-Xnoclassgc-Xloggc:log/gc.log-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps-XX:+UseParallelGC-XX:ParallelGCThreads=20

-XX:+UseParallelOldGC-XX:MaxGCPauseMillis=500

-XX:+UseAdaptiveSizePolicy-XX:MaxTenuringThreshold=7

-XX:GCTimeRatio=19”;

并行回收我尝试过多种组合配置，似乎都没什么用，resin启动3小时左右就会停顿，时间超过10秒。也有可能是参数设置不够好的原因，MaxGCPauseMillis表示GC最大停顿时间，在resin刚启动还没有执行FullGC时系统是正常的，但一旦执行FullGC,MaxGCPauseMillis根本没有用，停顿时间可能超过20秒，之后会发生什么我也不再关心了，赶紧重启resin,尝试其他回收策略。

三：JVM调优之并发回收

完成10万request用时60秒，比并行回收差不多快一倍，是默认回收策略性能的2.5倍，配置如下：

$JAVA_ARGS.=“-Dresin.home=$SERVER_ROOT-server

-Xms2048M-Xmx2048M-Xmn512M-XX:PermSize=256M

-XX:MaxPermSize=256M-XX:+UseConcMarkSweepGC

-XX:MaxTenuringThreshold=7-XX:GCTimeRatio=19

-Xnoclassgc-Xloggc:log/gc.log-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps-XX:+UseCMSCompactAtFullCollection

-XX:CMSFullGCsBeforeCompaction=0”;

这个配置虽然不会出现10秒连不上的情况，但系统重启3个小时左右，每隔几分钟就会有5秒连不上的情况，查看gc.log,发现在执行ParNewGC时有个promotionfailed错误，从而转向执行FullGC,造成系统停顿，而且会很频繁，每隔几分钟就有一次，所以还得改善。UseCMSCompactAtFullCollection是表是执行FullGC后对内存进行整理压缩，免得产生内存碎片，CMSFullGCsBeforeCompaction=N表示执行N次FullGC后执行内存压缩。

四：JVM调优之增量回收

完成10万request用时171秒，太慢了，配置如下：

$JAVA_ARGS.=“-Dresin.home=$SERVER_ROOT-server

-Xms2048M-Xmx2048M-Xmn512M-XX:PermSize=256M

-XX:MaxPermSize=256M-XX:MaxTenuringThreshold=7

-XX:GCTimeRatio=19-Xnoclassgc-Xloggc:log/gc.log

-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-Xincgc”;

似乎回收得也不太干净，而且也对性能有较大影响，不值得试。

五：JVM调优之并发回收的I-CMS模式

和增量回收差不多，完成10万request用时170秒。配置如下：

$JAVA_ARGS.=“-Dresin.home=$SERVER_ROOT-server

-Xms2048M-Xmx2048M-Xmn512M-XX:PermSize=256M

-XX:MaxPermSize=256M-XX:MaxTenuringThreshold=7

-XX:GCTimeRatio=19-Xnoclassgc-Xloggc:log/gc.log

-XX:+PrintGCDetails-XX:+PrintGCTimeStamps

-XX:+UseConcMarkSweepGC-XX:+CMSIncrementalMode

-XX:+CMSIncrementalPacing

-XX:CMSIncrementalDutyCycleMin=0

-XX:CMSIncrementalDutyCycle=10-XX:-TraceClassUnloading”;

采用了sun推荐的参数，回收效果不好，照样有停顿，数小时之内就会频繁出现停顿，什么sun推荐的参数，照样不好使。

六：JVM调优之递增式低暂停收集器

又叫什么火车式回收，完成10万request用时153秒，配置如下：

$JAVA_ARGS.=“-Dresin.home=$SERVER_ROOT-server

-Xms2048M-Xmx2048M-Xmn512M-XX:PermSize=256M

-XX:MaxPermSize=256M-XX:MaxTenuringThreshold=7

-XX:GCTimeRatio=19-Xnoclassgc-Xloggc:log/gc.log

-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+UseTrainGC”;

该配置效果也不好，影响性能，所以没试。

七：相比之下，还是并发回收比较好，性能比较高，只要能解决ParNewGC（并行回收年轻代）时的promotionfailed错误就一切好办了，查了很多文章，发现引起promotionfailed错误的原因是CMS来不及回收（CMS默认在年老代占到90%左右才会执行），年老代又没有足够的空间供GC把一些活的对象从年轻代移到年老代，所以执行FullGC.CMSInitiatingOccupancyFraction=70表示年老代占到约70%时就开始执行CMS,这样就不会出现FullGC了。SoftRefLRUPolicyMSPerMB这个参数也是我认为比较有用的，官方解释是softlyreachableobjectswillremainaliveforsomeamountoftimeafterthelasttimetheywerereferenced.Thedefaultvalueisonesecondoflifetimeperfreemegabyteintheheap,我觉得没必要等1秒，所以设置成0.配置如下

$JAVA_ARGS.=“-Dresin.home=$SERVER_ROOT-server-Xms2048M

-Xmx2048M-Xmn512M-XX:PermSize=256M-XX:MaxPermSize=256M

-XX:SurvivorRatio=8-XX:MaxTenuringThreshold=7

-XX:GCTimeRatio=19-Xnoclassgc-XX:+DisableExplicitGC

-XX:+UseParNewGC-XX:+UseConcMarkSweepGC

-XX:+CMSPermGenSweepingEnabled

-XX:+UseCMSCompactAtFullCollection

-XX:CMSFullGCsBeforeCompaction=0

-XX:+CMSClassUnloadingEnabled-XX:-CMSParallelRemarkEnabled

-XX:CMSInitiatingOccupancyFraction=70

-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram

-XX:+PrintGCDetails-XX:+PrintGCTimeStamps

-XX:+PrintGCApplicationConcurrentTime

-XX:+PrintGCApplicationStoppedTime

-Xloggc:log/gc.log”;

上面这个配置内存上升的很慢，24小时之内几乎没有停顿现象，最长的只停滞了0.8s,ParNewGC每30秒左右才执行一次，每次回收约0.2秒，看来问题应该暂时解决了。

https://www.cnblogs.com/softidea/p/4043770.html