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.
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.
Minimum amount of heap space initially allocated to the JVM
2g (or more)
Maximum amount of heap space available to the JVM
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
Explicit garbage collection should always be disabled.
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.
Enable parallel garbage collector that favors response time at the cost of memory and overall throughput
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.
- Download the security policy zip file: Java 6, Java 7
- Unzip the policy zip and copy local_policy.jar and US_export_policy.jar into the JRE's lib/security directory.