记录一次gc报警背后的思想推演

最新推荐文章于 2023-05-29 11:08:04 发布
最新推荐文章于 2023-05-29 11:08:04 发布
阅读量917 收藏
点赞数
分类专栏： 小案例 文章标签： c# 单元测试 物联网
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zhang6622056/article/details/120136570
版权

记录一次gc报警背后的思想推演

问题背景

在日常应用中，我们经常听到4C8G，8C16G等生产机器配置，在出现本次报警之前，我基本上是一个不太经常去看jvm指标的人。问题经历是这样的，在2021年8月14日凌晨，我收到了计费系统频繁YGC的报警，报警内容部分片段如下：

  • 00:05:20至00:05:40，JVM监控YoungGC次数=24次[偏差20%]，超过7次YoungGC次数>=20次

收到的内容大致是说平均1秒会发生1次+的YGC,YGC频繁，第一反应就是流量有对应增加，而结果也确实是这样的。拿到报警第一时间开始分析，我的业务流量都是通过worker有频率的去执行的，以此，来保证最终一致性。虽然有接口提供出去，但是很明显接口的调用量并没有报警，所以，第一时间排除了接口调用暴增的可能。而worker一直都是在执行的啊。为什么就会突然出现流量激增呢？

回顾近期上线~,突然意识到，功能虽然没有变更，但是，项目职责却变更了。如下图。这时候突然想起来，原来service app的职责变化了。上线后web和worker的业务逻辑都通过远程调用来支撑，于是乎service app的职责变的更加庞大了。
在这里插入图片描述

于是，首先降低worker app的运行频率或停止热点worker的执行（这需要根据业务评估，由于本worker任务是转历史，可以首先关闭的）。进行风险降低，以防止频繁gc引起老年代空间担保，最终导致频繁full gc，从而导致系统不可用。

问题虽然暂时性的解决了。但是，未从根本上解决。当时脑补的后续补救方案有以下几种

  • 调整worker的执行频率，使得对象的分配更加平滑
  • 调整jvm参数，在业务可以接受stw的时间之内，尽可能的降低gc频率
  • 调整不同应用的机器资源，加大service，减少worker和web.(原因为主逻辑都被service app承担)

jvm优化过程

机器资源和worker频率不在本篇的探讨范围内，而对于上面这一句话。调整jvm参数，在业务可以接受stw的时间之内，尽可能的降低gc频率。这里有两个关键描述

  • 业务可以接受stw的时间
  • 降低gc频率

Stw时间和gc频率，这两个指标在内存区域中是矛盾的：Eden越大，频率越低、stw越长。反之Eden越小、频率越高、stw越小。jvm调优是一个平衡的艺术。我们力求最大吞吐，而不是假设所有的系统都是高并发系统这样的假象。 gc次数 * 单次gc耗时 =stw总耗时，stw总耗时（注意：总耗时要加上full gc的stw耗时）要尽可能小，我们也就达到了最大吞吐。此时的性能就是最优的。（当然，问题不能一概而论。有些高并发系统，stw的耗时是有最低容忍的，即便调优之后整体吞吐变高，但是，单次stw的时间却变长了，这不适合用最大吞吐的思想来解决。）

优化前的jvm参数：

-Xms2048m 
-Xmx2048m 
-Xmn768m 
-Xss512K 
-XX:PermSize=96m 
-XX:MaxPermSize=96m 
-XX:SurvivorRatio=8 
-XX:InitialTenuringThreshold=8 
-XX:MaxTenuringThreshold=8 
-XX:ParallelGCThreads=4 
-XX:TargetSurvivorRatio=70 
-XX:+UseBiasedLocking 
-XX:-UseAdaptiveSizePolicy 
-verbose:gc 
-Xloggc:../gc.log 
-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps 
-XX:+PrintAdaptiveSizePolicy 
-XX:+PrintTenuringDistribution 
-XX:+PrintReferenceGC 
-Djava.awt.headless=true 
-Dsun.net.client.defaultConnectTimeout=60000 
-Dsun.net.client.defaultReadTimeout=60000 
-Djmagick.systemclassloader=no -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.ttl=300

  • 如上，堆设置为2G，其中年轻代设置768m，按照默认比例。Eden区大小为614m，Sur为76m。这样的设定，可以断定主要为了减少stw时间，细节层面也主要包含了以下几点

    • Eden区614m的空间，减少了单次标记的空间
    • sur区76m，减少了单次复制的空间
    • old区1358m，减少了单次full gc的空间。

  • 对应的效果图如下所示

    • YGC

