G1垃圾回收器GC频繁导致的系统波动问题(后续)

最新推荐文章于 2024-06-18 20:08:43 发布
最新推荐文章于 2024-06-18 20:08:43 发布
阅读量1.8k 收藏 2
点赞数
原文链接：https://my.oschina.net/110NotFound/blog/3092573
版权
本文探讨了G1垃圾回收器因大对象导致的系统波动问题，提出两种解决方案：一是限制单个消息大小不超过HeapRegionSize的一半；二是调整堆内存至8G以上并设置G1HeapRegionSize为4M。采用第二种方案虽然优化效果显著，但硬件成本较高。最终建议通过减少不必要的大对象创建，从根本上降低GC频率和停顿时间。
摘要由CSDN通过智能技术生成

承接上文的问题 ： https://my.oschina.net/110NotFound/blog/3084898

上文提到问题的解决方案有两种：

  1. 设置 getMaxRequestSizeBytes 的值为 1024256 ，减少每一个消息的数组的大小，使其不会超过 HeapRegionSize 的一半大小，这个缺陷就是需要保证消息的大小必须在 1024256 字节以内。

  2. 调整堆内存大小为8G或以上，同时增加配置 -XX:G1HeapRegionSize=4M ，使得1M的消息数组大小小于 HeapRegionSize 的一半。

采用的最为稳妥的方案二，这样当大对象过来的时候不直接分配到老年代，而是在伊甸区，回收的时间和次数明显减少，效果显著。 如下是gc的情况：

S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU            YGC       YGCT    FGC    FGCT     GCT   
 0.0   28672.0  0.0   28672.0 5255168.0 921600.0 3104768.0   462976.5  183168.0 171928.0 21120.0 19328.0   1201   32.053   0      0.000   32.053
 0.0   28672.0  0.0   28672.0 5255168.0 1228800.0 3104768.0   462976.5  183168.0 171928.0 21120.0 19328.0   1201   32.053   0      0.000   32.053
 0.0   28672.0  0.0   28672.0 5255168.0 1478656.0 3104768.0   462976.5  183168.0 171928.0 21120.0 19328.0   1201   32.053   0      0.000   32.053
 0.0   28672.0  0.0   28672.0 5255168.0 1781760.0 3104768.0   462976.5  183168.0 171928.0 21120.0 19328.0   1201   32.053   0      0.000   32.053
 0.0   28672.0  0.0   28672.0 5255168.0 2101248.0 3104768.0   462976.5  183168.0 171928.0 21120.0 19328.0   1201   32.053   0      0.000   32.053
 0.0   28672.0  0.0   28672.0 5255168.0 2355200.0 3104768.0   462976.5  183168.0 171928.0 21120.0 19328.0   1201   32.053   0      0.000   32.053
 0.0   28672.0  0.0   28672.0 5255168.0 2678784.0 3104768.0   462976.5  183168.0 171928.0 21120.0 19328.0   1201   32.053   0      0.000   32.053
 0.0   28672.0  0.0   28672.0 5255168.0 2965504.0 3104768.0   462976.5  183168.0 171928.0 21120.0 19328.0   1201   32.053   0      0.000   32.053
 0.0   28672.0  0.0   28672.0 5255168.0 3309568.0 3104768.0   462976.5  183168.0 171928.0 21120.0 19328.0   1201   32.053   0      0.000   32.053
 0.0   28672.0  0.0   28672.0 5255168.0 3604480.0 3104768.0   462976.5  183168.0 171928.0 21120.0 19328.0   1201   32.053   0      0.000   32.053
 0.0   28672.0  0.0   28672.0 5255168.0 3891200.0 3104768.0   462976.5  183168.0 171928.0 21120.0 19328.0   1201   32.053   0      0.000   32.053
 0.0   28672.0  0.0   28672.0 5255168.0 4161536.0 3104768.0   462976.5  183168.0 171928.0 21120.0 19328.0   1201   32.053   0      0.000   32.053
 0.0   28672.0  0.0   28672.0 5255168.0 4505600.0 3104768.0   462976.5  183168.0 171928.0 21120.0 19328.0   1201   32.053   0      0.000   32.053
 0.0   28672.0  0.0   28672.0 5255168.0 4796416.0 3104768.0   462976.5  183168.0 171928.0 21120.0 19328.0   1201   32.053   0      0.000   32.053
 0.0   20480.0  0.0   20480.0 5263360.0 53248.0  3104768.0   464538.5  183168.0 171928.0 21120.0 19328.0   1202   32.077   0      0.000   32.077
 0.0   20480.0  0.0   20480.0 5263360.0 290816.0 3104768.0   464538.5  183168.0 171928.0 21120.0 19328.0   1202   32.077   0      0.000   32.077
 0.0   20480.0  0.0   20480.0 5263360.0 737280.0 3104768.0   464538.5  183168.0 171928.0 21120.0 19328.0   1202   32.077   0      0.000   32.077
 0.0   20480.0  0.0   20480.0 5263360.0 1032192.0 3104768.0   464538.5  183168.0 171928.0 21120.0 19328.0   1202   32.077   0      0.000   32.077
 0.0   20480.0  0.0   20480.0 5263360.0 1294336.0 3104768.0   464538.5  183168.0 171928.0 21120.0 19328.0   1202   32.077   0      0.000   32.077
 0.0   20480.0  0.0   20480.0 5263360.0 1613824.0 3104768.0   464538.5  183168.0 171928.0 21120.0 19328.0   1202   32.077   0      0.000   32.077
 0.0   20480.0  0.0   20480.0 5263360.0 1896448.0 3104768.0   464538.5  183168.0 171928.0 21120.0 19328.0   1202   32.077   0      0.000   32.077
 0.0   20480.0  0.0   20480.0 5263360.0 2191360.0 3104768.0   464538.5  183168.0 171928.0 21120.0 19328.0   1202   32.077   0      0.000   32.077
 0.0   20480.0  0.0   20480.0 5263360.0 2482176.0 3104768.0   464538.5  183168.0 171928.0 21120.0 19328.0   1202   32.077   0      0.000   32.077
 0.0   20480.0  0.0   20480.0 5263360.0 2793472.0 3104768.0   464538.5  183168.0 171928.0 21120.0 19328.0   1202   32.077   0      0.000   32.077
 0.0   20480.0  0.0   20480.0 5263360.0 3125248.0 3104768.0   464538.5  183168.0 171928.0 21120.0 19328.0   1202   32.077   0      0.000   32.077
 0.0   20480.0  0.0   20480.0 5263360.0 3403776.0 3104768.0   464538.5  183168.0 171928.0 21120.0 19328.0   1202   32.077   0      0.000   32.077
 0.0   20480.0  0.0   20480.0 5263360.0 3653632.0 3104768.0   464538.5  18
