The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

IdPProdJVMTuning

Owned by Former user (Deleted)
Last updated: Mar 23, 2016 by astuart4@ed.ac.ukVersion comment

Tuning your Java Virtual Machine

Properly tuning your JVM can make a significant difference in performance. The following suggestions have proven to offer a good balance between performance, throughput, response time, and stability in most environments. As always, before performing any tuning you should understand the effect of each operation and take into account all the aspects of your environment.

Oracle HotSpot Virtual Machine

The Oracle Java Virtual Machine, HotSpot, offers a number of performance options. Before proceeding you should be familiar with the JVM, if you are not, you should stop reading and go review the document for the JVM.

Memory Management

All of the Java Shibboleth components attempt to keep as much frequently used information (like SAML metadata) cached in memory. While this caching is memory sensitive, in that if the JVM is running out of memory these caches allow the JVM to collect memory from them, providing a couple gigabytes of memory to the JVM is recommended. Additionally, the Identity Provider depends on a significant number of classes which can cause the permanent generation to be exhausted.

The following JVM options effect memory management within the Java VM.

JVM Option

Recommended Value

Description

-Xms<size>

256m

Minimum amount of heap space initially allocated to the JVM

-Xmx<size>

2g (or more)

Maximum amount of heap space available to the JVM

-XX:MaxPermSize=<size>

128m

Maximum amount of memory allocated for permanent generation

Memory requirements for Shib IdP V2

As of September 17, 2015, the Shibboleth Project recommends at least 1500M of heap for deployments consuming large (>25M) metadata files. See, for example, the topic on preparing Apache Tomcat for Shibboleth IdP V2.

Garbage Collection

Explicit garbage collection should always be disabled.

JVM Option

Description

-XX:+DisableExplicitGC

Disables explicit garbage collection (the System.gc method).

Additionally almost all servers come with multiple CPU cores. As such a parallel garbage collector should be used and the ParallelOldGC is recommended.

JVM Option

Description

-XX:+UseParallelGC

Enable parallel garbage collector that favors response time at the cost of memory and overall throughput

-XX:+UseParallelOldGC

Enable parallel garbage collection that favors memory and overall throughput at the cost of response time

Install Java Unlimited Strength Security Policy

The JVM, by default, contains a security policy that prohibits the use of cryptography keys above a certain size (2048bit for DSA/RSA keys). Some sites have begun using larger key sizes in their CAs and certificates so we recommend people add the Unlimited Strength Security Policy to their JVM. This allows for larger key sized. Note, if you don't install the Bouncy Castle JCE you won't actually get "unlimited" key sizes as the standard JCE only supports a max size of 4096bit DSA/RSA keys.

  1. Download the security policy zip file: Java 6, Java 7
  2. Unzip the policy zip and copy local_policy.jar and US_export_policy.jar into the JRE's lib/security directory.

Further Reading