在这里插入图片描述

  • FGC

在这里插入图片描述

  • 并发请求下，峰值可达45次/10s的频率，平均1s 3次ygc，平均耗时11.3ms 。但是在业务高峰期肯定不只11.3ms。
  • 老年代担保机制，触发Full Gc，甚至有可能导致应用不可用。

在4c8g的机器上的2G堆配置，单次stw时间确实短暂，保留在10ms以内，但是这种设定是否是正确的呢 ？在资源利用率方面是否存在严重浪费？

如果基于成本考虑，将4g内存留给系统，剩下的堆内存设置为4g，那么毫无疑问，在每个分代中，对应的堆内存都会加大。单次stw和full gc的stw时间都会由于空间增大而变长。只不过，这个变长的时间是要业务系统可以接受的情况下进行优化。

从系统角度来考虑，10+ms的stw优化无疑是有巨大进步的，但从成本的角度考虑，又存在了严重浪费，从老板的视角来看，是非常不值得的，毕竟为了ms级别的优化，需要每年支付对应的服务器费用，无疑是非常浪费的。

优化后的jvm参数

-Xms4096m
-Xmx4096m
-Xmn1024m
-Xss512K
-XX:SurvivorRatio=9
-XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize=256m
-XX:+UseParNewGC
-XX:PretenureSizeThreshold=1m
-XX:+ParallelRefProcEnabled
-XX:+DisableExplicitGC
-XX:InitialTenuringThreshold=6
-XX:MaxTenuringThreshold=6
-XX:ParallelGCThreads=4
-XX:TargetSurvivorRatio=70
-XX:+UseBiasedLocking
-XX:-UseAdaptiveSizePolicy
-XX:+UseConcMarkSweepGC
-XX:ConcGCThreads=4
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=50
-XX:+CMSParallelRemarkEnabled
-XX:CMSFullGCsBeforeCompaction=3
-verbose:gc
-Xloggc:../gc.log
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintAdaptiveSizePolicy
-XX:+PrintTenuringDistribution
-XX:+PrintReferenceGC
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCApplicationConcurrentTime
-XX:+PrintSafepointStatistics
-XX:PrintSafepointStatisticsCount=1
-Djava.awt.headless=true
-Dsun.net.client.defaultConnectTimeout=60000
-Dsun.net.client.defaultReadTimeout=60000
-Djmagick.systemclassloader=no
-Dnetworkaddress.cache.ttl=300
-Dsun.net.inetaddr.ttl=300
  • 增大整个堆空间到4096m，留一半的内存给系统中其他进程使用，尽可能的不要产生swap.
  • 年轻代1024m,Eden和sur比例为9:1:1，其中Eden区为921m，Sur区为102m。相对保守的加大了300m空间。sur区几乎不变
  • -XX:PretenureSizeThreshold=1m，将>1M大的对象提前晋升至老年代，是因为系统中有本地缓存，提前进入old区，减少sur区的拷贝
  • 采用cms垃圾收集器，并在old区50%的时候提前触发full gc
优化后的效果
  • YGC

在这里插入图片描述

  • FGC

在这里插入图片描述

  • 并发请求下，YGC频率最高可达10s 21次，单次stw耗时26ms

  • 无FGC

总结

  • 在业务stw可以接受的情况下，加大堆空间可以使得内存空间有更大的利用率，但是，单次stw时长必须增大，对于不同的系统可以根据实际情况做出对应思考

  • 本次计费worker可以增大堆空间，原因为stw可以稍微长一些，因为是在凌晨来做转历史的任务.所以，该应用可加大对应的新生代空间，以增加资源利用率

  • 如果业务流量可控，那么，可以通过减少worker频率和单次量级来应对机器gc频繁的问题
    在这里插入图片描述