最低0.47元/天 解锁文章
chengyi5512
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
G1垃圾回收器GC频繁导致的系统波动问题
chengyi5512的博客
08-07 2029
CPU波动如图所示： 内存波动如图所示： CPU经常达到告警阈值，触发告警信息，第一反应就是去看下java进程里哪个线程耗CPU资源多，其实这里看到内存波动情况就大致能猜测出和GC有关。 top -Hp PID PID %CPU %MEM TIME+ COMMAND ...
Java基础之《JVM性能调优（12）—G1的YoungGC》
csj50的专栏
04-14 2938
一、G1 young gc算法的垃圾回收和内存更新 1、Young GC的触发条件 Eden区的大小范围 = [ -XX:G1NewSizePercent, -XX:G1MaxNewSizePercent ] = [ 整堆5%, 整堆60% ] 在[ 整堆5%, 整堆60% ]的基础上，G1会计算下现在Eden区回收大概要多久时间，如果回收时间远远小于参数-XX:MaxGCPauseMills设定的值（默认200ms），那么增加年轻代的region，继续给新对象存放，不会马上做YoungGC。 G1计算回
G1调优--解决G1频繁出现GC，JVM内存图波浪
yangjiaaiLM的博客
02-28 1844
问题：堆区到达250M左右就进行GC 可能导致此问题的原因： 1、配置-XX:G1HeapRegionSiz太小，程序产生了大对象大于配置的一半，导致会直接丢入老年代 2、设置了-Xmn配置，固定了年轻代的大小 解决： 1、排查出具体大对象，配置-XX:G1HeapRegionSize，使得此配置大小要小于HeapRegionSize的一半。 2、不建议配置，固定年轻代的大小会覆盖暂停时间目标，G1设置垃圾收集暂停时间最大值指标：-XX:MaxGCPauseMillis=200 ...
峰谷流量年轻代GC频繁场景下G1回收器参数优化实例
最新发布
weixin_44231672的博客
06-18 570
峰谷型业务G1参数调优
JVM GC原理及调优的基本思路
JavaEdge全是干货的技术号
08-01 1229
若观察到Tomcat进程CPU使用率较高，并在GC日志中发现GC次数比较频繁、GC停顿时间长，说明需优化GC。 CMS和G1是时下使用率比较高的两款垃圾收集器，从Java 9开始，G1是默认垃圾收集器。 CMS vs G1 CMS收集器 将Java堆分为新生代（Young）或老年代（Old），因为研究表明，超过90％的对象在第一次GC时就被回收掉，仅少数对象会存活较长。 CMS还将新生代内存空间分为幸存者空间（Survivor）和伊甸园空间（Eden）： 新的对象始终在Eden空间上创建 一旦一个对象在
Young GC过于频繁
厚积薄发
03-28 5043
YoungGC频繁一般是内存问题，在优化代码降低频率的同时，也需关注某个时间段的累计耗时。总的来说，在CPU Quota允许的范围内，GC总耗时越少越好，GC频率反倒不是那么重要。展开: JVM / 内存 / GC / ClassLoader这一行，找到监控面板：GC耗时 和 GC原因与频次。Young GC过于频繁，说明JVM内存分配压力大，可能是Young区比较小或者代码加载到内存的数据过多。Young GC频繁，通常不用立即处理，大多需要优化代码。可参考原因部分，优化代码，调整GC参数。
服务频繁发生YoungGC的处理过程（合理压测）
AlgoRain的博客
06-22 3268
问题描述 最近一直在做项目的GC优化，因为服务在运行过程中频繁发生GC问题，虽然不是FullGC，但Young频繁GC也会影响线上服务的性能，优化的方向有两个，1.修改JVM参数 ，2.优化代码逻辑。查看当前线上JVM配置调整年轻代的大小可以缓解因内存分配太小而发生频繁GC的问题。本次优化的重点在于代码逻辑的实现，主要原因是： 在目前架构内，系统并不能通过改变eden区大小得到有效解决，年轻代内存区域调大，GC频率改善，但时长会变长。反之，作用也是相反。 频繁的GC和pause清理耗时又引起jvm内
java年轻代频繁gc_JVM young GC频繁，内存泄漏
weixin_30119469的博客
03-02 4362
young gc频繁，老年代占用线性上涨young gc频繁因为产生系统使用log4j1版本在系统中大量使用debug日志输入，导致频繁创建Stringbuilder对象，然后导致年轻代空间不够，执行频繁gc分析老年代内存泄漏是因为一个对象image.png这玩意是个啥呢，是个数据库连接相关的虚引用，每个数据连接对应生产这么一个虚引用对象，这个对象负责在连接对象被回收后通知系统。在<>...
java g1垃圾收集器优化参考
liaomingwu的专栏
05-18 3535
java g1垃圾收集器优化参考
游戏引擎jvm频繁young gc问题分析
qq_21981287的博客
10-26 2116
问题背景: 阿里云vpc部署的游戏引擎服务端集群中有一个节点相对于其他节点来说ygc的次数远远超出正常情况,不过fgc次数是正常的。一般来说出现这种问题,首先要看下jvm gc图，后来发现基本都是par new复制标记算法,cms未出现过。 #查看java进程pid jpc -v #根据pid 来查看s0 s1 e 区 的占用情况 jstat -gcutil 9777 S0C S1C S0U S1U EC EU OC OU
JVM调优实战讨论：YGC调优
chenpeng19910926的专栏
12-21 7160
事情过往交代：    YongGC需要降到10ms，目前是20ms而且不增加总的YGC时间，并且不会增加FULLGC的次数。。 讨论开始： A:大神们，求助： 正在做YGC优化，遇到了些问题。   YGC的耗时主要是在复制阶段吧？由复制的对象大小决定？如果想知道每次被复制的对象是哪些，包括那些age 为1的对象，怎么看？ B：s 区互相挪也耗时吧 A:目标是把YGC单次时间降下去，调
如何定位和解决频繁Young GC问题
m0_37900506的博客
02-12 5927
如何来分析一个项目的gc情况： 首先通过命令： jstat -gc pid 1000 1000来执行 分析 然后具体需要看如下这些指标 1.新生代对象增长的速率: 看EU指标的变化情况（一般会大致成线性变化） 2.Young GC的触发频率: 通过eden区的总大小除以新生代对象增长的速率 3.Young GC的耗时：通过看YGCT指标 4.每次Young GC后的存活对象大小：通过看S1U指标再ygc前后的变化情况（即当EU突然由一个很大的值变成一个很小的值时，可以看对应变化前后S1U的值） 5.每
G1参数调优个人记录
u012447842的博客
06-29 1293
G1内存划分G1看起来和CMS比较类似，但是实现上有很大的不同。 传统分代GC将整体内存分为几个大的区域，比如Eden,S0,S1,Tenured等。而G1将内存区域分为了n个不连续的，大小相同的Region,Region具体的大小为1到32M,根据总的内存大小而定，目标是数量不超过2048个。 如下图所示： G1调优参数 -XX:+UseG1GC ： 使用G1回收器。 -XX:G1HeapRegionSize=2m ： 指定分区大小(1MB~32MB，且必须是2的幂)，默认将整堆划分为2048个分区 -X
JVM参数详解
zangzh的博客
01-27 1164
JVM参数详解 一.参数详解 1、基本参数 -Xms2048m 初始堆大小 默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制. 调整同-Xmx一样可提高性能,防止使用时再申请 -Xmx2048m 最大堆大小 默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制 -Xmn512 年轻代大小 注意：此处的大小是（eden+ 2 survivor space).与jmap -heap中显
G1的Region是如何划分数量和大小的？
z69183787的专栏
01-07 3930
说明：JDK7和JDK8的Region划分实现略有不同（差异非常小，且只有-Xmx和-Xms的值不一样才有区别），本篇文章讲解的是JDK8中Region的划分实现；如果要了解JDK7的Region划分实现，请参考JDK7 headpRegion.cpp 之所以写这篇文章是因为看到有人发出了这样的提问：G1的Xmx大于64G有意义吗？看过一些资料，G1的Region最大可以到32M，2048个分区，这样算下来，32M*2048=64G。 首先说结论，大于64G肯定有意义。那么他的计算方式问题出在哪里呢.
JVM GC G1垃圾回收器配置
年少青山的博客
02-23 2940
JVM GC G1垃圾回收器配置
G1垃圾回收器REGION SIZE说明
zhangjunli的博客
02-02 5430
说明：JDK7和JDK8的Region划分实现略有不同（差异非常小，且只有-Xmx和-Xms的值不一样才有区别），本篇文章讲解的是JDK8中Region的划分实现；如果要了解JDK7的Region划分实现，请参考JDK7 headpRegion.cpp 源码分析 G1 Region划分的实现源码在headpRegion.cpp中，摘取部分核心源码如下： // Minimum re...
JVM 调优
ChineseSoftware的博客
01-13 443
一、什么情况下GC会对程序产生影响 无论 Minor GC/Young GC 还是 Full GC，都会造成一定程度的程序卡顿，即Stop The World：JVM 因为执行 GC 线程，其他工作线程被挂起。它会在任何一种 GC 算法中发生，即使采用 ParNew、CMS 或者 G1 这些更先进的垃圾回收算法，也只是在减少卡顿时间，而并不能完全消除卡顿。当stop-the-world发生时，除 GC 所需的线程外，所有的线程都进入等待状态，直到 GC 任务完成。GC 优化很多时候就是减少 stop-the
G1垃圾回收器 full gc
08-19
G1垃圾回收器也会存在Full GC的情况，尽管Full GC的发生代价很高，应该尽量避免。Full GC的出现可能意味着程序的运行出现了问题，需要仔细考虑为什么会触发Full GC。 Full GC是指对整个Java堆进行垃圾回收，包括...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值