亿级流量电商系统如何优化JVM参数

亿级流量电商系统如何优化JVM参数

注意: 此案例只针对于CMS+ParNew

详细链接: https://www.processon.com/view/link/628a02277d9c0858169528f0

• 假如8G内存，我们一般是分配4G给JVM，正常的JVM参数配置如下

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

• 但是得考虑到动态年龄判断机制导致频繁FullGC

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

• 很多优化无非就是让短期存活的对象尽量留在Survivor区，不要进入老年代，这样MinorGC后都会进行回收，不会进入到老年代触发FullGC

• 问题: 对象动态年龄应该设置多少才移动到老年代比较合适

  • 本例中一次MinorGC要间隔二三十秒，大多数对象一般在几秒内就会变为垃圾，完全可以将默认的15岁改小一点，比如改为5，那么意味着对象要经过5次MinorGC才会进入老年代，整个时间也有一两分钟了，如果对象这么长时间都没被回收，完全可以认为这些对象是会存活的比较长的对象，可以移动到老年代，而不是继续一直占用Survivor区空间

  • 对于多大的对象直接进入老年代(参数-XX:PretenureSizeThreshold)，这个一般可以结合你自己系统看下有没有什么大对象生成，预估下大对象的大小，一般来说设置为1M就差不多了，很少有超过1M的大对象，这些对象一般就是你系统初始化分配的缓存对象，比如大的缓存List、Map之类的对象

  • 可适当调整下参数

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

• 问题: CMS参数如何设置

  • 首先我们想下当前这个系统有哪些对象可能会长期存活躲过5次以上MinorGC最终进入老年代

  • 比如Spring的Bean对象、线程池对象、一些初始化缓存对象，这些加起来充其量也就几十MB，还有就是某次MinorGC完之后还有超过100MB的对象存活，那么就会直接进入老年代，比如突然某一秒瞬间要处理500多个订单，那么每秒生成的对象可能有100多MB，再加上系统可能又压力剧增，一个订单好几秒才能处理完，下疫苗可能又有很多订单过来

  • 估算下大概每隔五六分钟出现一次这样的情况，那么大概半小时到一小时之间就可能因为老年代满了触发一次FullGC，FullGC的触发条件还有我们之前说过的老年代空间分配担保机制，历次的MinorGC挪动到老年代的对象大小肯定是非常小的，所以几乎不会在minor gc触发之前由于老年代空间分配担保失败而产生FullGC，其实在半小时后发生FullGC，这时候已经过了抢购的最高峰期，后续可能几小时才做一次FullGC

  • 对于碎片整理，因为都是1小时或几小时才做一次FullGC，是可以每做完一次就开始碎片整理，或者两到三次之后再做一次也行

  • 只要年轻代参数设置合理，老年代CMS的参数设置基本都可以用默认值

    -Xms3072M -Xmx3072M -Xmn2048M -Xss1M  -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M  -XX:SurvivorRatio=8 
    -XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC 
    -XX:CMSInitiatingOccupancyFraction=92 -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0