1. Skip to Menu
  2. Skip to Content
  3. Skip to Footer>

Expert Sessions!

Identifying Memory Leak in Java Stack

Tuesday, 31 July 2012 13:17

Written by Prakash Palani

Print E-mail

I had to deal with a peculiar but an interesting issue on one of the PI Java stack, I have attempted to give detailed information on how I did go about analyzing the issue to identify the root cause.

Symptom : PI Java Stack is performing poor, there were no complaints around ABAP stack.

Analysis :

 

Step 1 : Look at the Memory and CPU utilization to understand the hardware capacity, from the task manager, it was evident that the SQLServer and Jstart (related to Javastack) services were utilizing about 50% of CPU which resulted in poor performance of the overall hardware.

Step 2 : Since jstart was consuming about 26 % of CPU, I turned my focus towards JVM behavior as that is the most influencing component of a java stack when it comes to performance issues.

Below will help you to understand how the GC has been reacting to this situation.

 

GC behavior from dev_server0 revealed that the Small and Full GCs are happening very frequently with specific amount (close to 900 MB) of data getting released from each of the GC runs. Since it looked like a memory leak to me, I had to use Memory Analyzer tool to take a close look at the JVM behavior in terms of memory allocation.

Step 3 : Used the memory analyzer tool understand whether there is really a leak in JVM memory area, as per the output from Memory Analyzer, it is understood that there is about 900 MB of memory leak in JVM which resulted in frequent Full and Small GCs.

In the problem suspect area, I could see a reference to the communication channel which is of type adapter type FILE which made it easy for me to analyze the issue further.

Step 4 : Login to Integration Directory and look for the communication channel that was noted in the problem suspect report.  From the ID, we could understand that the communication channel is referring to a network drive which contains exactly 900 MB of file in it.  That’s it, case closed, our developers took the issue forward from hereon.

 

Solution : Below are the few options to resolve the issue

  1. Have PI developers to find out the reason for having such a large file and correct it
  2. If it is really needed by the business to have such a large file as part of the interfaces, then you can either increase the JVM area (or) add additional server node. But make sure that you have enough physical memory to increase JVM or to additional server node.
{fcomment} {flike}
Share
Identifying Memory Leak in Java Stack