JVM系列:JVM内存优化建议

优化原则

JAVA程序在运行时

  1. 加快GC速度
  2. 减少FullGC
  3. 减少停顿
  4. 杜绝GC出错

    GC优化的策略本质上JVM运行中通过参数的变换调和达到运行平衡的过程。it is an art.

经验配置

垃圾搜集器

新生代收集器:有Serial收集器、ParNew收集器、Parallel Scavenge收集器
老生代收集器:Serial Old收集器、Parallel Old收集器、CMS收集器、G1收集器
以上所有的垃圾收集器都会发生STW,只不过FGC的STW时间更长。

常用搜集器:
  • CMSGC
    CMS(Concurrent Mark-Sweep)是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器。对于要求服务器响应速度的应用上,这种垃圾回收器非常适合,因此我们又叫它低延迟垃圾收集器。在启动JVM参数加上-XX:+UseConcMarkSweepGC ,这个参数表示对于老年代的回收采用CMS,注意此时新生代默认使用的是ParNew。CMS采用的基础算法是:标记—清除。
  • MSCGC vs CMSGC
    和普通序列化整理(MSC)区别在于有三个mark阶段(实际上还有个预清理过程,但对于解释清楚CMSGC没有帮助就忽略了)。CMSGC的精髓在于因为做到了不STW的情况下进行mark,我们得到了更短的总STW时间,代价是因为并行mark产生了『脏数据』即在mark的同时又生成了需要mark的对象,我们必须再进行一次STW,并收尾(remark)。
    同时,我们要注意到得到更短的STW的同时,我们牺牲了系统吞吐量,CMSGC总吞吐量比ParOld要更低。
  • G1GC
    作为最新的垃圾收集器,有可能在jdk9中成为默认的垃圾收集器。
    主要思路是将新生代老生代进一步分为多个region,每次gc可以针对部分region而不是整个堆内存。由此可以降低stw的单次最长时间,代价是可能在总时间上会更高。
    G1GC让系统在整体吞吐量略降的情况下变得更加平滑稳定。

响应时间优先的应用

  • 年轻代选择
    尽可能设大,直到接近系统的最低响应时间限制(根据实际情况选择).在此种情况下,年轻代收集发生的频率也是最小的.同时,减少到达年老代的对象.
  • 年老代选择
    年老代使用并发收集器,所以其大小需要小心设置,一般要考虑并发会话率和会话持续时间等一些参数.如果堆设置小了,可以会造成内存碎片,高回收频率以及应用暂停而使用传统的标记清除方式;如果堆大了,则需要较长的收集时间.最优化的方案,一般需要参考以下数据获得:
    1. 并发垃圾收集信息.
    2. 持久代并发收集次数.
    3. 传统GC信息.
    4. 花在年轻代和年老代回收上的时间比例。

吞吐量优先的应用

  • 年轻代选择
    尽可能的设置大,可能到达Gbit的程度.因为对响应时间没有要求,垃圾收集可以并行进行,一般适合8CPU以上的应用.
    避免设置过小.当新生代设置过小时会导致:
    1. YGC次数更加频繁
    2. 可能导致YGC对象直接进入旧生代,如果此时旧生代满了,会触发FGC.
  • 年老代选择
    一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代.这样可以尽可能回收掉大部分短期对象,减少中期的对象,而年老代尽存放长期存活对象.

碎片问题

因为年老代的并发收集器使用标记,清除算法,所以不会对堆进行压缩.当收集器回收时,他会把相邻的空间进行合并,这样可以分配给较大的对象.但是,当堆空间较小时,运行一段时间以后,就会出现”碎片”,如果并发收集器找不到足够的空间,那么并发收集器将会停止,然后使用传统的标记,清除方式进行回收.如果出现”碎片”,可能需要进行如下配置:

-XX:+UseCMSCompactAtFullCollection:使用并发收集器时,开启对年老代的压缩.
-XX:CMSFullGCsBeforeCompaction=0:上面配置开启的情况下,这里设置多少次Full GC后,对年老代进行压缩

promotion failed问题

