Finding Memory Leaks with SAP Memory Analyzer
Introduction
There is a common understanding that a single snapshot of the java heap is not enough for finding a memory leak. The usual approach is to search for a monotonous increase of the number of objects of some class by “online” profiling/monitoring or by comparing a series of snapshots made over time. However, such a “live” monitoring is not always possible, and is especially difficult to be performed in productive systems because of the performance costs of using a profiler, and because of the fact that some leaks show themselves only rarely, when certain conditions have appeared.
In this blog I will try to give some guidelines how one could find the unwanted memory accumulation without having to sleep besides the servers in the office – with the help of the recently released “SAP Memory Analyzer” tool, and a couple of tricks .
Preparation
First make sure that you will get sufficient data for the troubleshooting even if the problem occurs when you are not on the system. For this purpose configure the JVM to produce a heap dump when an OutOfMemoryError occurs (see description here).
The second step of the preparation is to enable the memory leak to become more visible and easily detectable. To achieve this use the following trick – configure the maximum size of the java heap to be much higher (say it twice) than the heap used when the application is running correctly (e.g. set it to be twice as much as what is usually left after a full GC). Even if you don’t know how much memory the application really needs, increasing the heap is not a bad idea (it may turn out that there is no leak but simply more heap is required). I don’t want to go into discussions if running Java applications with too big heaps is a good approach in general – simply use the tip for the time of the troubleshooting.
What do you gain by this change? If the VM throws an OutOfMemoryError with this configuration it will produce a heap dump in which the size of the objects related to the leak will be about the half of the total heap size, i.e. it should be relatively easy to detect the leak later.
Analysis – Case 1
Now imagine that after the latter configurations are activated, you go to the office in the morning and find that the error has reoccurred and there is a nice big heap dump in the file system. What is next? Well, believe it or not, what follows is the easier part.
First, open the heap dump with the “SAP Memory Analyzer” tool. One may have to wait a bit for the initial parsing if the heap dump is too big, but subsequent reopening will be instant (see some performance metrics here).
Then let’s search who has eaten up the memory. Go to the Dominator tree view.
There you will find the object graph transformed in a tree – a special kind of tree showing the objects’ dependencies, and not simply the references between them. I won’t go into details about the theory behind this tree, but I’ll simply list some of its key properties:
– On the top of these tree (i.e. what you see immediately after opening it) one can find the biggest objects in the heap
– All descendants of an object in the dominator tree are being retained by it (meaning that they will be garbage collected if the object is garbage collected). The biggest objects are the ones which retained most heap
In most of the cases when there is a leak one will immediately notice it by looking at the size of the biggest object. To go a bit “closer” to the real accumulation point one should expand the tree under the biggest object until a significant drop in the retained sizes of the parent and the children is seen (usually this will be some kind of a collection or an array). Well, it’s so easy. You found it! If you are interested you can also analyze the content by further exploring the dominator tree.
The next thing to do is to see the real reference chain from the GC roots. Simply call “Paths from the GC roots” from the context menu on the accumulation point object.
In the “Paths from the GC Roots” view one can see the references with the names of the fields.
Analysis – Case 2
It would be nice if every problem was so easily found. Sometimes however the first look at the dominator tree is not enough. But one more click should make the second look sufficient. One click, but where? On the “Group by class” button from the toolbar. Here is some explanation. Previously we have configured big enough heap for the leak to grow. And we also have a dominator tree covering the full object graph that also includes the leak. So, why don’t we see it? In the example we just looked at all the small leaking objects were dominated by one single object whose retained size was huge. But sometimes it may happen that the leaking objects themselves are on the top of the dominator tree. Even though they are many in number, each of them is small in size and is therefore not displayed among the biggest objects.
However, if we manage to find the whole group of leaking objects and see their aggregated size, then the leak will be as easily noticed as in the previous example. This is namely achieved by grouping the objects by their class.
So, did you find the memory eater now? I hope the answer is “Yes”. If not, please let me have the heap dump you are looking at and I’ll try to extend and complete the description.
Finding Memory Leaks with SAP Memory Analyzer的更多相关文章
- Android性能优化之被忽视的Memory Leaks
起因 写博客就像讲故事.得有起因,经过,结果,人物.地点和时间.今天就容我给大家讲一个故事. 人物呢.肯定是我了. 故事则发生在近期的这两天,地点在coder君上班的公司.那天无意中我发现了一个奇怪的 ...
- On Memory Leaks in Java and in Android.
from:http://chaosinmotion.com/blog/?p=696 Just because it's a garbage collected language doesn't mea ...
- [转]Activitys, Threads, & Memory Leaks
转自:http://www.androiddesignpatterns.com/2013/04/activitys-threads-memory-leaks.html http://www.cnblo ...
- Find out when memory leaks are a concern and how to prevent them
Handling memory leaks in Java programs Find out when memory leaks are a concern and how to prevent t ...
- Identify Memory Leaks in Visual CPP Applications —— VLD内存泄漏检测工具
原文地址:http://www.codeproject.com/Articles/1045847/Identify-Memory-Leaks-in-Visual-CPP-Applications 基于 ...
- 解决:Detected memory leaks
最近在一个项目中,程序退出后都出现内存泄漏: Detected memory leaks!Dumping objects ->{171} normal block at 0x05785AD0, ...
- [Angular2 Router] Exiting an Angular 2 Route - How To Prevent Memory Leaks
In this tutorial we are going to learn how we can accidentally creating memory leaks in our applicat ...
- The Introduction of Java Memory Leaks
One of the most significant advantages of Java is its memory management. You simply create objects a ...
- 【转】简单内存泄漏检测方法 解决 Detected memory leaks! 问题
我的环境是: XP SP2 . VS2003 最近在一个项目中,程序退出后都出现内存泄漏: Detected memory leaks! Dumping objects -> {98500} n ...
随机推荐
- Springmvc ajax请求400
转载做记录 传JSON对象 前端 function test () { var param = {username : "yitop"}; $.ajax({ timeout : 2 ...
- EDMX 残余表信息清理方法
今天出现的edmx报错,怎么也无法删除的问题,解决了.1.打开edxm2.删除所有表模型3.右键,选择模型浏览器4.在实体类型查看是否还有没有删除的模型如果有,点击删除5.重新生成edxm.解决问题.
- Jenkins启动报端口被占用,解决办法FAILED ServerConnector@2a265ea9{HTTP/1.1}{0.0.0.0:8080}: java
修改Jenkins端口java -jar jenkins.war --httpPort=8081
- question?
- c++ 字符输入读取
cin.clear()重置输入流 cin.get()锁住屏幕直到获取输入 while(cin) cin.get(ch) 方法返回的是一个cin对象,istream类提供了可以将istream对象转换为 ...
- 关于PHP导出excel文件名乱码的问题
关于PHP导出excel文件名乱码的问题 对于中文的文件名使用,urlencode即可避免此问题 urlencode() 申请的urlencode()
- 【Oracle】Oracle 10g利用闪回挽救误删的数据
我们在开发和运维过程中,经常遇到数据被误删除的情况.无论是在应用开发中的Bug,还是修改数据的时候,如果提交了错误数据修改结果,会带来很多问题.一般来说,一旦提交commit事务,我们是不能获取到之前 ...
- ZooKeeper架构
ZooKeeper服务器端运行于两种模式下:独立模式(standalone)和仲裁模式(quorum).独立模式几乎与其术语所描述的一样:有一个单独的服务器,ZooKeeper状态无法复制.在仲裁模式 ...
- Eclipse修改tomcat初始分配空间参数
正常启动tomcat后,运行报java.lang.OutOfMemoryError: PermGen space,查阅是tomcat内存溢出,也就是分配给tomcat的永久内存小了点 在Eclipse ...
- 查看端口占用情况lsof,并关闭对应进程kill
lsof -n -P| grep ":<端口号>" | grep LISTEN #监听对应端口号的进程 lsof -i tcp:<端口号> #和对应端口号有 ...