JVM Memory Pool Garbage Collections Test

While the JVM Garbage Collections test reports statistics indicating how well each collector on the JVM performs garbage collection, the measures reported by the JVM Memory Pool Garbage Collections test help assess the impact of the garbage collection activity on the availability and usage of memory in each memory pool of the JVM. Besides revealing the count of garbage collections per collector and the time taken by each collector to perform garbage collection on the individual memory pools, the test also compares the amount of memory used and available for use pre and post garbage collection in each of the memory pools. This way, the test enables administrators to guage the effectiveness of the garbage collection activity on the memory pools, and helps them accurately identify those memory pools where enough memory could not reclaimed or where the garbage collectors spent too much time.

Target of the test : An Oracle 9i Application Server

Agent deploying the test : An internal/remote agent

Outputs of the test : One set of results for every GarbageCollector:MemoryPool pair on the JVM of the server being monitored.

Configurable parameters for the test
Parameter	Description
Test period	How often should the test be executed.
Host	The host for which the test is to be configured.
Port	The port number at which the specified host listens to.
Measure Mode	This test allows you the option to collect the desired metrics using one of the following methodologies: By contacting the Java runtime (JRE) of the application via JMX Using GC logs To use JMX for metrics collections, set the Measure Mode to JMX. On the other hand, if you intend to use the GC log files for collecting the required metrics, set the measure mode to Log File. In this case, you would be required to enable GC logging. The procedure for this has been detailed in Enabling GC Logging page.
JMX Remote port	This parameter appears only if the Measure Mode is set to JMX. Here, specify the port at which the JMX listens for requests from remote hosts. Ensure that you specify the same port that you configured in the management.properties file in the <JAVA_HOME>\jre\lib\management folder used by the target application (see Enabling JMX Support for JRE page).
JNDIName	This parameter appears only if the Measure Mode is set to JMX. The JNDIName is a lookup name for connecting to the JMX connector. By default, this is jmxrmi. If you have registered the JMX connector in the RMI registry using a different lookup name, then you can change this default value to reflect the same.
User, Password, and Confirm password	These parameters appear only if the Measure Mode is set to JMX. If JMX requires authentication only (but no security), then ensure that the user and password parameters are configured with the credentials of a user with read-write access to JMX. To know how to create this user, refer to Configuring the eG Agent to Support JMX Authentication. Confirm the password by retyping it in the Confirm Password text box.
JREHome	This parameter will be available only if the Measure Mode is set to Log File. Specify the full path to the Java Runtime Environment (JRE) used by the target application.
LogFilename	This parameter will be available only if the Measure Mode is set to Log File. Specify the full path to the GC log file to be used for metrics collection.
Provider	This parameter appears only if the Measure Mode is set to JMX. This test uses a JMX Provider to access the MBean attributes of the target Java application and collect metrics. Specify the package name of this JMX Provider here. By default, this is set to com.sun.jmx.remote.protocol.

Measurements made by the test

Measurement

Description

Measurement Unit

Interpretation

Has garbage collection happened

Indicates whether garbage collection occurred on this memory pool in the last measurement period.

This measure reports the value Yes if garbage collection took place or No if it did not take place on the memory pool.

The numeric values that correspond to the measure values of Yes and No are listed below:

State	Value
Yes	1
No	0

Note:

By default, this measure reports the value Yes or No to indicate whether a GC occurred on a memory pool or not. The graph of this measure however, represents the same using the numeric equivalents – 0 or 1.

Collection count

Indicates the number of time in the last measurement pool garbage collection was started on this memory pool.

Number

Initial memory before GC

Indicates the initial amount of memory (in MB) that this memory pool requests from the operating system for memory management during startup, before GC process.

Comparing the value of these two measures for a memory pool will give you a fair idea of the effectiveness of the garbage collection activity.

If garbage collection reclaims a large amount of memory from the memory pool, then the Initial memory after GC will drop. On the other hand, if the garbage collector does not reclaim much memory from a memory pool, or if the Java application suddenly runs a memory-intensive process when GC is being performed, then the Initial memory after GC may be higher than the Initial memory before GC.

Initial memory after GC

Indicates the initial amount of memory (in MB) that this memory pool requests from the operating system for memory management during startup, after GC process

Max memory before GC

Indicates the maximum amount of memory that can be used for memory management by this memory pool, before GC process.

Comparing the value of these two measures for a memory pool will provide you with insights into the effectiveness of the garbage collection activity.

If garbage collection reclaims a large amount of memory from the memory pool, then the Max memory after GC will drop. On the other hand, if the garbage collector does not reclaim much memory from a memory pool, or if the Java application suddenly runs a memory-intensive process when GC is being performed, then the Max memory after GC value may exceed the Max memory before GC.

Max memory after GC

Indicates the maximum amount of memory (in MB) that can be used for memory management by this pool, after the GC process.

Committed memory before GC

Indicates the amount of memory that is guaranteed to be available for use by this memory pool, before the GC process.

Committed memory after GC

Indicates the amount of memory that is guaranteed to be available for use by this memory pool, after the GC process.

Used memory before GC

Indicates the amount of memory used by this memory pool before GC.

Comparing the value of these two measures for a memory pool will provide you with insights into the effectiveness of the garbage collection activity.

If garbage collection reclaims a large amount of memory from the memory pool, then the Used memory after GC may drop lower than the Used memory before GC. On the other hand, if the garbage collector does not reclaim much memory from a memory pool, or if the Java application suddenly runs a memory-intensive process when GC is being performed, then the Used memory after GC value may exceed the Used memory before GC.

Used memory after GC

Indicates the amount of memory used by this memory pool after GC.

Percentage memory collected

Indicates the percentage of memory collected from this pool by the GC activity.

Percent

A high value for this measure is indicative of a large amount of unused memory in the pool. A low value on the other hand indicates that the memory pool has been over-utilized. Compare the value of this measure across pools to identify the pools that have very little free memory. If too many pools appear to be running short of memory, it could indicate that the target application is consuming too much memory, which in the long run, can slow down the application significantly.

Collection duration

Indicates the time taken by this garbage collector for collecting unused memory from this pool.

Mins

Ideally, the value of this measure should be low. This is because, the garbage collection (GC) activity tends to suspend the operations of the application until such time that GC ends. Longer the GC time, longer it would take for the application to resume its functions. To minimize the impact of GC on application performance, it is best to ensure that GC activity does not take too long to complete.