性能文章>一次真实的线上OOM问题定位>

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

2年前
8159311

image.png

概述

近日,负责的一系统生产环境上出现了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

第一步:重启服务

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

image.png

第二步:收集dump文件

image.png

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

打开jvisualvm工具

image.png

载入dump文件

image.png

查找保留大小最大的对象

image.png

重点关注前几位

image.png

查看实例数最大的实例

image.png

分析可能的原因

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

image.png

查看原始sql:originalSql

image.png

sql详情:

image.png

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

image.png

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

第四步:紧急发布

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

总结

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

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

本文来自公众号:依码平川,作者:王政

点赞收藏
牧杨
请先登录,查看3条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

【全网首发】(大表小技巧)有时候 2 小时的 SQL 操作,可能只要 1 分钟

【全网首发】(大表小技巧)有时候 2 小时的 SQL 操作,可能只要 1 分钟

【全网首发】JVM性能问题的自动分析

【全网首发】JVM性能问题的自动分析

【全网首发】揭密Java常用性能调优工具的底层实现原理

【全网首发】揭密Java常用性能调优工具的底层实现原理

干货!Java代码优化必知的30个小技巧!

干货!Java代码优化必知的30个小技巧!

JVM 优化踩坑记

JVM 优化踩坑记

Java 异步调用原理与实战

Java 异步调用原理与实战

11
3