FullGC告警

最新推荐文章于 2024-06-07 12:27:33 发布
最新推荐文章于 2024-06-07 12:27:33 发布
阅读量285 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： jfinal eova 文章标签： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/zerovpp/article/details/103489230

查jstat -gc ip

 

异常代码：

Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
Sql: select * from eova_menu where code = ?
12-11 11:16:15[ERROR]/single_grid/list/hr_cost_bud_menu
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
	at com.jfinal.aop.Invocation.invoke(Invocation.java:87)

运维中遇到的GC频繁告警问题处理方式
wngua的专栏
05-18 5032
自己工作那么久很少接触到内存调整方面的问题，很巧的是最近两个系统频繁出现了GC回收始终高于75%同时长久不触发OC的回收。自己看到这些很是开心啊，终于有了机会来体验面试中常问的是否有过内存调优方面的经验，哈哈，我再也不空白了。。。。。。。 1、WebLogic中间件频繁告警GC回收率高于75%。自己首先打出hrof的heapdump然后通过mat工具查看内存使用情况。 从mat中可以看到内
记一次生产频繁发生FullGC问题
m0_71777195的博客
03-17 651
因为最近这个接口调用量是翻倍了，所以我就去检查了下慢SQL，发现确实是有较多的慢SQL，所以我就缩减了查询的时间范围，但是效果并不好。经过上面问题的排查，造成hooks大对象的原因找到了，就是每次调用接口的时候，都会往hooks里面put一个对象。过了一会发现，这个服务fullGC是有问题的，太频繁了，这个应该是导致接口超时的根本问题，因为时间也是对的上的。对比一下，就不难发现，fullGC数量是从3月15号晚上9点开始增加的，也是这个接口对外开放的时间。2、根据dump文件，分析出堆内对象的分布情况。
线上 GC 告警，我菊花一紧，裤子都没提！！
武哥聊编程
07-14 2625
阅读本文约需要5分钟 就在上周，晚上下班后在家上厕所，突然微信企业邮箱收到线上GC告警了：G1 Young Generation Count 超过阈值。我菊花一紧，裤子还没来得及提。这是我入职拼多多后第一次遇到的线上告警。 从告警提示来看，是新生代垃圾回收次数过多，换种角度想想，应该是代码中某个地方创建了太多的对象，而且很快就被回收。由于电脑没装 VPN...
关于一次fullgc告警分析与分布式任务调度框架的选型调研
路辉的博客
08-17 407
但是这次定时任务导致的fullgc引发了我的思考，其实在当今分布式应用的大环境下，我们还用之前老一套的定时任务去处理，确实会带来很多不便，比如这次的问题，如果采用分布式任务调度框架的话，是不是就能避免或者更早的发现这样的问题了？task1与task2的调度间隔为1s，但是因为task1与task2的执行时间都超过了1s，所以预期的时间间隔应该是。这里没有写每种分布式框架的原理，其实分布式调度框架的目的是一样的，所以注定了它的原理不会有太大的差异。对我们的业务场景而言，分布式调度框架的优点就是。...
FullGC没及时处理，差点造成P0事故
艾小仙的专栏
09-19 761
背景上线新功能后，要多观察。如果出现不稳定性的情况，需要高优先级查清原因，避免出现更大的问题。问题描述部分应用出现重启过程11:58，接到报警，一个pod1三分钟内存在重启12:02，pod1已经5分钟没有报警，数据已经正常恢复【有耗内存的功能，多人同时触发时，偶尔也会重启】12:06，JVM监控 节点机IP: 10.10.48.116 JVM_FullGC次数，最近2分钟求平均 >= 5....
可观测性-告警-JVM GC重要指标+告警指标
laker的博客
10-14 3177
如果一个线程在临界区时需要GC，那么它将允许它们完成，即调用相应的释放函数。如果一个线程在临界区时需要GC，那么它将允许它们完成，即调用相应的释放函数。对于 G1，这可能是一个主要的 GC，并且在例行的次要收集中看到。，而不考虑实际的分配大小，但是如果由于这个检查而触发，原因将被列为巨大的分配。jvm.gc.max.data.size : 老年代内存池最大size（即设置的老年代大小，单位字节）。jvm.gc.concurrent.phase.time：在 CMS 的并发阶段花费的时间。
记一次 CMS GC导致 FULL GC 时间开销很大的排查
Agly_Charlie的博客
12-22 2276
记一次 CMS GC导致 FULL GC 时间开销很大的排查背景定位分析过程第一次尝试解决方案CMS GC收集器分析了解CMS收集原理优缺点分析总结分析根因解决方案 背景 服务接入注册中心后，就会有实例健康检查，通过ip+port的方式访问接口，检查实例是否健康，某日有个实例出现了告警。检查发现是当时接口超时异常了，触发告警。 短暂的时间后，服务又正常恢复了，接口正常响应。观察日志没有异常问题。 定位分析过程 这个健康接口是个简单的返回，没有经过DB、缓存等。所以超时问题出现在服务本身。 查看CAT、
一次Full GC分析
iverson2010112228的专栏
10-11 954
背景 最近开始看gc日志，感觉颇有了解。但苦于手上没有例子来练手，结果昨天下午，受到joy-merchant-service的告警，表示有full gc，虽然这个不是我负责的服务，但是好不容易逮到怎么能不管，于是晚上饭后开始查看问题。 ![avatar][fullGCpng] 解决步骤 问题表现 我发现该服务线上共四台机器，每台机器在发布的时候都会发生full gc，但是 仅限于发布的时候，而且次...
java jvm-old gc耗时几十s，导致系统告警（csdn）————程序.pdf
12-01
问题描述中提到，生产环境中由于old GC耗时几十秒，导致系统出现告警，接口响应超时。通常，Java的垃圾收集分为年轻代（Young Generation）和老年代（Old Generation）两个主要区域。年轻代用于存储生命周期较短的...
记一次Flink任务Full gc的问题排查
weixin_39935887的博客
03-29 5706
最近发现flink任务vc_lark_rtc_event_job_new_test会每隔一两天会造成上游topic消费积压，后来发现是因为full gc(Full GC(Ergonomics)通过TM中的gc.log.0.current日志文件查看)频繁导致cpu飙升，造成数据处理不过来造成积压，查看Dtop监控可以看到 然后进入到tm中，如下图： 点击webshell， ...
FullGC没及时处理，差点造成大事故
gg10748的博客
06-07 1090
目前的这个场景所涉及到的查询结果数据，被用于数据权限控制，返回的数据变多时造成的问题是，该看到该数据的人可以看到，不该看到该数据的也可以看到。只是串行查询TableStore，虽然会耗内存，但如果正在执行的pod没有其它在执行的耗内存操作，是不会触发FullGC的。想着是两年前的线上代码，code reivew就没有作为重点，具体过程，相关的同学都不记得了。新业务场景是接收到mq消息然后根据条件去触发这段老代码，当同时接收n个消息，则占用的内存*n ，则很容易触发FullGC。那么，测试是通过的。
频繁full GC排查
小太阳DENGJIE的博客
10-24 2037
场景：通过prometheus去拉取通过actuator组件暴露的端点中的JVM相关指标。通过告警规则，检测线上服务出现频繁full gc。
java排查full gc_一次频繁Full GC问题排查过程分享
weixin_29471009的博客
02-25 1035
问题描述应用收到频繁Full GC告警问题排查登录到对应机器上去，查看GC日志，发现YGC一分钟已经达到了15次，比Full GC还要频繁一些，其中Full GC平均10分钟超过了4次，如下图 使用jstat -gcutil 5280 1000查看实时GC情况，年老代采用的是CMS收集器，发现触发Full GC的原因是年老代占用空间达到指定阈值70%(-XX:CMSInitiatingOccupa...
记录一次gc报警背后的思想推演
zhang6622056的专栏
09-06 1021
记录一次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频繁，第一反应就是流量有对应增加，而结果也确实是这样
一次线上频繁FullGC的排查
码农无双的博客
03-12 4111
背景 一日，线上的某个服务的某个节点突然告警，频繁地FullGC，这个服务已经有半个月没有进行过发布和容器重启了。 处理步骤 首先将告警的容器隔离，从网关上摘掉这个节点，让流量不再进入到这个节点。 通过jmap将节点的内存快照dump下来。 通过jprofiler分析hprof文件。 分析原因 有很多工具可以方便地分析hprof文件，如MAT、JProfiler。 我们通过JProfiler分析，在JProfiler的启动中心打开单个快照。 选择下载到本地的hprof文件，等待一会解析，然后直奔“最大
记一次频繁生产频繁full-gc事件
qq_34679704的博客
03-15 492
记一次频繁生产频繁full-gc事件
fullgc频繁的原因_记一次服务Full GC背后的内存泄漏问题，真是匪夷所思
weixin_39517357的博客
11-20 1239
1. 告警最近所负责的服务略频繁地收到4xx告警2. 问题定位1、查业务日志，没发现相关错误的日志2、查nginx access log，发现返回的状态码都是499，从request_uri查了一遍发现不是集中在某一个请求上，说明应该不是某个接口的问题了，有可能进程层面问题了。通过对upstream_addr 分类，可以看到问题基本都是集中在 某一台这台机器上3、网上资料了解到，499 是 ngi...
【JVM补充】频繁fullgc的解决思路
言淮的博客
05-12 2559
背景 最近在整理JVM的知识体系，想到了大家平时都会讨论了一个话题，当然也是面试常问的一个话题，就是发生频繁fullGC的情况，我们应该如何应对，如何找到问题并且如何解决问题，这是让人 头大 的事情。 发现问题 我们先思考一下，我们平时是怎么发现频繁fullgc的，它的表现形式有哪些，这里只列举出来我能想到的几个点，可能还有其他的表现形式。 CPU满载告警 API响应时间过长 内存反复波动 主动GC … 定位问题 ...
JVM性能调优：线上 JVM GC 频繁耗时长，出现 LongGC 告警！
Java精选
10-12 1107
1. 背景多个业务线的应用出现LongGC告警最近一段时间，经常收到CAT报出来的Long GC告警（配置为大于3秒的为Longgc）。2. 知识回顾2.1 JVM堆内存划分新生代（Young Generation）新生代内被划分为三个区：Eden，from survivor，to survivor。大多数对象在新生代被创建。Minor GC针对的是新生代的垃圾回收。老年代（Old Generat...
tomcat启动时内存泄露的告警
最新发布
01-03
### 原因分析 内存泄漏警告通常意味着应用程序在运行过程中未能释放不再使用的对象，导致可用内存逐渐减少。对于Tomcat服务器而言，可能的原因包括但不限于： - 应用程序代码中的静态集合类（如`HashMap`, `ArrayList`等）持续增长而不清理。 - 使用了第三方库或框架存在已知的内存泄漏问题。 - Tomcat自身的某些组件配置不当。 针对特定情况提到的服务大量超时以及OOM Killed现象[^2]，这表明不仅有内存泄漏的可能性，还可能存在其他因素影响着系统的稳定性和性能表现。例如，在Go项目中如果设置了过低的内存限制（如1GB），当业务逻辑频繁访问数据库并处理大数据集时很容易触发内存溢出错误；而在Java环境中，则需关注JVM参数设定是否合理，尤其是最大堆空间(-Xmx)、最小堆空间(-Xms)，以及其他与垃圾回收机制密切关联的各项属性值[^3]。 ### 解决方案 #### 修改Catalina脚本增加调试选项 编辑位于E:\apache-tomcat-5.5.20\bin目录下的catalina.bat批处理文件，添加如下几项重要的JVM启动参数来帮助诊断和预防潜在的内存泄漏问题: ```batch set JAVA_OPTS=%JAVA_OPTS% -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=E:\tomcat_heapdumps\ ``` 上述命令会在发生Out Of Memory Error(OOM)的时候自动保存heap dump文件至指定位置以便后续分析。 #### 合理调整JVM参数 基于当前硬件条件适当增大-Xmx, -Xms数值可以有效缓解短期压力，但长期来看仍要找出根本原因所在。另外建议开启GC日志记录功能用于监控每次Full GC前后的情况变化： ```bash set JAVA_OPTS=%JAVA_OPTS% "-XX:+PrintGCCause -XX:+UseConcMarkSweepGC ``` 同时考虑到NIO缓冲区可能导致额外开销，可考虑加入-Djdk.nio.maxCachedBufferSize=xxx 和 -XX:MaxDirectMemorySize 参数控制其上限范围[^4]: ```bash set JAVA_OPTS=%JAVA_OPTS% -Djdk.nio.maxCachedBufferSize=8m -XX:MaxDirectMemorySize=256m ``` #### 工具辅助排查 利用专业的工具来进行更深入细致地剖析也是必不可少的一环。比如IBM HeapAnalyzer 或者 Alibaba Cloud提供的Arthas都可以很好地胜任这项工作。通过这些工具能够直观看到哪些地方占用了过多资源从而进一步缩小怀疑区间直至最终定位具体源头[^5].
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值