Memory Profiling for Novices ( Heap OutOfMemory OOME error )

Printer-friendly versionPDF version

So sometimes out of memory errors crop up in you application. But to troubleshoot these should not be that complicated. Let me show you with Oracle's Visual VM, how you can quickly get down to the root cause of your out of memory errors. All you need Oracle's Java JDK installed on your system and the VisualVM tool that comes with it. At the time of writing the version I used was with JDK 8 (1.8.0_144). On a Mac OSX system all you need to do is type "jvisualvm" on your terminal and it will just popup. If you have your paths properly setup under windows and linux, it should also just work. Otherwise navigate to the folder with this tool and open it manaully.

First things first, you need to have a usecase where you are observing the OOM error. I.e. you need to know the steps your user is performing and seeing the this error. Once you have those you are set to go. Start your application from your favorite Java Editor or directly. Your application will appear in VisualVM on the left hand side under the "Local" tree node. You need to right click on it and choose "Open". You will see 4 Tabs initially (ignore the 5 Tab you see below for now as we will get to it later). Now you are ready to profile your application. In the below image you can already see that the Heap size and Used Heap size for my application under the "Monitor" tab is growing. This is through the repeated execution of the steps that I know will eventually lead to the OOM error. So at this stage you can verify that you heap is growing for your particular use case and Performing a manual garbage collection operation on the "Monitor" tab with "Perform GC" button. But if you want to save some time, save the execution of these steps at this moment. And jump on to the next section that does some settings before you should proceed.

Visual VM attached to your application

So first step and this is just precautionary, enable the heap dump on OOME. This can be done by right clicking your application and choosing it from context menu as shown below.

Enable OOME

Now click on the Profiler tab and click the "Settings" checkbox on the top right hand corner. On the new tabs that appear, move to the "Memory Settings" tab and select the check box labelled "Record allocations stack traces". If the leaked classes are your own classes, than you don"t need this, as the alive objects that appear will show you allocated classes. Then you need to hunt down where you are allocating and not getting rid of these instances. But if you memory leak is other classes that you don"t own or like in arrays of primitive types (byte[] array was the culprit im my case), this option  is highly useful, as it will show you from which point in your code the problematic allocation occured. It will ofcourse also work for your own classes as well. So turning this option won"t hurt you but I think it will help in any case. Than you can click on the Memory button you see on this tab and Visual VM will start the profiling of your application. This can take a while. Wait for it to finish.

Settings for allocation stacktrace

Now you can move to the monitor tab again, and start the known steps for the OOME. Repeat the steps to the point when you think the heap size has grown enough and manual GC is not helping. We really don"t need to trigger the OOME error if it takes a long time if we can identifty the culprit from the trend. But even if the OOME error happens remember we enabled the heap dump that we can analyze. I won't go to that point. In my case I see the heap size has significantly allocated and rea-allocated and is not trimming down. So I move to the "Profiler" tab again. Click on the column "Live Bytes [%]" to bring to top the most memory taking objects.

Live Memory Profiler

Next right click the row with the most memory taking object on the top and click "Take Snapshot and Show Allocation Stack Traces". This will now open the 5th tab of the snapshot we saw in the first image. This will look something like below and will allow you to drill down the allocation stacktrace to most probably the points in your class where you allocated the objects that are holding onto the memory that you probably need to clean up. This would be the greyed out area in the image below for me.

Snapshot memory

Happy out of memory problem hunting.

 

Top level category:

Add new comment