一次真实的线上 OOM 问题定位

概述

       近日,负责的一系统生产环境上出现了OutOfMemoryError,伴随着这个问题随之而来的是一堆Full GC, CPU 百分之百,频繁宕机重启等问题,严重影响业务的推广及使用,此类问题一般处理起来比较棘手,本文将此问题的出现及定位解决过程做下梳理,以便对后续处理类似问题提供参考指导。       注:该问题前面发了一版,因有些描述不太恰当,后来删除了,少数先得者看到了,想再看下发现已被删除,私信咨询我怎么找不到了,由此可见,很多同事还是比较在意此类问题的,很好,重新梳理下,补上一篇。

问题出现

软件:WildFly standalone 8.1.0.Final(OpenJDK)
报警内容:日志中有OutOfMemoryError信息
环境:PRD
报警级别:严重
报警时间:2019-04-09 11:04:59
当前时间:2019-04-09 11:06:03
监控项名称:jboss日志OutOfMemoryError
最新数据:2019-04-09 11:03:38,791 ERROR [stderr] (RMI RenewClean-[net.sf.ehcache.distribution.ConfigurableRMIClientSocketFactory@1d4c0]) Exception in thread "RMI RenewClean-[net.sf.ehcache.distribution.ConfigurableRMIClientSocketFactory@1d4c0]" java.lang.OutOfMemoryError: Java heap space

第一步: 重启服务

做好机器隔离,重启服务,保证不影响业务使用!

第二步: 收集dump文件

第三步: 利用JVM故障处理工具分析问题

打开jvisualvm工具

载入dump文件

查找保留大小最大的对象

重点关注前几位

查看实例数最大的实例

分析可能的原因

从实例上看JDBC42ResultSet占用空间最大,从而大胆猜测与查询相关,那么就看详情中能否找到是哪个sql导致的问题, 查看owningstatemeng语句集:

查看原始sql: originalSql

sql详情:

纳尼,where 1=1?相当于没带条件查所有记录,那么,表中有多少记录呢,不多,也就20万不到吧

至此,改问题的原因似乎显而易见。

第四步:紧急发布

于当晚拉紧急版本,通宵发布处理,以免问题重现。

总结

此问题是由于研发人员疏漏,查询字典表数据未带查询条件,导致查出表中所有记录进行ORM处理导致内存溢出。定位过程看似简单,但如何能在第一时间迅速排查原因并给出解决方案,难度还是不小的,由于缺乏经验,往往不知该怎么入手,况且线上异常场景复杂多变,不保证这个地方优化了,后续就没有问题了,需要在 现网环境经住考验 才行。

事实证明,此问题优化后,现网仍然有较多其他问题待解决,目前正在组织专家会诊,待后续有时间再做总结吧。

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章