Skip to main content

JVM Monitoring landing page in Pega Predictive Diagnostic Cloud

Suggest edit Updated on January 19, 2022

Access garbage collection (GC) pauses and memory pools usage in real time on the JVM monitoring landing page. Pega Predictive Diagnostic Cloud (PDC) listens for JVM MBeans notifications to help you understand the run-time behavior of your application and to discover the reasons for critical performance glitches that are otherwise difficult to diagnose.

Note:

You can monitor JVM memory statistics with PDC for the following versions of Pega Platform™:

• Pega Platform version 8.6 and later
• For Pega Platform 8.5, version 8.5.1 and later
• For Pega Platform 8.4, version 8.4.3 and later

Note: To enable the feature for your application, you set the value of the aessetting/M3/disableMonitoring dynamic system setting to false, and then restart all the nodes in the system. For more information, see Configuring dynamic system settings. If you still cannot view statistics on the JVM Monitoring landing page, contact Pega Support.Note: The interpretation of the data that the JVM monitoring landing page presents requires a certain level of knowledge. It is most useful for advanced users with knowledge about memory management in Java.

By correlating memory usage and GC events with the corresponding Pega alerts and exceptions, PDC helps you identify the application features that cause the particular memory usage patterns that PDC observes. This monitoring ability helps you determine when an issue began to manifest and what actions caused the issue so that you can investigate the issue more quickly.

The JVM Monitoring landing page displays the following information:

  • The GC Analysis tab contains information about the application throughput and GC run information.
  • The JVM Memory Pools tab contains information about the usage of different kinds of memory.
  • The JVM Memory Allocation tab contains information about how quickly the JVMs allocate, promote, and reclaim memory.

GC Analysis tab

Inspect each node for major and minor GC runs and investigate throughput issues on each node using the GC analysis tab.

The Application Throughput chart shows the percentage of time that the node spends running your application. Low throughput might mean that your application spends too much time performing GC.

GC are operations that the virtual machine performs to clean the memory. There are two types of GC operations: minor GC and major GC.

Minor GC is a partial memory cleaning operation that every node performs periodically. Minor GC reclaims memory by reallocating, compacting, and removing objects in the young space. In a healthy system, most of GC is minor GC. A minor GC can be triggered, for example, during the evacuation pause, when the garbage-first garbage collector copies live objects from one or more regions to another.

Major GC cleans the whole memory of the node and requires significant time and resources. Fewer major GC runs in your application mean that your application is more efficient. A major GC can be triggered, for example, by a memory allocation failure, which occurs when a minor garbage collection fails to recover enough memory to allocate live objects from your application.

For more information on JVM memory management, see the Oracle Java online documentation.

The Major GC runs and the Minor GC runs charts show all GC processes that the node performed in a specified time window. For each major GC run and every minor GC run longer than the configured threshold, PDC creates a GC event that you can view by clicking the relevant chart entry or going to the Event Viewer. The default threshold for minor GC run is 200 miliseconds for Pega Platform version 8.6.3 and later, and 100ms for versions earlier than 8.6.3.

JVM Memory Pools tab

Analyze the availability of memory in each node across different memory spaces and investigate memory availability issues in your application by using the JVM Memory Pools tab.

The Heap chart shows the heap memory usage. Heap is a part of the memory that the system allocates to the JVM. All running threads of your application share the heap.

The chart presents how much of the heap the following regions take:

  • G1 Eden Space, which is the part of the young space where most new objects reside.
  • G1 Old Gen, which is the space to which garbage collectors move objects that survived enough GC runs. This space is also called the tenured space.
  • G1 Survivor Space, which is the section of the young space that garbage collectors use to organize and compact objects in the memory.

The following charts show the state of memory space for each of the space types. The memory can have the following states:

  • Committed: The amount of memory that the system guarantees as available to use by the JVM.
  • Used: The amount of committed memory that the JVM used.

The chart displays information about the following space types:

  • Old Gen, which contains objects that survived enough GC runs.
  • Young, which contains new and short-lived objects that have not yet survived enough GC runs for a garbage collector to move them to the old generation.
  • Metaspace, which contains the application metadata that the JVM requires to describe the classes and methods that the application uses. Metaspace is not part of the heap. Starting from Java 8, the metaspace replaces the PermGen space.
  • Code Cache, which has a fixed size. JVM cannot compile any additional code when the cache is full because the just-in-time (JIT) compiler cannot function without using the code cache. As a result, the performance of your application degrades.

JVM Memory Allocation tab

Analyze the allocation of memory in each node and investigate memory management issues in your application by using the JVM Memory Allocation tab.

The chart shown in the JVM Memory Allocation tab displays the amount of memory in different states across the specified time window. The chart displays the following memory states:

  • Allocated, which is the memory that the JVM allocated for use.
  • Promoted, which is the memory that GC promoted from the young generation to the old generation.
  • Reclaimed, which is the memory that GC reclaimed by evacuating objects from one memory region to another, and then compacting the memory.

The following figure shows different functionalities of the JVM Monitoring landing page in PDC:

"Exploring the JVM Monitoring landing page in PDC"
Monitoring the JVM memory management with PDC
  • Previous topic Elasticsearch landing page in Pega Predictive Diagnostic Cloud
  • Next topic Changes Summary landing page in Pega Predictive Diagnostic Cloud
Did you find this content helpful? YesNo

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us