Friday Dec 07, 2007

JConsole to isolate the Memory leak case

In this blog entry I want to provide you with a tip in order to help you answer to the fact that there is or not a memory leak in your application.

In some cases, where you are instantiating a lot of objects in a very short period of time, you can observe some huge memory consumption making the application to run out of memory. When it happens, we are (too?) quickly identifying this problem as a Memory leak and forget that the application can have reached some badly set JVM memory threshold causing OutOfMemory exception.

In order to distinguish between theses cases, I am using JConsole in a very very simple and quick way.

Steps to follow to isolate the case

1) Keep the JVM activity below the OutOfMemoryException to occur. For example, if your server crashes after 10000 received requests, tune your test case to deal with only 5000 requests. Doing so you will not run out of memory.

2) Start the application you want to monitor.

3) Start JConsole and attach it to your application. If your are using NetBeans, click on the "Run Main Project with Monitoring and Management" toolbar button.

Your project is compiled, run and JConsole automaticaly attached to it.

4) Click on JConsole Memory Tab and call Perform GC button located on the top right corner. The memory consumed during the application startup is released.

5) Start the activity (start a client application that will connect to the server, call a JMX MBean that initiates some activity, ...). Thanks to JConsole you will follow the memory allocation. Some big numbers can be reached there. In the example below, my server is simply serving simple Web Services Request. The memory consumed reaches 200 Megs...

6) Once the activity is stopped, you will notice that the amount of consumed memory is still very high. Call Perform GC multiple time to make sure that the GC is actually freeing the consumed memory.

7) Now you have 2 cases, or the memory consumed number is similar to step 4 and you are not experiencing a memory leak, or it stays high and you found a memory leak. In this example, the memory consumption is high but is not linked to any memory leak. You will notice that the Old Generation Memory pool (last vertical bar on top of Heap label) is cleared. There is no accumulation. In case of memory leak, you would have seen that this pool contains some objects. Mandy Chung wrote a blog entry that describes such case.

You can now take the right action. Or you allocate more memory for your application (use -Xmx JVM option for example), or you start investigate your problem (eg: by using NetBeans Profiler).

Jean-Fran├žois

About

jeanfrancoisdenise

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today