记一次OOM排查解决

现场人员反馈tomcat假死,已不能访问,而且一直报如下异常:

SEVERE:Memory usage is low, parachute is non existent, your system may start failing.
java.lang.OutOfMemoryError: Java heap space

很显然堆内存溢出了,现场配置了2G的堆内存,用jmap命令dump heap失败,添加参数-F强制dump半天没有反应,只能带着-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tomcat/logs参数重启,过了半天问题又出现了,这次得到了堆内存的快照,用Memory Analyzer (MAT)分析,概要信息如下:

One instance of "org.hibernate.impl.SessionFactoryImpl" loaded by "org.apache.catalina.loader.WebappClassLoader @ 0x788c95390" occupies 1,567,956,008 (80.22%) bytes. The memory is accumulated in one instance of "java.util.concurrent.ConcurrentHashMap$Segment[]" loaded by "<system class loader>".

Keywords
org.hibernate.impl.SessionFactoryImpl
org.apache.catalina.loader.WebappClassLoader @ 0x788c95390
java.util.concurrent.ConcurrentHashMap$Segment[]

从这个概要信息可以看到这个OOM是和Hibernate有关的。

视图Biggest Objects by Retained Size如下:

可以看到对象org.hibernate.impl.SessionFactoryImpl @ 0x78ada8e98持有的对象竟然站到了1.5GB的大小。视图Shortest Paths To the Accumulation Point如下:

从上图可以清晰的看出对象org.hibernate.impl.SessionFactoryImpl @ 0x78ada8e98、org.hibernate.stat.ConcurrentStatisticsImpl @ 0x78b1f2378、java.util.concurrent.ConcurrentHashMap @ 0x78b1f2928之间的引用关系。

视图Accumulated Objects in Dominator Tree如下:

从此图可以看到org.hibernate.stat.ConcurrentStatisticsImpl @ 0x78b1f2378对象持有了大量的ConcurrentHashMap对象,占到了整个堆内存的80%,导致了内存泄漏。经查类ConcurrentStatisticsImpl和Hibernate的SQL、HQL统计有关,Hibernate有个参数hibernate.generate_statistics,这个参数可以统计执行的SQL和HQL的执行信息,此参数默认是false,当设置为true时Hibernate就会缓存每一个执行的SQL和HQL,当大量请求访问,Hibernate就会缓存大量的SQL从而导致内存溢出,将此参数设置为false问题解决。

原文地址:http://blog.51cto.com/wenshengzhu/2086935

时间: 2024-11-12 14:17:34

记一次OOM排查解决的相关文章

记一次OOM查询处理过程

记一次OOM查询处理过程 问题的爆出及分析排查现场 排查后的解决方案 项目的jvm参数 总结 一.问题的爆出及分析排查现场 服务偶尔会出现不可用的情况,导致出现time out,然后我迅速登录现场,直接查看当时的gc日志,不废话,直接上图 通过这个图可以发现在10点7分.8分的时候频繁Full GC,但是GC之后 年轻代,老年代并没有少.并且Full GC时长5s8多,造成stop-the-world5s8,因此应用程序会出现无影响.再贴一张图 通过这个可以看到内存慢慢的通过GC降下来了 根据这

13_FCITX输入法安装及问题排查解决

使用linux最沮丧的事情莫过于中文输入法切换不出来,甚至有人错误地认为,要使用中文输入法,必须把“区域和语言”(Region & Language)设置为中国-中文.输入法只是一个软件,和区域设置没有什么必然联系.如果你在初始化安装系统的时候,选择了中文,倒是会帮你把中文输 入法打包安装好. 所以和我一样使用en-us区域设置的朋友,如果输入法出了问题,怎么排查解决呢? 首选你必须安装一个中文输入法,推荐小企鹅 sudo yum install fcitx-pinyin 但是,安装完后,发现按

Atitit.提升稳定性-----分析内存泄漏PermGen OOM跟解决之道...java

Atitit.提升稳定性-----分析内存泄漏PermGen OOM跟解决之道...java 1. 内存区域的划分 1 2. PermGen内存溢出深入分析 1 3. PermGen OOM原因总结 2 4. 常见的类加载器和类型卸载的可能性总结 2 5. PermGen内存溢出的应对措施 3 6. 第二种就是使用oracle的BEA JDK,因为这个里面的JVM没有PermGen space 3 7. 参考 3 1. 内存区域的划分 java的内存泄漏基本上按照内存区域的划分可以分为: 1 堆

android mediaplayer VideoPlayerManager 加载视频闪屏问题排查解决

Android VideoPlayer 在滚动列表实现item视频播放(ListView控件和RecyclerView),在列表滚动时点击屏幕列表暂停,在item视频播放区域,视频播放时会出现闪屏问题. 排查解决,VideoPlayerManager->MediaPlayerWrapper.java->prepare() :                     { .prepareAsync().set(State.)(!= ) {                             

谨记一次问题排查经历

一个客户那儿: 1接收报文->2系统转码->3发送给处理程序->4处理程序调用数据库存储过程 现在系统数据库库内记录出现问题了:某个关键字段的值扩大了10倍:自某个时间4-19日开始发现该问题:上游厂商确定没有变动过接口. 经过:根据分析和经验,认定问题出现在2上,初步推断是上游接口发生变化而未告知(上游有前科).重新依据生产环境部署程序.重新测试.问题仍在.期间发现过和汇率可能有关系.当时没有程序源代码. 接下来..... 找上游争吵 ..... 最后:冷静下来,向公司原来负责该客户的

MySQL redo lock 死锁问题排查 &amp; 解决过程

版权声明:本文由 MySQL redo lock 死锁问题排查 & 解决过程 张青林 原创文章,转载请注明出处: 文章原文链接:https://www.qcloud.com/community/article/181 来源:腾云阁 https://www.qcloud.com/community 周一上班,首先向同事了解了一下上周的测试情况,被告知在多实例场景下 MySQL Server hang 住,无法测试下去,原生版本不存在这个问题,而新版本上出现了这个问题,不禁心头一颤,心中不禁感到奇怪

Redis性能问题排查解决手册(七)

阅读目录: 性能相关的数据指标 内存使用率used_memory 命令处理总数total_commands_processed 延迟时间 内存碎片率 回收key 总结 性能相关的数据指标 通过Redis-cli命令行界面访问到Redis服务器,然后使用info命令获取所有与Redis服务相关的信息.通过这些信息来分析文章后面提到的一些性能指标. info命令输出的数据可分为10个类别,分别是: server clients memory persistence stats replication

Redis(二十一):Redis性能问题排查解决手册(转)

性能相关的数据指标 通过Redis-cli命令行界面访问到Redis服务器,然后使用info命令获取所有与Redis服务相关的信息.通过这些信息来分析文章后面提到的一些性能指标. info命令输出的数据可分为10个类别,分别是: server clients memory persistence stats replication cpu commandstats cluster keyspace 这篇主要介绍比较重要的2部分性能指标memory和stats. 需要注意的是info命令返回的信息

记一个程序oom的排查过程

一,背景 收到应用服务报警,然后登录上服务器查看原因,发现进程不再了. 二,问题分析 1,那么判断进程被干掉的原因如下: (1),机器重启了 通过uptime看机器并未重启 (2),程序有bug自动退出了 通过查询程序的error log,并未发现异常 (3),被别人干掉了 由于程序比较消耗内存,故猜想是不是oom了,被系统给干掉了.所以查messages日志,发现的确是oom了: Jul 27 13:29:54 kernel: Out of memory: Kill process 17982