一、logstash启动时报OOM(内存溢出),导致logstash进程一直启动不了。解决方法,删除sincedb文件后再启动logstash。事后用Eclipse 的memory analyzer工具分析heapdump文件,第一次使用MAT分析问题,此次记录下这次使用MAT时一些东西。
1、heapdump :
通过jvm参数--XX:-HeapDumpOnOutOfMemoryError可以让JVM在出现内存溢出是Dump出当前的内存转储快照;
2、MAT界面功能
从上图可以看到它的大部分功能。
1. Histogram可以列出内存中的对象,对象的个数以及大小。
2. Dominator Tree可以列出那个线程,以及线程下面的那些对象占用的空间。
3.Top consumers通过图形列出最大的object。
4.Leak Suspects通过MA自动分析泄漏的原因。
把内存中的对象看成下图中的节点,并且对象和对象之间互相引用。这里的特殊节点GC Roots,就是reference chain的起点。(http://blog.csdn.net/xb151652000/article/details/8056792)
从obj1入手,上图中蓝色节点代表仅仅只有通过obj1才能直接或间接访问的对象。因为可以通过GC Roots访问,所以左图的obj3不是蓝色节点;而在右图却是蓝色,因为它已经被包含在retained集合内。
所以对于左图,obj1的retained size是obj1、obj2、obj4的shallow size总和;右图的retained size是obj1、obj2、obj3、obj4的shallow size总和。obj2的retained size可以通过相同的方式计算。
Dominator Tree如下图:可以看到jruby类的线程占用了了很多的内存。
Top consumers如下:可以看出org.jruby.RubyObject对象占用了极大的内存以及该对象有极大的类数量。
Leak Suspects:我们可以看到内存是由 org.jruby.RubyObject的实例消耗的,system class loader 负责这个对象的加载;下面应该进一步去分析问题,为什么org.jruby.RubyObject 会占据了系统如此多的内存?
Problem Suspect 1
One instance of "char[]" loaded by "<system class loader>" occupies 198,214,576 (36.08%) bytes. The memory is accumulated in one instance of "char[]" loaded by "<system class loader>".
Keywords
char[]
Problem Suspect 2
One instance of "org.jruby.RubyObject" loaded by "<system class loader>"occupies 101,415,560 (18.46%) bytes. The memory is accumulated in one instance of"byte[]" loaded by "<system class loader>".
Keywords
org.jruby.RubyObject
byte[]
Problem Suspect 3
One instance of "org.jruby.RubyObject" loaded by "<system class loader>"occupies 101,302,352 (18.44%) bytes. The memory is accumulated in one instance of"byte[]" loaded by "<system class loader>".
Keywords
org.jruby.RubyObject
byte[]
Problem Suspect 4
One instance of "org.jruby.runtime.ThreadContext" loaded by "<system class loader>" occupies 101,300,280 (18.44%) bytes. The memory is accumulated in one instance of "byte[]" loaded by "<system class loader>".
Keywords
org.jruby.runtime.ThreadContext
byte[]
Hint 1
The problem suspects 1, 3 and 4 may be related, because the reference chains to them have a common beginning.
查看可疑对象org.jruby.RubyObject 的详细分析报告:
查看下从 GC 根元素到内存消耗聚集点的最短路径:
Shortest Paths To the Accumulation Point
Class Name | Shallow Heap | Retained Heap |
---|---|---|
101,294,960 | 101,294,960 | |
40 | 101,295,000 | |
40 | 101,295,040 | |
40 | 101,295,120 | |
40 | 40 | |
56 | 101,295,888 | |
40 | 101,296,600 | |
|
32 | 101,296,632 |
80 |