Press "Enter" to skip to content

数据清洗中的OOM异常追踪


产品:叮(一份execl传送过来),这是今天要清洗的数据。
我:嗯????什幺情况???
产品:之前新增一个字段,需要将历史数据补充完毕
我:我在开发需求
产品:好的,今天洗完
我:……..我洗!

于是今日写好数据清洗程序之后,就让运维小哥跑一下,在清洗过程中出现了 OOM 的异常情况。然后让运维小哥哥将对应的线程栈信息以及内存信息 dump 下来。

 

先说明发生 OOM 的可能原因:

outOfMemoryError 年老代内存不足。
outOfMemoryError:PermGen Space 永久代内存不足。
outOfMemoryError:GC overhead limit exceed 垃圾回收时间占用系统运行时间的98%或以上。

在这里我们就要结合代码,观察是否大量应该被回收的对象在一直被引用或者是否有占用内存特别大的对象无法被回收。

 

问题展示

日志文件:

 

时间戳 [http-nio-端口号-exec-1] ERROR ResponseExceptionHandle:26 - Handler dispatch failed; nested exception is java.lang.OutOfMemoryError: GC overhead limit exceeded
org.springframework.web.util.NestedServletException: Handler dispatch failed; nested exception is java.lang.OutOfMemoryError: GC overhead limit exceeded
****中间一大段****
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded

 

这个时候要是有可视化界面就好了(或者拥有运维的电脑,自己用 Arthas 上去:joy:),没办法,只能让运维线程栈信息以及内存信息下载下来。

 

Linux上生成文件命令

 

# 生成堆转储快照dump文件命令
jmap -dump:format=b,file=heapdump.hprof pid
# 生成堆栈信息文件命令
jstack -l pid >> stack.txt

 

堆栈信息查看

 

"http-nio-端口号-exec-1" #37 daemon prio=5 os_prio=0 tid=0x00007f789d236800 nid=0x650e waiting on condition [0x00007f7851409000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x00000000faa51ba0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:103)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:31)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
   Locked ownable synchronizers:
- None
****等等容器内其他线程

 

上面只是我截取整个线程堆栈信息的一个容器线程状态查看,整个文件下来是没有发现 死锁 的发生,那线程方面是没有问题的,不会有线程相互竞争资源造成服务内部请求阻塞而造成 OOM 的情况发生。

 

堆转储快照查看

 

我们通过上面那条指令,以hprof二进制格式转储Java堆到指定filename的文件中。按照普通的文件方式打开肯定是行不通的(你在想啥呢?醒醒)。我这边是有两种方式去处理分析这种文件的。

 

1.利用 jhat

 

利用 JDK 里面的指令去分析文件(有时dump出来的堆很大,在启动时会报堆空间不足的错误,可加参数: jhat -J-Xmx512m <heap dump file> 。这个内存大小可根据自己电脑进行设置。):

接着你就可以在浏览器里面输入
http://localhost:7000/

进行访问:

当前页面是展示了当前容器内包含的类以及id。页面的最下面是导航栏了:


All classes including platform 显示堆中所包含的所有的类
Show all members of the Rootset 从根集能引用到的对象
Show instance counts for all classes(including platform)显示平台包括的所有类的实例数量
Show instance counts for all classes(excluding platform)显示除去平台包括的所有类的实例数量
Show heap histogram 堆实例分布表
Show finalizer summary 显示终结器概述
Execute Object Query Language(OQL)query 执行对象查询语句

一般查看堆异常情况主要看这个两个部分:

Show instance counts for all classes (excluding platform),平台外的所有对象信息。如下图:

Show heap histogram,以树状图形式展示堆情况。如下图:

要注意的是,一般不会直接在服务器上进行分析,因为jhat是一个耗时并且耗费硬件资源的过程,一般把服务器生成的dump文件复制到本地或其他机器上进行分析。

 

2.利用 Memory Analyzer

 

打开 matMAC端安装MAT )然后导入文件:

这里面参数说明很多(我到现在都没有看完全过:joy:):

 

Shallow Heap 表示一个对象消费的内存的总量。对象 X 的 Retained Set 指的是一旦 X 被垃圾回收后也会随之被 GC 回收掉的对象的集合。对象 X 的 Retained heap 指的是 X 的 retained set 中所有对象的 shallow heap 之和,或者说是因为对象 X而保持 alive 的内存的大小。

 

我们查看下面的选项:

 

    1. Histogram可以列出内存中的对象,对象的个数以及大小。

 

    1. Dominator Tree可以列出那个线程,以及线程下面的那些对象占用的空间。

 

    1. Top consumers通过图形列出最大的object。

 

    1. Leak Suspects通过MA自动分析泄漏的原因。

 

 

我们看到最大的那个区域就好(占用了41MB的):我们可以看到左下角是显示对象的名称: org.hibernate.internal.SessionFactoryImpl 。我们的技术栈持久成框架使用的是 hibernate (但是不怎幺对底层了解:joy:)。

 

我们点击 Leak Suspects ,然后出现:

经过 MAT 出现了两个怀疑内存泄露相关的问题:

我们通过查看下面的问题描述知道:

 

Question1:被 LaunchedURLClassLoader 类加载器加载的一个 SessionFactoryImpl 实例中的 BoundedConcurrentHashMap 堆积着内存空间,占据了42,984,656字节。

 

Question2:该内存中存在被 SystemClassLoader 加载的7,941个 Class 对象,占据了10,075,768字节。

 

从Q1入手进行查看:

 

    1. Description 描述信息

 

    1. Shortest Paths To the Accumulation Point 到堆积点的最短路径

 

    1. Accumulated Objects by Class in Dominator Tree 支配树中按类累积对象

 

    1. All Accumulated Objects by Class 所有按类累积的对象

 

 

我们这里就选择从下面三个都可以进行查看当前容器内部的内存堆积问题。上面的第二个是从堆积点一直追踪到线程,可以看到每一个线程对应的 Shallow Heap 以及 Retained heap

 

庖丁解牛中

 

我们这里就查看第三个:

我们查看到是 SessionFactoryImpl 中的 QueryPlanCache 中存在一个Map集合,该集合占据了大量的内存空间。这个类实际运用中还没有使用到过,不过看这个提示以及名称,个人觉得跟 ConcurrentHashMap 相似:joy:(有大佬对 BoundedConcurrentHashMap 了解的嘛,可以评论下让我涨涨知识)。通过 QueryPlanCache 的名字,就可以知道它是用来缓存查询计划的,也就是缓存sql语句,以便于后边的相同的sql重复编译。

 

我本次清洗的数据大约在40w的数据量,而且每个参数都是不相同的,那幺有可能会导致的 hibernate 在进行查询的时候,缓存大量的 sql 导致 heap 内存溢出(还是不怎幺了解我们的技术栈。。。惭愧惭愧),知道问题了,就要想办法解决去也~~~

 

Be First to Comment

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注