How to get a manual heap dump on application hanging (high CPU, high RAM or slow performance)

Products

• Clarity PPM On Premise
• Clarity PPM SaaS
• STARTER PACK-CLARITY PPM

Issue/Introduction

Our application is hanging (or has high CPU or high RAM or just slowness) but there is no OOM or outage, how can we determine what is going on? 

Environment

Release : All Supported Clarity Releases

Resolution

To further investigate reasons for slow performance, you can generate a manual JVM heap dump on the server. This has to happen at the precise time you experience the slowness.

The heap dump is a snapshot of what is going on the server so we will be having a better idea on what is running and what is taking resources.

 

Note: This manual heap dump is different from Heap dump on OOM (aka automatic heap dump) as the application is not in outage so the OOM heap dump may not be generated.

Steps:

1. Connect to the Clarity server having the slowness issue. 

2. Run the Java command below (you may have to run it from Java directory):

 

    jmap -dump:format=b,file=heapdump <process id>

 

3. This will create a dump from the moment of the hanging thread like a current snapshot.

• This can be opened and analyzed as a heap dump.
• Please make sure that you have enough disk space.

 

IMPORTANT: 

You  always have to provide the PID for the java.exe, not the Clarity Tanuki Service Wrapper (e.g. serviceappcmd.exe). Otherwise the command will fail. 

If the service you're trying to work with is an app or nsa, you can also usually check for which process the port is listening on in order to determine through the netstat command.  For example, if you have your app URL listening on port 1561 so that users visiting Clarity enter http://servername:1561 to connect, you can find the PID with this (Windows):

 

   D:\Clarity>netstat -ano | find /i ":1561"

      TCP    0.0.0.0:1561         0.0.0.0:0              LISTENING       7164

   D:\Clarity>

 

Additional Information

Note: To perform this action is a low impact, as the system is already slow. The only thing that could happen if the JVM is non responsive then the heap dump will not be taken until it gets to be responsive again so you may not have a correct snapshot of the situation