eG Monitoring
 

Measures reported by JvmMemoryDetailsTest

This test monitors every memory type on the JVM and reports how efficiently the JVM utilizes the memory resources of each type.

Note:

  • For this test to report detailed diagnostics, the target Java application should use the JDK/JRE offered by one of the following vendors only: Oracle, Sun, OpenJDK , Azul Zing

  • If the target Java application is running on an AIX system using an IBM JRE/JDK, then, this test will not report detailed diagnostics. To enable the test to report DD, a MAT plugin is required. This plugin needs to be downloaded and extracted into the target AIX host. Once this is done, then the next time the eG agent runs this test, it takes the help of the plugin to read the usage statistics of object types from the heap dump file, and finally reports these metrics to the eG manager. To know how to install and configure the MAT plugin, refer to the Installing and Configuring the MAT Plugin section of the Monitoring Java Applications document.

  • This test can provide detailed diagnosis information for only those monitored Java applications that use JRE 1.6 or higher.

  • This test can run in an agent-based/agentless manner only, but detailed diagnostics will be available only if the test is run in an agent-based manner.

  • For an Azul Zing JVM, you can have this test report additional metrics on heap memory usage by enabling the MemoryMXBean interface. MemoryMXBean is an interface used by the Zing management system to access memory-related properties. The MemoryMXBean provides an overview of the memory system and the memory managers that control the size and use patterns of memory. To enable the MemoryMXBean interface, add the following JVM option in the start-up script of the target application.
    -XX:+UseZingMXBeans
    Also, to enable the test to report detailed diagnostics for a Zing JVM, make sure that the following JVM option is included in the start-up script of the target application:
    -XX:+ProfileLiveObjects

 The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Inital_memory Indicates the amount of memory initially allocated at startup. MB  
Currently_used_memory Indicates the amount of memory currently used. MB It includes the memory occupied by all objects, including both reachable and unreachable objects.

Ideally, the value of this measure should be low. A high value or a consistent increase in the value could indicate gradual erosion of memory resources. In such a situation, you can take the help of the detailed diagnosis of this measure (if enabled), to figure out which class is using up memory excessively.
Available_memory Indicates the amount of memory guaranteed to be available for use by the JVM. MB The amount of committed memory may change over time. The Java virtual machine may release memory to the system and committed memory could be less than the amount of memory initially allocated at startup. Committed will always be greater than or equal to used memory.
Free_memory Indicates the amount of memory currently available for use by the JVM. MB If an Azul Zing JVM is being monitored, then the value of this measure will change according to the value of the Memory_pool_size_type measure. If the Memory_pool_size_type measure is Fixed, then the value of this measure is the difference between the value of the Max_free_memory and Currently_used_memory measures. On the other hand, if the Memory_pool_size_type is Elastic, then the value of this measure will be the difference between the value of the Available_memory and Currently_used_memory measures.

For all other JVMs, this measure is the difference between the Max_free_memory and Currently_used_memory measures.

Ideally, the value of this measure should be high.

Note:

Sometimes, administrators may not want to cap/limit the maximum amount of memory that a JVM can use. In such cases, they may set the maximum memory to -1. If this is done, then it implies that the JVM can use any amount of memory. In this case therefore, the Maximum allocated memory will also report the value -1, but the Free memory measure will not be reported. This is the difference between Available memory and Used memory. Ideally, the value of this measure should be high.

Note:

Sometimes, administrators may not want to cap/limit the maximum amount of memory that a JVM can use. In such cases, they may set the maximum memory to -1. If this is done, then it implies that the JVM can use any amount of memory. In this case therefore, the Maximum allocated memory will also report the value -1, but the Free memory measure will not be reported.
Max_free_memory Indicates the maximum amount of memory allocated for the JVM. MB In the case of the Azul Zing JVM, this measure will be reported only for memory pools of type FIXED.
Pct_used_memory Indicates the percentage of used memory. Percent In the case of the Azul Zing JVM, this measure will be reported only for memory pools of type FIXED. The formula for computing the value of this measure for a FIXED memory type is as follows:

(Currently_used_memory / Available_memory )*100

For all other JVMs, the value of this measure is computed using the following formula:

(Currently_used_memory / Max_free_memory)*100

Ideally, the value of this measure should be low. A very high value of this measure could indicate excessive memory consumption by the JVM, which in turn, could warrant further investigation. In such a situation, you can take the help of the detailed diagnosis of this measure (if enabled), to figure out which class is using up memory excessively.
Heap_memory_exceeds Indicates whether/not the heap memory usage has exceeded the amount of memory initially reserved for this memory type.   The values that this measure can report and their corresponding numeric values are listed in the table below:

Measure Value Numeric Value
Yes 1
No 0

Typically, the value of this measure will be Yes for a memory pool of type ELASTIC - i.e., for those descriptors that report the value ELASTIC for the Memory_pool_size_type measure. For FIXED memory pools on the other hand, the value of this measure will generally be No.

Note:

By default, the test reports the Measure Values listed in the table above to indicate whether/not memory usage has exceeded allocation. In the graph of this measure however, the same is indicated using the numeric equivalents only.
Percent_heap_used_aftergc Indicates the percentage of heap memory used by the Zing JVM after garbage collection. Percent This measure is reported only for Azul Zing JVM, and only when the ‘MemoryMXBean’ interface is enabled.

This measure is only reported for the ‘Heap memory usage’ descriptor.

If garbage collection reclaims a large amount of memory from the Zing JVM, then the value of this measure will be low. On the other hand, if the garbage collector does not reclaim much memory, or if the Java application suddenly runs a memory-intensive process when GC is being performed, then the value of this measure will be very high.
App_object_heap_used Indicates the amount of heap memory that is used by application objects. MB This measure is reported only for Azul Zing JVM, and only when the ‘MemoryMXBean’ interface is enabled.

This measure is only reported for the ‘Heap memory usage’ descriptor.
App_object_heap_usable Indicates the amount of heap memory that was reserved for the usage of application objects. MB This measure is reported only for Azul Zing JVM, and only when the ‘MemoryMXBean’ interface is enabled.

This measure is only reported for the ‘Heap memory usage’ descriptor.
App_object_heap_percent Indicates what percentage of its reserved memory the application objects used. Percent This measure is reported only for Azul Zing JVM, and only when the ‘MemoryMXBean’ interface is enabled.

This measure is only reported for the ‘Heap memory usage’ descriptor.

The formula used for computing the value of this measure is as follows:

(App_object_heap_used/App_object_heap_usable)*100

A value close to 100% is a cause for concern as it indicates that space reserved for application objects is being eroded rapidly. If the space-drain is not controlled, it can cause application performance to deteriorate.
Memory_pool_size_type Indicates this memory pool's type in terms of size   This measure is reported only for Azul Zing JVM, and only when the ‘MemoryMXBean’ interface is enabled.

The values that this measure can report and their numeric values are listed in the table below:

Measure Value Numeric Value
Uninitialized 0
Fixed 1
Elastic 2

Each of these measure values are described below:

Measure Value Description
Uninitialized A memory pool may be labelled as Unitialized, if the memory region itself has not been reserved.
Fixed A Fixed pool has a fixed upper bound on its size, usually set when the memory for that memory pool is initially reserved.
Elastic An Elastic memory pool has the ability to use unused memory that other memory pools are not using. Likewise, when the memory pool no longer needs to use all of its memory, it can return that memory so that it can be used by other sibling memory pools.

Note:

By default, the test reports the Measure Values listed in the table above to indicate the memory pool size type. In the graph of this measure however, the same is indicated using the numeric equivalents only.