Analyze Tomcat memory overflow at once using Eclipse memory analyzer

Recently, the online production system suddenly frequent the JVM memory alarm! But the system has not been changed in the near future!

In order to identify the cause of the memory alarm, the JVM Dump file was analyzed using the Eclipse memory Analyzer tool (MAT)!

1. Generate Dump File

Production of dump files with Jmap

Jmap-dump:format=b,file=heapdump.bin <pid>

2. MAT Installation and introduction

: http://www.eclipse.org/mat/downloads.php

650) this.width=650; "src=" http://www.zhangsr.cn/resources/img/blog/attachment/201502/1_20150209180326.jpg "style = "Font-family:simsun;font-size:14px;white-space:normal;background-color:rgb (255,255,255);" Alt= "1_ 20150209180326.jpg "/>

Open the dump memory file through the MAT and open it as follows:

650) this.width=650; "src=" http://www.zhangsr.cn/resources/img/blog/attachment/201502/1_20150209180332.jpg "style = "Font-family:simsun;font-size:14px;white-space:normal;background-color:rgb (255,255,255);" Alt= "1_ 20150209180332.jpg "/> 650) this.width=650;" Src= "http://www.zhangsr.cn/resources/img/blog/attachment/ 201502/1_20150209180338.jpg "style=" Font-family:simsun;font-size:14px;white-space:normal;background-color:rgb ( 255,255,255); "alt=" 1_20150209180338.jpg "/>

Histogram can list objects in memory, the number of objects, and their size.

Histogram such as:

Objects: The number of objects of the class.
Shallow size: The size of the object itself, which does not contain a reference to other objects, that is, the sum of the object header plus the member variable (not the value of the member variable).
Retained size: Is the object's own shallow size, plus the sum of the shallow size from which the object can be accessed directly or indirectly to the object. In other words, the retained size is the sum of the memory that the object can be recycled to after it has been GC.

We find that the objects of the Concurrenthashmap class occupy a lot of space.

650) this.width=650; "src=" http://www.zhangsr.cn/resources/img/blog/attachment/201502/1_20150209180345.jpg "style = "Font-family:simsun;font-size:14px;white-space:normal;background-color:rgb (255,255,255);" Alt= "1_ 20150209180345.jpg "/>

Leak Suspects such as:

From that pie chart, the dark area of the image is suspected of a memory leak, and the entire heap of 2G memory can be found, with a dark area accounting for 98%. The following description shows that memory is consumed by an instance of memory and indicates that the system class loader loaded "java.util.concurrent.concurrenthashmap$segmen[" instances are clustered in memory (consuming space), It is recommended to check with the keyword "java.util.concurrent.concurrenthashmap$segmen[". So, MAT explains the problem with a simple report.

650) this.width=650; "src=" http://www.zhangsr.cn/resources/img/blog/attachment/201502/1_20150209180403.jpg "style = "Font-family:simsun;font-size:14px;white-space:normal;background-color:rgb (255,255,255);" Alt= "1_ 20150209180403.jpg "/>

Dominator Tree like:>

We opened the CONCURRENTHASHMAP memory structure layer by level, found that there is a lot of Key, and the lowest String length is very large!

Fortunately the downstream of the system is also our responsible system, guess Concurrenthashmap should be RPC call back value to be processed memory storage, normally the length of this String is not very large. Looking closely, the String contains a lot more detailed exception description information, which was not previously.

650) this.width=650; "src=" http://www.zhangsr.cn/resources/img/blog/attachment/201502/1_20150209180411.jpg "style = "Font-family:simsun;font-size:14px;white-space:normal;background-color:rgb (255,255,255);" Alt= "1_ 20150209180411.jpg "/>

Troubleshoot downstream system code, and find that when an exception is returned, it differs from the previous exception throw:

try {} catch (Exception e) {throw e;} ... try {} catch (Exception e) {throw new Exception ("xxxx", e);}//Return pseudo-code RESPO NSE (E.getmessage);

Is that there are these differences, we look at the source code:

Public Throwable (String message, throwable cause) {fillinstacktrace ();    detailmessage = message; This.cause = cause;}    Public Throwable (Throwable cause) {fillinstacktrace ();    Detailmessage = (cause==null? null:cause.toString ()); This.cause = cause;} Public String GetMessage () {return detailmessage;}

When there is no message,message = cause.tostring (), so the return of a large number of unnecessary anomaly information, thus affecting the upstream system!

Reference:

http://tivan.iteye.com/blog/1487855

—————————— This article is published synchronously in ZHANGSR My personal blog ——————————

This article is from the "Sword of the Decade" blog, please be sure to keep this source http://sauron.blog.51cto.com/5231038/1614362

Analyze Tomcat memory overflow at once using Eclipse memory analyzer