Although the java virtual machine (JVM) configures itself for optimal performance for most situations, it is advantageous to configure it for a specific application.
This section explores additional tuning options to improve the PingFederate service in your deployment. In all cases, test these options to ensure that they do benefit your deployment before enabling them in a production environment.
By default, the server HotSpot JVM selects the parallel collector on machines with multiple CPUs or cores. On machines with a single CPU, the serial collector is used.
On machines with eight or more hardware threads, the parallel collector uses a fraction of them as the number of garbage collector threads; the fraction is roughly 5/8. If the number of hardware threads drops below 8, the number of garbage collector threads matches the number of hardware threads.
The number of garbage collector threads can be overridden by the
JVM option, where n is the desired number of garbage collector
threads. It is generally recommended to leave
ParallelGCThreads as the default.
Specifically, setting to a value greater than the number of CPUs will not improve garbage
collection performance as the GC threads will all contend for CPU time, causing the operating
system to context switch between them. Setting to less than the number of CPUs can cause longer
than necessary pause times because not all available CPU resources will be utilized.
The parallel collection is generational, so minor (young generation only) and major (entire heap) collections do occur. Because PingFederate uses a much larger proportion of short to medium lived objects, consider applying a young generation bias to the JVM heap, which will improve performance because the parallel scavenge copying collector used for the young generation is fast. For more information, see Young generation bias.
Concurrent mark sweep collector
The concurrent mark sweep (CMS) collector suits applications that prefer shorter garbage collection pauses, can afford to share CPU resources with the garbage collector, have a large set of long-lived objects in the tenured (or old) generation, and run on machines with multiple CPUs.
The CMS collection is generational, so minor, young generation only, and major, entire heap, collections occur. Because PingFederate uses a much larger proportion of short to medium lived objects, the CMS collector is not generally the best fit. However, if you use a JVM heap greater than 6 GB on larger machines with eight or more CPUs, the CMS collector can provide shorter pause time than the parallel collector in major collections. Applying a young generation bias to the JVM heap will improve performance when using the CMS collector because it employs the same parallel scavenge copying collector for the young generation as the parallel collector.
Enable the CMS collector using the
-XX:+UseConcMarkSweepGC JVM option
Garbage first collector
The garbage first (G1) collector is best for machines with multiple CPUs and a JVM heap of 6 GB or more. The G1 collector is designed to achieve high throughput while meeting its pause times goal for garbage collection.
When using the G1 Collector, it is best to remove any sizing options specific to the young generation. The G1 collector self-tunes by adjusting the size and nature of the various heap regions to meet the pause time goal. By setting a fixed amount of memory to be used for young generation regions, it limits its self-tuning options.
When applicable, you can enable the G1 collector using the
For more information about each garbage collector, see Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide from Oracle.