...
| Code Block |
|---|
# Print computed flags after startup -XX:+PrintCommandLineFlags # Memory Configuration -server -d64 # switch to 64bit server mode -Xms4096m # Set initial heap sizes -Xmx4096m # Set max heap size -XX:NewSize=2048m # Set initial new size to 1/2 the initial heap -XX:MaxNewSize=2048m # Specify the max new size, generally allow the JVM to use up to 1/2 the max heap -XX:MaxGCPauseMillis=250 # GC Pauses up to 250ms aren't bad, have ergonomics try and keep pauses below this level -XX:+UseConcMarkSweepGC # Force CMS for the collector -XX:+CMSIncrementalMode # Use incremental mode since minor CPU overhead is better than potential pauses. Useful if system has 1 or 2 processors. -XX:+UseAdaptiveGCBoundary # Lets the JVM adjust the young/old ratio #-XX:+UseParNewGC # ParNewGC is the default when using the CMS collector # Enable perm-gen class unloading (needed with UseConcMarkSweepGC) -XX:+CMSClassUnloadingEnabled # Set a large enough perm gen. You can track how much you are using with jvisualvm, jconsole, or looking at the output in gc.log -XX:PermSize=250m -XX:MaxPermSize=400m |
Java 8 has deprecated option '-XX:+CMSIncrementalMode' and based on my reading it was created for single or dual proc systems to relinquish the processor periodically (see http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#icms). With modern multi-CPU and multi-core architectures it doesn't seem to me the option is needed. However I have not seen any load testing that verifies that assumption (anyone willing to check it out?) so I have currently left the option in as recommended but I strongly suspect it should be removed.
JVM Logging Options
The JVM can be configured to log details about garbage collection and classloading that may be helpful when analyzing portal performance. It is also recommended for production systems. It can be analyzed using https://github.com/chewiebug/GCViewer
...