JVM系统优化实践:订单系统的垃圾回收案例

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了JVM系统优化实践:订单系统的垃圾回收案例相关的知识,希望对你有一定的参考价值。

您好,我是湘王,这是我的51CTO博客,欢迎您来,欢迎您再来~




上回说到了年轻代和老年代的两个垃圾回收器:ParNew和CMS,并且将CMS的GC过程也一并介绍了,现在来看个订单系统的案例。

假设有这样的订单系统:

1、每日亿级流量,500万DAU,每日50万单集中在4小时高峰期;

2、大促(如双11)期间,就可能产生1000单/秒的峰值;

3、假设需增加3台机器,平均300单/台,4C8G。

案例目标:优化JVM,尽量避免Full GC。

按500单/秒的请求来估算的话,也就是:

500 * 1K * 20倍(单个开销) * 10倍(相关对象) = 100M

即每秒会产生100M(垃圾)。

JVM系统优化实践(8):订单系统的垃圾回收案例_JVM


按此消费水平,内存模型是:

1、4C8G内存,JVM内存 = 物理内存 / 2 = 4G内存;

2、JVM堆分配3G(年轻代1.5G,老年代1.5G);

3、JVM栈每线程分配1M;

4、剩余内存再配置其他JVM参数

所以常规的JVM参数配置就是这样的:

-Xms3072M -Xmx3072M -Xmn1536M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M

但按此配置,年轻代15秒后就会被填满。

JVM系统优化实践(8):订单系统的垃圾回收案例_老年代_02


所以稍稍调整下,增加-XX:SurvivorRatio参数:

-Xms3072M -Xmx3072M -Xmn1536M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8


-XX:SurvivorRatio=8,导致Eden只有1.2G,会提前触发Minor GC:

JVM系统优化实践(8):订单系统的垃圾回收案例_老年代_03



接下来可以再考虑优化Survivor。它的问题是:

1、会经常出现Survivor空间不足而直接进入老年代;

2、超过Survivor空间50%规则(会直接进入老年代)。

建议:

1、调整年轻代和老年代空间大小;

2、因为普通业务系统的大部分对象生成周期都很短,根本不应该频繁进入老年代;

3、尽量让对象留在年轻代里。

因此,对于任何系统,首要考虑的就是尽量让对象都留在Survivor里。调整后的JVM配置:

-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8


同时,可以降低进入老年代的“年龄”大小,给Survivor腾空间。调整后的JVM配置:

-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5


另一方面,为了不让过大的对象进入老年代,可以考虑对进入老年代的对象大小进行调整,当有超过指定大小的内存对象时,就直接进入老年代。调整后的JVM配置:

-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M


之前说过默认超过Survivor空间大小的50%时,存活对象就会进入老年代,因此这里也可以优化。调整后的JVM配置:

-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M -XX:TargetSurvivorRatio=50


最后别忘了指定GC,年轻代用ParNew,老年代用CMS。调整后的JVM配置:

-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M -XX:TargetSurvivorRatio=50 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC


那么各位可以根据这个思路,估算一下自己公司的生产系统,合理设置并优化JVM参数。


总结一下:

1、对象进入老年代的一般规律:

l -XX:MaxTenuringThreshold=N,该参数值让年轻代对象躲过N次GC之后进入老年代。这些对象一般是@Entity、@Component、@Service、@Controller等注解标注出来的系统组件;

l -XX:PretenureSizeThreshold=1M,年轻代中超过该值的对象就进入老年代;

l -XX:TargetSurvivorRatio=50,Minor GC后存活对象的总大小如果超过该值就进老年代。

2、什么时候会触发Full GC?

l -XX:HandlePromotionFailure,该参数没打开时触发Full GC(JDK1.6后已废弃);

l 老年代可用空间 < 历次Minor GC后进入老年代的对象的平均大小时触发Full GC;

l 老年代可用空间 < 要进入的老年代的存活对象大小时触发Full GC;

l -XX:+UseCMSCompactAtFullCollection和XX:CMSInitiatingOccupancyFraction=92,老年代可用空间超过该值时触发Full GC,这两个必须配对出现(JDK1.8已不建议使用)。

大促期间,真正的系统压力峰值时间是有限的,比如持续2小时。如果JVM能做到500单/秒,大约1小时才触发一次Full GC,那么峰值过后,JVM的压力就会小很多,就不会触发Full GC了。

3、老年代GC时发生Concurrent Mode Failure的问题。

l 当老年代使用空间超过92%时进行CMS,可用空间不足100M;

l 有一批存活对象要进入老年代,大小200M;

l 此时就发生Concurrent Mode Failure;

l 但这种概率极小,不需要为极小概率事件调整JVM参数设置;

l 也没有必要修改执行多少次Full GC之后进行碎片清理,因为经过优化后, Full GC执行次数大大降低了。

那么订单系统的最终配置是:

JVM系统优化实践(8):订单系统的垃圾回收案例_CMS_04





感谢您的大驾光临!咨询技术、产品、运营和管理相关问题,请关注后留言。欢迎骚扰,不胜荣幸~

以上是关于JVM系统优化实践:订单系统的垃圾回收案例的主要内容,如果未能解决你的问题,请参考以下文章

案例实战:每日上亿请求量的电商系统,JVM年轻代垃圾回收参数如何优化?

JVM:21 每日请求上亿的电商系统,老年代的垃圾回收参数该如何优化?

JVM系统优化实践:什么时候GC以及有哪些GC

JVM垃圾回收优化实战-G1垃圾回收器

最新 JVM 垃圾回收器 Shenandoah GC 的实践案例

JVM. GC 性能调优方法与思路