The JConsole can be connected to multiple processes. To monitor several instances of the PingAccess server after a connection is established, go to Connection > New Connection and add the additional connection.

The Overview tab provides a dashboard of the following performance and resource-utilization charts:
  • Heap memory usage (cumulative memory that is used by all memory pools)
  • Live threads
  • CPU usage
  • Classes (number of classes that are loaded)

This tab provides a high-level view of the JVM's performance metrics.

A screen capture of the Java Monitoring Console showing CPU usage charts.

Use the Overview tab to visualize and collect CPU usage data. When your PingAccess deployment is subjected to its normal or expected load, the CPU utilization typically falls between 60% and 80%. If the system registers consistently at 80% or higher, additional CPU resources might be necessary to handle load spikes that occur during peak usage times.

The Overview tab shows only overall heap usage. To view additional details about memory utilization, click the Memory tab, which lets you analyze usage patterns usage in specific memory pools within the heap. This tab also provides information about the overall heap utilization profile.

Objects that survive a sufficient number of garbage-collection cycles are promoted to the Old Generation. To view the memory usage in the pool of such objects, go to Memory Pool > PS Old Gen or Memory Pool > G1 Old, depending on the relevant garbage collector. The PingAccess server services mostly short-lived transactions, such as single sign-on (SSO), Security Token Service (STS), and OAuth requests. Most of the created memory objects are required only for a short period of time.

Although the PingAccess server makes use of some memory objects that are medium- to long-lived, such as session data for authentication sessions, adapter sessions, or single logout (SLO) functionality, most of the objects that are promoted to the Old Generation are likely to become garbage that requires cleaning up. If the younger generation, or Eden space, is not sized appropriately, objects are moved to and retained in the Old Generation before they are collected as garbage. If size limitations prevent the Old Generation from accumulating future garbage as well as longer-lived objects, then garbage-collection cycles occur more frequently.

The Old Generation space is the most important space to monitor. It is easy to identify if the heap is sized and proportioned appropriately for a specific load, based on its usage pattern. The following examples involve two Old Generation usage charts. In both examples, the same user load executes the same workflow. The size of the heap represents the only difference.

Because the heap is sized adequately in the first example, memory in the Old Generation rises at a reasonably slow rate. Garbage collection frees around 60% to 75% of the space, and room is available to accommodate the future garbage of newly created objects that are moved from the Eden space, as well as the longer-term objects that remain in use. Although the space is 1 GB in size, the average full (PS MarkSweep or G1 Old Generation) collection time is approximately only 240 milliseconds, or 0.728 seconds for three collections.

A screen capture of the Memory Pool PS Old Gen chart measured in gigabytes.

When a heap is sized inadequately, the Old Generation runs out of space.

In the following example, the amount of memory that becomes free with each garbage collection shrinks, due to the rate at which objects are promoted from the Eden space.

A screen capture of the Memory Pool PS Old Gen chart measured in megabytes.

184 PS MarkSweep (full) collections require garbage collections more frequently, totaling 60 seconds, or an average of 326 milliseconds per collection.

If the heap is sized appropriately for the load that the system must handle, it fills up and is followed by an appreciable drop in usage as a full garbage collection occurs, such as a PS MarkSweep collection triggered by the Old Generation filling up. In this example, the heap rises steadily, with drops from minor collections until a PS MarkSweep collection occurs and collects approximately 70% of the heap.

A screen capture of the heap memory usage chart measured in gigabytes.

When the heap is undersized, full collections that are performed more frequently return less memory. In the following example, the frequency of Java Management Extensions (JMX) data that the JConsole retrieves does not keep pace with the frequency of full collections. As a result, only a fraction of them occur.

A screen capture of the Memory Pool PS Old Gen chart measured in megabytes.

Regardless of whether the heap is adequately sized or undersized, the usage pattern is nearly identical with the Eden space. This similarity can be due to the sampling frequency of the data-colle