Hello Amit!
Below is your old gen memory usage.
If you notice memory just keeps growing slowly. But however this window is measured only from 12:00am to 02:15am (i.e. 2 hours). It's too short window to come to a conclusion. However if old gen continues to keep growing like this, then yes we can conclude your application is suffering from acute memory leak.
You can diagnose Memory leak either through a manual or automated approach.
Manual approach
In the manual approach, you need to capture heap dump as the first step. Heap dump is a snapshot of memory, which shows all the objects in memory, values contained by those objects, and their references. You can capture heap dump using one of the 7 approaches given here . But an important criteria is: You need to capture the heap dump right before OutOfMemoryError is thrown. If you are going to capture a heap dump, after OutOfMemoryError has occurred, then leaking objects can get garbage collected, and it will become hard (or even impossible) to diagnose the problem. Once heap dumps are captured, you need to import the heap dumps from your production servers to your local machine. From your local machine you can use heap dump analysis tools like jHat, HeapHero, Eclipse MAT to analyze the heap dumps. Here is a video tutorial, which may assist you with it.
Automated approach
You can use root cause analysis tools like yCrash - which automatically captures application-level data (thread dump, heap dump, Garbage Collection log) and system-level data (netstat, vmstat, iostat, top, top -H, dmesg, kernel parameters…). Besides capturing the data automatically, it marries these two datasets and generates an instant root cause analysis report. Below is the report generated by the yCrash tool when the above sample program is executed:
Fig: yCrash tool pointing out the root cause of OutOfMemoryError
You can notice the yCrash tool precisely pointing out the root cause of memory leak. You can register here to get a 14 day trial of yCrash.
Edit your Comment