Caveat: These are recommendations only and it is recommended that customers refer to Oracle and other tuning documentation, and use a performance testing optimisation strategy to optimally configure IG according to deployment. Only an incremental optimisation strategy will determine the optimal configuration for a given deployment and user load.
Before tuning the JVM, be sure to understand and define performance targets, and select an appropriate JVM and garbage collector (GC).
As a proxy, IG is generally a low memory consumer, proxying request and response data between the client and server. Other factors to consider though in determining memory sizes are:
|Ensures the JVM uses server-optimised configuration, compilation and execution. This is the default with a 64-bit JVM.|
Configure the initial and maximum heap space:
Configure the initial and maximum YoungGen space:
Prevent String duplication and so conserve memory (java 8u20+), reducing GC needs. The threshold can be provided to specify the age after which a String becomes a candidate for deduplication.
Configure the number of transitions between survivor spaces before an object is moved to OldGen.
Because IG largely consumes YoungGen space, we can determine that anything that eventually would live in OldGen space could be moved there early to free up Eden space and reduce objects transitioning between survivor spaces. We could therefore set
Configure initial and maximum Metaspace size (from java 8). IG
IG makes low memory demands and specifically is mostly a consumer of
The specific settings described in this section may be considered when optimising JVM memory. See Oracle documentation for more information.
Garbage collection (GC)
Selecting the right garbage collector and tuning collection can reduce expensive "stop the world" pauses in collection. As IG is largely a consumer of YoungGen memory, there is a lot of scope for tuning to avoid expensive major collections (OldGen space consumption).
-XX:InitialHeapSize=5g -XX:MaxHeapSize=5g \ -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M \ -XX:MaxTenuringThreshold=1 \ -XX:+UseStringDeduplication \ -XX:+UseG1GC \ -XX:MaxGCPauseMillis=500\
Care should be taken in selecting an appropriate garbage collector, depending on your identified performance targets.
G1 is designed for multiprocessor environments with large available memory with the intent of good overall performance without the need to specify additional options. It is designed to reduce garbage collection through low-GC latency. It is largely self-tuning, with an adaptive optimisation algorithm, but there are a number of options to consider to suite the needs of the protected web application. See Oracle G1 collector documentations and tuning guide.
The Parallel GC aims to improve garbage collection by following a high-throughput strategy, but requires more full GCs. See Oracle Parallel GC documentation.
Generally, the recent addition of the G1 garbage collector is largely promoted by Oracle to satisfy most needs, but testing should be done to compare the results of G1 and the Parallel collector in typical business use cases.
- KB FAQ: IG Performance and Tuning
- KB BestPractice: Best practice for JVM Tuning (java 7)
- KB HowTo: How do I collect JVM data for troubleshooting IG/OpenIG (All versions)?
- KB HowTo: How do I enable Garbage Collector (GC) Logging for IG/OpenIG (All versions)?
- DZone: Choosing the Right GC
- Oracle Parallel Garbage Collector
- Oracle Garbage Collection Tuning Guide
- Oracle G1GC Tuning Guide
- JVM Tuning with G1GC by @marknienaber on medium.com (our very own Mark Nienaber (S))
- Improving G1 Out-of-the-box Performance by Stefan Joansson
- High Performance at Low Cost – Choose the Best JVM and the Best Garbage Collector for your Needs by Jonatan Kazmierczak
- A Step-by-step Guide to Java Garbage Collection Tuning by Rafal Kuc
- Reduce Long GC Pauses by gceasy.io