一次MAT分析logstash内存溢出

一、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自动分析泄漏的原因。

 Histogram如下图：

     Objects:类的对象的数量。

     Shallow size：就是对象本身占用内存的大小，不包含对其他对象的引用，也就是对象头加成员变量（不是成员变量的值）的总和。

     Retained size：是该对象自己的shallow size，加上从该对象能直接或间接访问到对象的shallow size之和。换句话说，retained size是该对象被GC之后所能回收到内存的总和。

把内存中的对象看成下图中的节点，并且对象和对象之间互相引用。这里的特殊节点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[]

Details »

  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[]

Details »

  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[]

Details »

  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[]

Details »

 Hint 1

The problem suspects 1, 3 and 4 may be related, because the reference chains to them have a common beginning.

Details »

查看可疑对象org.jruby.RubyObject 的详细分析报告：

查看下从 GC 根元素到内存消耗聚集点的最短路径：

Shortest Paths To the Accumulation Point 

Class Name	Shallow Heap	Retained Heap
byte[101294942] @ 0xd32bc220 [2016-12-22 14:17:00.950] [INFO] [http-nio-8080-exec-57] [c.vip.goods.tools.controller.StockCheckController] >>> [method_execute] json={"startTime":"2016-12-22 14:15:54.309","className":"StockCheckController","endTime":"2016-12-22 14:16:57.510","methodName...	101,294,960	101,294,960
bytes org.jruby.util.ByteList @ 0xd31b9c98	40	101,295,000
value org.jruby.RubyString @ 0xd31b9c70	40	101,295,040
value org.jruby.RubyHash$RubyHashEntry @ 0xd31b9ea0	40	101,295,120
nextAdded org.jruby.RubyHash$RubyHashEntry @ 0xd31bac90	40	40
head org.jruby.RubyHash @ 0xd31ba570	56	101,295,888
[1] java.lang.Object[5] @ 0xd31b9f40	40	101,296,600
varTable org.jruby.RubyObject @ 0xd17d9020	32	101,296,632
[0] org.jruby.runtime.builtin.IRubyObject[16] @ 0xd31bc090	80