解决线上OutOfMemoryError: GC overhead limit exceeded问题

线上出现OutOfMemoryError如何排查解决

背景:公司之前给甲方开发了一个服务,因为数据问题,甲方要求部署在他们自己的服务器上,后来发现这个服务跑了一段时间后就会挂掉,一直找不到问题,重启以后有没有问题,过段时间又会出现这个问题,之前同事去甲方那边拿到了服务的日志,可以看到日志中一直报错:java.lang.OutOfMemoryError: GC overhead limit exceeded
具体日志信息如下图
在这里插入图片描述
说实话这个日志除了可以断定是堆内存溢出的问题以外,确实看不出是哪里的问题导致的

解决方案:
一开始只有一个log日志,我就想这能不能直接分析日志,看出问题,然后找了一个线上GC日志分析的网站,直接导入日志分析GC日志分析网站
在这里插入图片描述
分析出来是这个鬼, 我也很绝望,后来网上搜索要拿到dump日志进行分析。但是这个确实拿不到,因为甲方自己部署的,我们也没得权限连他们的服务器。

后来想只能通过测试环境来复现解决 这个,就把测试环境重启了,带上打印dump日志的jvm参数:
具体相关JVM参数如下:
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/usr/local/log/ 输出dump日志的文件路径,这个路径中的文件夹都必须存在

重启以后,在测试环境进行了全功能测试,跑了两个功能确实出现系统变卡,开始挂机的情况,查看log日志也开始报GC问题,后来就将dump日志导出,然后通过jdk自带的工具jvisualvm导入日志进行分析
在这里插入图片描述
生成日志后可以看到出现OutOfMemory的线程,点进去可以看到具体报错内容
在这里插入图片描述
上面是具体的报错行,找到代码发现是excel导出,生成excel的时候出现的问题,数据量3万多条,直接导出,单线程操作这里就会报OutOfMemoryError: GC overhead limit exceeded,GC问题的难点在于排查问题点在哪里,问题找到解决其实很简单,我这里是后台数据量过大,并且在导出的时候会根据当前数据生成一个excel对象,数据量过大导致这里产生大对象,而且整个导出响应变慢。这个时候用户继续点击导出按钮,请求到达后台,导致一直产生导出实体bean对象和excel对象,方法执行的慢,gc回收释放的空间有限,这些大对象没操作完无法释放,就导致内存不够,直接出现OOM问题,系统由前期的卡顿,直接变为无响应挂机。
说实话:在对整个系统并不熟悉的基础上,确实很难对系统的堆栈继续分析,所以,必要的时候还是要拿到堆栈信息和gc相关的信息才能分析问题。如果是公司内部主机,其实可以直接通过jdk的一些命令拿到程序当前的这些信息

参考博客:
https://www.jianshu.com/p/cfe08044045b
https://zhuanlan.zhihu.com/p/43435903

### Kettle 中 `OutOfMemoryError: GC overhead limit exceeded` 错误解决方案 当遇到 Java 应用程序中的 `java.lang.OutOfMemoryError: GC overhead limit exceeded` 错误时,表明应用程序花费过多的时间执行垃圾回收操作却只恢复少量内存[^1]。对于 Kettle 脚本而言,这通常意味着 JVM 堆空间不足或存在潜在的内存泄漏。 #### 修改 JVM 参数配置 为了缓解此问题,可以调整启动 Kettle 的 JVM 参数来优化堆内存分配: - **增加最大堆大小**:通过设置 `-Xmx` 参数增大可用的最大堆内存量。例如,将最大堆设为 2GB 可以这样指定: ```bash kettle.sh -Xmx2048m ``` - **禁用 GC 开销限制**:可以通过添加 `-XX:-UseGCOverheadLimit` 来取消默认启用的 GC 成本保护机制,但这仅作为临时措施而非长久之计。 ```bash kettle.sh -XX:-UseGCOverheadLimit ``` 这些更改可以帮助暂时绕过错误并允许作业继续运行,但并不能从根本上解决问题所在[^4]。 #### 审查数据处理逻辑 除了调整 JVM 设置外,还应该审查 ETL 流程本身是否存在低效的数据处理方式,比如一次性读取大量记录入内存而不是分批处理;或是有循环引用造成对象无法被及时释放等问题。确保所有大尺寸集合都尽可能早地清理不再使用的元素,并考虑采用流式处理模式减少瞬态存储需求[^3]。 #### 日志分析与监控工具的应用 利用日志文件定位具体哪个阶段触发了异常是非常重要的一步。同时借助于专业的性能剖析器(如 VisualVM 或 JProfiler),能够更直观地观察到应用内部的状态变化趋势以及各组件间的交互情况,从而为进一步诊断提供依据[^5]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值