How do I set up jvm_monitor to monitor heap memory?
Article ID: 45552
Updated On:
Products
Issue/Introduction
Question:
How do I set up jvm_monitor to monitor heap memory?
Answer:
The first thing to do is to assign the probe a port for JMX to listen on.
This is accomplished by opening the probe configuration in Raw Configure mode.
Then going to the startup options and add the following to the java_opts parameter
-Dcom.sun.management.jmxremote.port=51000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
In this example I have chosen port 51000, but any unused port is acceptable.
The next step is to deploy and configure the jvm_monitor probe. The jvm_monitor probe is capable of remote monitoring so it does not need to be deployed to the same robot that the probe you're monitoring is deployed to, however it will not function over a tunnel connection as it does need direct IP communication.
Once jvm_monitor is deployed, open the configuration GUI for it
Right click on Default Group and click New Resource.
Enter a Resource Name. The value that you enter in this field will be the source that this QOS is identified by in Performance Reports Designer (PRD). You might have a nomenclature you wish to follow, particularly if you are monitoring several probes.
Enter the hostname or IP address of the robot that runs the probe and enter the port number that you configured JMX to listen on.
Click Test to verify connectivity and click OK to save the profile.
After this, you'll want to expand the profile you created in order to add the checkpoints.
The first checkpoint I like to add is the heap usage
Expand java.lang -> Memory -> name -> HeapMemoryUsage and put a check in the "used" checkpoint.
The heap is comprised of three individual memory spaces, which give much more granular information about how Java is managing memory.
Expand java.lang -> MemoryPool
Expand PS Eden Space -> Usage and put a check in the "used" checkpoint.
Expand PS Old Gen -> Usage and put a check in the "used" checkpoint.
Expand PS Survivor Space -> Usage and put a check in the "used" checkpoint.
Click OK to save this configuration.
There are numerous additional checkpoints that can be added in as well, however these four will give a very good view of how Java is managing the memory that you have allocated it.
At this point you will want to allow the monitoring to run for a time. If the purpose of monitoring is to try and track down a suspected memory leak, then you'll want to let this monitor until the symptoms occur and perhaps even beyond that point. Once you have gathered enough datapoints, you can move to the Performance Reports Designer portlet and begin graphing the memory usage.
In general, when observing heap usage, you'll see a very characteristic saw tooth pattern; memory usage will rise over some time and drop very suddenly. This is the classic pattern of heap space being used and cleaned up by Garbage Collection and is a textbook example of healthy memory management. In reality, you might not see this pattern all the time. You might see periods of fluctuation followed by drops, but usually you'll always see some drops. If memory usage consistently stays close to maximum, then it could be an indication that you need additional memory, or it could be a sign of a memory leak. This is where Eden Space, Old Gen and Survivor Space come into play.
As Java is performing Garbage Collection, it will make determinations about whether objects are still needed or not. All object begin life in Eden Space and most objects end life there as well through the process of Garbage Collection. It's very common to see your Eden Space graph somewhat mirroring your heap space graph. If Java makes a determination that an object is needed for a longer period of time, it moves to Survivor Space. Survivor Space is not handled by minor garbage collections and the objects persist longer. Finally, if the objects are determined to be needed much longer, they are moved to Old Gen.
During these promotions to Survivor Space and Old Gen, you would see a rise in usage of those memory spaces. However, you should see those stabilize fairly quickly over time with very little overall growth. You will see up and down fluctuation as other Garbage Collection duties run, but unrestrained growth often indicates a problem. It means that memory management has determined that objects can't be flagged for reclamation. Over time, the Old Gen space has too many objects stored in it and your Old Gen space consumes all of the allocated heap space and the probe runs out of memory for new objects to be created in Eden Space.
If this occurs, it is usually necessary to contact support for investigation.
Environment
Component:
Feedback
