EMA :1: The Leak Suspects Report

This blog is about using Eclipse Memory Analyzer (EMA) to fix Out Of Memory (OOM) errors. You can do runtime profiling as well using JProfiler to figure out if a method is retaining a lot of heap , but EMA is far more useful in scenarios when you are having servers running on 2GB heap and you are frequently facing OOM errors. I was taking care of Fusion System Test environments where we have a separate domain for each Product Family like Financials (FIN), Supply Chain Management (SCM) etc, and there are managed servers for each sub family having 2GB heap (-Xmx2048m). For example, in case of FIN, we are having managed servers for Receivables, Payables etc. I am using this blog to share/document my findings.

Using the Leak Suspects Report

As  soon as you open the heap dump, you get the following dialog:

Selecting Leak Suspect Report option is very handy because if there is a big memory leak then Leak Suspects Report automatically lists which object is retaining most of the heap in a new tab, as shown below:

In the above snap, you can see that there is an active thread is referring to a connection pool which is retaining around 17% of heap. In this case, the next step would be to find out why connection pool is retaining so much of memory (or is there a connection leak going on), and what Thread 3 is currently doing.

However, sometimes it’s not that easy as this tool does not list any memory leak. Then you need to figure out yourself by using various other tools/options provided by EMA to find the root cause of memory pressure.

You can find any memory leak issue using EMA, and I have used to find out the following kind of issues in Fusion ADF technology stack:

1. View Object Leak.
2. Connection/Application Module Leak.
3. Statement Leak.
4. Issues Because of Logging Exceptions.
5. Passivation Issues.

Other posts in this blog explains each of the above topic in detail.