延伸问题

  • 如果stw比较维持在较短的耗时，需求整个堆用到较小的内存空间。那么，4c8g和8c16g的机器在这种应用上是否是必要的 ？ 还是用多个机器来实现更好？
  • 在增大资源利用率的情况下，G1垃圾收集器在8C16G上的应用需要实践和调优
NeroJings
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
运维中遇到的GC频繁告警问题处理方式
wngua的专栏
05-18 4926
自己工作那么久很少接触到内存调整方面的问题，很巧的是最近两个系统频繁出现了GC回收始终高于75%同时长久不触发OC的回收。自己看到这些很是开心啊，终于有了机会来体验面试中常问的是否有过内存调优方面的经验，哈哈，我再也不空白了。。。。。。。 1、WebLogic中间件频繁告警GC回收率高于75%。自己首先打出hrof的heapdump然后通过mat工具查看内存使用情况。 从mat中可以看到内
一次诡异的full gc查找问题全过程
08-26
在我们的服务中，突然出现了频繁的 Full GC 问题，而服务本身没有任何改动和发布记录。查看 GC log 日志，发现每次发生 Full GC 时，old 区域和 perm 区域的使用率很低，没有达到触发 Full GC 的条件。此外，项目中...
可观测性-告警-JVM GC重要指标+告警指标
laker的博客
10-14 2614
如果一个线程在临界区时需要GC，那么它将允许它们完成，即调用相应的释放函数。如果一个线程在临界区时需要GC，那么它将允许它们完成，即调用相应的释放函数。对于 G1，这可能是一个主要的 GC，并且在例行的次要收集中看到。，而不考虑实际的分配大小，但是如果由于这个检查而触发，原因将被列为巨大的分配。jvm.gc.max.data.size : 老年代内存池最大size（即设置的老年代大小，单位字节）。jvm.gc.concurrent.phase.time：在 CMS 的并发阶段花费的时间。
4C8G的JVM调优
qq_41789192的博客
05-29 1367
JVM调优
一、MySQL基础篇
weixin_45775746的博客
11-02 1550
MySQL基本概念 MySQL驱动是什么东西? 访问数据库则进行网络连接 这个网络连接则需要由MySQL驱动创建 基于网络连接建立各种CRUD操作 数据库连接池解决了什么问题? 当并发过高时候，如果此时只有一个数据库连接，多个线程抢占一个数据库连接，肯定会导致效率低下。 如果每个请求去访问数据库都创建一个连接，使用后进行销毁，那么创建和销毁线程的开销过大，会导致程序效率低下。 故引进连接池，需要的时候从池里取，不需要的时候放回池里。 数据库连接池是用来干什么的？ 维护了server与DB之间的多个
一次完整的JVM GC的流程
最新发布
05-09
一次完整的JVM GC的流程分析，描述了Full GC的原因入口以及Minor GC
第一次脚本监测内存泄露记录
12-22
于是利用VBScript写了一段代码来监测Server进程dllhost:  Option Explicit  Dim strComputer， processid， Name， interval  'CONFIGURATIONS  strComputer = "localhost"  'process
一次OOM问题排查过程实战记录
08-26
* 为什么 Tomcat 就会一次性分配这么大的 buffer 呢？ * 为什么会有那么多的 Tomcat 线程？ 通过进一步的分析，我们可以确定这些问题的答案。 六、结论 在本次 OOM 问题排查中，我们通过分析 Histogram、byte ...
JVM垃圾回收参数
C30混凝土
11-05 340
4C8G推荐参数： -Xms6144m -Xmx6144m -Xmn3g -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=15 -XX:CMSInitiatingOccupancyFraction=60 -XX:CMSFullGCsBeforeCompaction=0 -XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSClas
JVM性能调优：线上 JVM GC 频繁耗时长，出现 LongGC 告警！
Java精选
10-12 966
1. 背景多个业务线的应用出现LongGC告警最近一段时间，经常收到CAT报出来的Long GC告警（配置为大于3秒的为Longgc）。2. 知识回顾2.1 JVM堆内存划分新生代（Young Generation）新生代内被划分为三个区：Eden，from survivor，to survivor。大多数对象在新生代被创建。Minor GC针对的是新生代的垃圾回收。老年代（Old Generat...
java jvm-old gc耗时几十s，导致系统告警
Java个体户
11-25 1469
问题 生产环境告警，接口超时。 原因 old gc耗时几十s，导致系统瞬间卡死，然后接口都超时了。 另外一个应用也是耗时好几s，导致系统瞬间卡死，然后很多告警。 不是每次old gc都会卡死，而是偶尔一次old gc才会耗时很久，大部分时候正常。 本质原因 为什么old gc耗时这么久？原因是因为之前有一个节点接入skywalking，然后调整了jvm配置，具体是：新生代和老年代的比例，默认是2。现在是4，老的内存大小翻倍——导致老年代的gc阈值变高了，所以才会很久gc一次，但是有可能导致单次耗时太
8核16G内存jvm配置优化
weixin_42605397的博客
01-03 1403
谢谢你的问题。 对于 8 核 16G 内存的机器，你可以考虑将 JVM 的最大堆内存设置为 12G，这样可以给操作系统和其他程序留出足够的内存空间。例如，你可以使用以下命令来启动 JVM： java -Xmx12G -Xms12G MyProgram 如果你的程序需要较多的常驻内存，你还可以将 JVM 的初始堆内存设置为 12G，这样可以减少垃圾回收带来的性能影响。 此外，你还可以使用以下参数来...
2021-04-06 GC调优记录
白首太玄经
04-06 312
机器配置： 8C 16G 设置GC参数 一、采用CMS -Xmx6144m -Xms6144m //整个堆内存 6G -Xmn4096m // 年轻代 4G -Xss128k // 线程栈的大小 -XX:SurvivorRatio=6 // 设置年轻代中 Eden 和 Survivor区的比值，6 表示 6:2:2 新生代 4G：Eden- 2458M， S0: 819M ， S1： 819M -XX:MaxPermSize=512m -XX:ParallelGCThreads=8 ...
JAVA性能调优
scholery的专栏
03-18 530
一、性能调优 除了上述内存泄漏外，我们还发现CPU长期不足3%，系统吞吐量不够，针对8core×16G、64bit的Linux服务器来说，是严重的资源浪费。 在CPU负载不足的同时，偶尔会有用户反映请求的时间过长，我们意识到必须对程序及JVM进行调优。从以下几个方面进行： 线程池：解决用户响应时间长的问题 连接池 JVM启动参数：调整各代的内存比例和垃圾回收算法，提高吞吐量 程序算法：改进程序逻辑算法提高性能 1.Java线程池（java.util.concurrent.ThreadPo...
8核16g服务器支持多少并发
athena1999的博客
10-24 1604
8核16g服务器支持多少并发
Java中9种常见的CMS GC问题分析与解决
美团技术团队
11-12 7768
总第422篇2020年 第46篇目前，互联网上 Java 的 GC 资料要么是主要讲解理论，要么就是针对单一场景的 GC 问题进行了剖析，对整个体系总结的资料少之又少。前车之鉴，后事之师...
线上 GC 告警，我菊花一紧，裤子都没提！！
武哥聊编程
07-14 2548
阅读本文约需要5分钟 就在上周，晚上下班后在家上厕所，突然微信企业邮箱收到线上GC告警了：G1 Young Generation Count 超过阈值。我菊花一紧，裤子还没来得及提。这是我入职拼多多后第一次遇到的线上告警。 从告警提示来看，是新生代垃圾回收次数过多，换种角度想想，应该是代码中某个地方创建了太多的对象，而且很快就被回收。由于电脑没装 VPN...
android 应用主动触发一次gc
05-27
在 Android 中，可以使用 `System.gc()` 方法来主动触发一次垃圾回收，如下所示： ```java System.gc(); ``` 但是需要注意的是，这只是对系统的一个建议，不能保证系统会立即执行垃圾回收。因为系统会根据需要自动...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值