如何优化生产环境的Full GC?

举报
JavaEdge 发表于 2022/01/29 20:11:25 2022/01/29
【摘要】 大部分工程师开发完一个系统后,部署生产环境的时候往往不对JVM进行参数设置,直接用默认JVM参数,这绝对是系统负载逐渐增高的时最大问题如你不设置-Xmx、-Xms之类的堆内存大小,你启动一个系统,可能默认就给你几百MB的堆内存大小,新生代和老年代可能都是几百M。很多后台系统都用默认JVM参数部署启动,前期没啥问题,但中后期开始,当有一定用户量和一定负载,就会出现惊喜。Eden过小,导致频繁触...

大部分工程师开发完一个系统后,部署生产环境的时候往往不对JVM进行参数设置,直接用默认JVM参数,这绝对是系统负载逐渐增高的时最大问题

如你不设置-Xmx、-Xms之类的堆内存大小,你启动一个系统,可能默认就给你几百MB的堆内存大小,新生代和老年代可能都是几百M。

很多后台系统都用默认JVM参数部署启动,前期没啥问题,但中后期开始,当有一定用户量和一定负载,就会出现惊喜。

Eden过小,导致频繁触发YGC,Survivor过小,导致经常在YGC后存活对象其实也没多少,但Survivor放不下,导致对象经常进入老年代,导致老年代过段时间就满,然后触发Full GC。

所以当时这个垂直电商APP的各个系统通过jstat分析JVM GC后发现,高峰期Full GC每小时发生好几次。Full GC正常以天为单位发生,如每天发生一次或几天发生一次。要是每h都发生几次Full GC,就会导致系统每h卡顿好几次!

公司级别JVM参数模板

让大部分系统套用这个模板,基本保证JVM性能别太差,避免很多初中级工程师直接使用默认的JVM参数,可能一台8G内存的机器上,JVM堆内存就分配了几百MB。

-Xms4096M
-Xmx4096M
-Xmn3072M
-Xss1M
-XX:PermSize=256M
-XX:MaxPermSize=256M
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFaction=92
-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction=0

8G机器给JVM堆分配4G,毕竟还有其他进程使用内存,别让JVM堆把机器内存占满。

年轻代给到3G,让年轻代尽量大,进而让每个Survivor区域都达到300MB。根据当时对这个业务系统的分析,假设用默认的JVM参数,可能年轻代就几百MB的内存,Survivor区域就几十M。

那每次GC后,存活对象可能几十M,因为在GC瞬间可能有部分请求没处理完,此时会有几十M对象存活,所以很容易触发动态年龄判定规则,让部分对象进入老年代。

所以分析后,给年轻代更大内存空间,让Survivor更大,这样在YGC时,这瞬间可能有部分请求没处理完,有几十M存活对象,这时候在几百M的Survivor可轻松放下,而不会进老年代。这样操作对垂直电商大部分后台业务都能cover。

不同系统运行时情况略不同,但基本上都是在每次YGC后存活几~几十M对象,所以此时在这个参数模板下都能抗住。

只要把内存分配完毕,那对象进入老年代速度就很慢,经过该参数模板在朋友公司全部系统的重新部署和上线,各个团队通过jstat观察,基本上发现各个系统的Full GC都变成了几天才会发生一次。

此时在参数模板里还会加入Compaction相关参数,保证每次Full GC后都会执行一次压缩,解决内存碎片。

如何优化每次Full GC的性能?

就是把每次Full GC时间进一步降低。

  • -XX:+CMSParallelInitialMarkEnabled,会在CMS的“初始标记”阶段开启多线程并发执行

    初始标记阶段,会STW,该阶段开启多线程并发后,可尽可能优化该阶段性能,减少STW时间。

  • -XX:+CMSScavengeBeforeRemark

    在CMS重新标记阶段前,先尽量执行一次YGC

这样做有什么作用呢?

CMS重新标记也会STW,所以重新标记前,先执行一次YGC,就会回收掉一些年轻代里无人引用的对象。

所以若提前回收掉一些对象,在CMS重新标记阶段就能少扫描一些对象,这就提升CMS重新标记阶段的性能。

-Xms4096M -Xmx4096M -Xmn3072M -Xss1M 
-XX:PermSize=256M
-XX:MaxPermSize=256M
-XX:+UseParNewGC 
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFaction=92 
-XX:+UseCMSCompactAtFullCollection 
-XX:CMSFullGCsBeforeCompaction=0 
-XX:+CMSParallelInitialMarkEnabled 
-XX:+CMSScavengeBeforeRemark

采用JVM参数模板后的效果

采用jstat观察JVM GC情况,发现好转,各系统:

  • YGC都在几min或十几min一次,每次耗时就几十ms
  • Full GC基本都在几天一次,每次耗时在几百ms

JVM达到这个性能就对线上系统没多大影响。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。