OutOfMemoryError: GC Overhead Limit Exceeded错误处理

OutOfMemoryError: GC Overhead Limit Exceeded错误处理

最近线上遇到一个问题,服务日志正常打印,但是接口调不通,重启服务后正常。

为了找到问题所在,那就翻日志,究竟是哪里出现异常,结果发现 OutOfMemoryError: GC Overhead Limit Exceeded 错误。

初步判断有内存溢出。但是没有dump日志,不好分析。所以在启动脚本中加上了:-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/psm/psm/logs/gc/  ,将OutOfMemoryError 的dump日志打印保存,

一段时间之后又遇到这种问题。现在有dump文件可以看了。服务器相应目录里有这种文件名:java_pid6705.hprof,download下来用jdk自带的jvisualvm.exe打开,在java的bin目录里能找到这个工具。

如图:

点击错误线程到相应的错误位置

按描述基本可以看出问题所在。

结合日志查询可得出结论:

结果是:有人查询数据的时候没有限制分页,直接把pagesize放到最大,查询出来的数据太多,导致内存超出了限制。

解决方法:限制分页数,设置默认值

其他情况解决方案,网上也有很多如:

           增加堆大小,启动脚本添加参数-Xmx1024m

           关闭GC Overhead limit:-XX:-UseGCOverheadLimit (都建议不推荐此方法,个人也不推荐,有可能会引发其他问题如java.lang.OutOfMemoryError: Java heap space错误)

 

 

### 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]。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值