After a connection is established, you can access the JConsole monitoring interface.

Monitoring clustered PingFederate engines

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

Monitoring CPU utilization

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.

Screenshot of the Overview tab showing a high level view of performance metrics.

Use the Overview tab to visualize and collect CPU usage data. When your PingFederate 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.

Monitoring memory utilization

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 in specific memory pools within the heap. This tab also provides information about the overall heap utilization profile.

Old Generation space

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, click Memory Pool > PS Old Gen or Memory Pool > G1 Old, depending on the relevant garbage collection. PingFederate services mostly short-lived transactions, like SSO, STS, and OAuth requests and most of the created memory objects are required only for a short period of time.

Although PingFederate makes use of some memory objects that are medium to long lived, such as session data for authentication session, adapter sessions, or single logout 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 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.

The most important space to monitor. It is easy to identify if the heap is sized andBecause 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 (0.728 seconds for three collections).

Windowshot of the Memory tab showing an Old Generation usage chart and how memory rises at a reasonably slow rate because the heap is sized adequately.

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.

Windowshot of the Memory tab showing an Old Generation usage chart where the amount of memory that becomes free with each garbage collection shrinks due to the rate objects are promoted from the Eden space.

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

Entire heap space

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.

Windowshot of the Memory tab showing the heap rising steadily with drops from minor collections until a PS MarkSweep collection occurs.

When the heap is undersized, full collections that are performed more frequently return less memory. In the following example, the frequency of 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.