可能是两种原因产生:
1. 第一个原因是救助空间不够,救助空间里的对象还不应该被移动到年老代,但年轻代又有很多对象需要放入救助空间。
2. 第二个原因是年老代没有足够的空间接纳来自年轻代的对象;这两种情况都会转向Full GC,网站停顿时间较长。

用64位操作系统,Linux下64位的jdk比32位jdk要慢一些,但是吃得内存更多,吞吐量更大
XMX和XMS设置一样大,MaxPermSize和MinPermSize设置一样大,这样可以减轻伸缩堆大小带来的压力

  • 使用CMS的好处是用尽量少的新生代,经验值是128M-256M, 老生代利用CMS并行收集,这样能保证系统低延迟的吞吐效率。
  • cms的收集停顿时间非常的短,2G的内存, 大约20-80ms的应用程序停顿时间
    系统停顿的时候可能是GC的问题也可能是程序的问题,多用jmap和jstack查看,或者killall -3 java,然后查看java控制台日志,能看出很多问题。
  • 如果用了缓存,那么年老代应该大一些,缓存的HashMap不应该无限制长,建议采用LRU算法的Map做缓存,LRUMap的最大长度也要根据实际情况设定。
  • 采用并发回收时,年轻代小一点,年老代要大,因为年老大用的是并发回收,即使时间长点也不会影响其他程序继续运行,网站不会停顿
    JVM参数的设置(特别是 –Xmx –Xms –Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold等参数的设置没有一个固定的公式,需要根据PV old区实际数据 YGC次数等多方面来衡量。为了避免promotion faild可能会导致xmn设置偏小,也意味着YGC的次数会增多,处理并发访问的能力下降等问题。每个参数的调整都需要经过详细的性能测试,才能找到特定应用的最佳配置。

解决方方案一:
第一个原因最终解决办法是去掉救助空间,设置-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可,
第二个原因我的解决办法是设置CMSInitiatingOccupancyFraction为某个值(假设70),这样年老代空间到70%时就开始执行CMS,年老代有足够的空间接纳来自年轻代的对象。
解决方案一的改进方案:

又有改进了,上面方法不太好,因为没有用到救助空间,所以年老代容易满,CMS执行会比较频繁。我改善了一下,还是用救助空间,但是把救助空间加大,这样也不会有promotion failed。具体操作上,32位Linux和64位Linux好像不一样,64位系统似乎只要配置MaxTenuringThreshold参数,CMS还是有暂停。为了解决暂停问题和promotion failed问题,最后我设置-XX:SurvivorRatio=1 ,并把MaxTenuringThreshold去掉,这样即没有暂停又不会有promotoin failed,而且更重要的是,年老代和永久代上升非常慢(因为好多对象到不了年老代就被回收了),所以CMS执行频率非常低,好几个小时才执行一次,这样,服务器都不用重启了。

-Xmx4000M -Xms4000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log

CMSInitiatingOccupancyFraction值与Xmn的关系公式

上面介绍了promontion faild产生的原因是EDEN空间不足的情况下将EDEN与From survivor中的存活对象存入To survivor区时,To survivor区的空间不足,再次晋升到old gen区,而old gen区内存也不够的情况下产生了promontion faild从而导致full gc.那可以推断出:eden+from survivor < old gen区剩余内存时,不会出现promontion faild的情况,即:
(Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2)) 进而推断出:

CMSInitiatingOccupancyFraction <=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100

例如:

当xmx=128 xmn=36 SurvivorRatior=1时 CMSInitiatingOccupancyFraction<=((128.0-36)-(36-36/(1+2)))/(128-36)*100 =73.913

当xmx=128 xmn=24 SurvivorRatior=1时 CMSInitiatingOccupancyFraction<=((128.0-24)-(24-24/(1+2)))/(128-24)*100=84.615…

当xmx=3000 xmn=600 SurvivorRatior=1时 CMSInitiatingOccupancyFraction<=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33

CMSInitiatingOccupancyFraction低于70% 需要调整xmn或SurvivorRatior值。

令:

网上一童鞋推断出的公式是::(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn 这个公式个人认为不是很严谨,在内存小的时候会影响xmn的计算。

参考:
http://www.cnblogs.com/redcreen/archive/2011/05/05/2038331.html
http://www.jianshu.com/p/c9ac99b87d56