The general tuning guidelines for java VM.
Here are some general tunning guideline to help you categorize the kinds of java tunning you will perform:
1. Be aware of ergonomics settings
The -server: server compiler
The -XX:+useParallelGC: parallel garbage collector
The -Xms: initial heap size is 1/64th of the machine’s physical memory
The -Xmx: maximum heap size is 1/4th of the machine’s physical memory ( up to 1 GB max)
2. Heap sizing
The mazimum heap size of a java application is limited by the factors:
The process daata model (32-bit or 64-bit) on the system.
The amount of physical memory available on the system.
The size of the java heap for a paricular application can never exceed or even reach the maximum
virtual address space of the process data model.
3. Garbage collector policy
The -XX:+UseParallelGC: parallel garbage collector
The -XX:+UseConcMarkSweepGC: concurrent garbage collector (CMS)
The -XX:+UseSerialGC: serial garbage collector ( for smaller applications and systems)
4. Other tunning parameters
The -XX:+UseLargePages: large memory pages.
The -XX:LargePageSizeInBytes:
Examples:
1. Tunning for throughput
Here is an example of specific command line tuning for a server application
running on system with 4 GB of memory and capable of running 32 threads simultaneously
(CPU’s and cores or contexts).
java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
2. Try the parallel old generation collector
Similar to example 1 we here want to test the impact of the parallel old generation collector.
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC
3. Try 256 MB pages
This tuning example is specific to those Solaris-based systems that would support the huge page size of 256 MB.
java -Xmx2506m -Xms2506m -Xmn1536m -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
-XX:+UseParallelOldGC -XX:LargePageSizeInBytes=256m
4. Try -XX:+AggressiveOpts
This tuning example is similar to Example 2, but adds the AggressiveOpts option.
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
-XX:+UseParallelOldGC -XX:+AggressiveOpts
5. Try Biased Locking
This tuning example is builds on Example 4, and adds the Biased Locking option.
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
-XX:+UseParallelOldGC -XX:+AggressiveOpts -XX:+UseBiasedLocking
6.Tuning for low pause times and high throughput
This tuning example similar to Example 2, but uses the concurrent garbage collector
(instead of the parallel throughput collector).
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC
-XX:+UseParNewGC -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31
7. Try AggressiveOpts for low pause times and high
This tuning example is builds on Example 6, and adds the AggressiveOpts option.
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC
-XX:+UseParNewGC -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31
-XX:+AggressiveOpts
A good start to understand JVM, Heap, Perm Gen and GC collector
JDK 6 Performance Features and Update
GC Collector:
Serial Collector (-XX:+UseSerialGC)
• Throughput Collectors
> Parallel Scavanging Collector for Young Gen
? -XX:+UseParallelGC
> Parallel Compacting Collector for Old Gen
? -XX:+UseParallelOldGC (on by default with ParallelGC in JDK 6)
• Concurrent Collector
> Concurrent Mark-Sweep (CMS) Collector
? -XX:+UseConcMarkSweepGC
> Concurrent (Old Gen) and Parallel (Young Gen) Collectors
? -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
• The new G1 Collector as of Java SE 6 Update 14 (-XX:+UseG1GC)
Sample JVM Parameters:
Performance Goals and Exhibits
A) High Throughput (e.g. batch jobs, long transactions)
B) Low Pause and High Throughput (e.g. portal app)
• JDK 6
A) -server -Xms2048m -Xmx2048m -Xmn1024m -XX:+AggressiveOpts
-XX:+UseParallelGC -XX:ParallelGCThreads=16
B) -server -Xms2048m -Xmx2048m -Xmn1024m -XX:+AggressiveOpts
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:ParallelGCThreads=16
• JDK 5
A) -server -Xms2048m -Xmx2048m -Xmn1024m -XX:+AggressiveOpts
-XX:+UseParallelGC -XX:ParallelGCThreads=16 -XX:+UseParallelOldGC
-XX:+UseBiasedLocking
B) -server -Xms2048m -Xmx2048m -Xmn1024m -XX:+AggressiveOpts
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:ParallelGCThreads=16
-XX:+UseBiasedLocking
Rule of Thumb on Best selection of
> Garbage Collector (Make sure to override GCThreads)
> Heap Size (-Xms == 1/64 Max Memory or Max Heap and
-Xmx == ¼ Max Memory or Max Heap)
> Runtime Compiler (-server vs -client)
• Desired Goals (This is a hint, not a guarantee)
> Maximum Pause Time (-XX:MaxGCPauseMillis=)
> Application Throughput (-XX:GCTimeRatio= where
Application time = 1 / (1 + n))
Do check out 1.5 paper as it comes with sample parameters for high thoughput and low latency application
Java 1.5 Tuning White Paper
If you are using 1.6, check out the difference and improvement from 1.6 paper, take note that 1.5 parameters still apply to 1.6.
Java SE 6 Performance White Paper
A very practical and easy to understandable slide which walking you through the Sun HotSpot GC tuning tip and take-away parameters.
HotSpot JVM Tuning
Wondering whether java thread stack space (Xss) and perm gen (MaxPermSize) part of heap space. The answer is NO. That is why when u saw actually linux memory consumption is bigger than your “-Xmx” settings.
Using -Xss to adjust Java default thread stack size to save memory and prevent StackOverflowError
One working jvm parameters with JBoss server:
JAVA_OPTS=”-server -Xms3072m -Xmx3072m -Xmn2048m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -XX:ParallelGCThreads=8 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31 -XX:+AggressiveOpts -XX:+PrintHeapAtGC -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime -Xloggc:/opt/jbos/server/default/log/jvmgc.log”
Advanced JVM Tuning for Low Pause
The standard Java Virtual Machine (JVM) is configured to optimize for throughput. But some systems are more interested in low pause/reduced latency and GC (garbage collection) might be one source of pausing.
(you can read an interesting article about what latency means to your business)
I have found a post on GigaSpaces forum providing some possible JVM configurations to optimize on latency:
-Xms2g -Xmx2g -Xmn150m
-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode
-XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=10
-XX:CMSIncrementalDutyCycle=50 -XX:ParallelGCThreads=8
-XX:+UseParNewGC -XX:MaxGCPauseMillis=2000
-XX:GCTimeRatio=10 -XX:+DisableExplicitGC
Please note that -XX:+UseConcMarkSweepGC has the heaviest impact on performance – decrease of 40%.
The following set of parameters shows 20% better performance than with -XX:+UseConcMarkSweepGC while the pause size still is below 100msec in embedded test with payload 10KB and 100 threads:
-Xms2g -Xmx2g -Xmn150m
-XX:GCTimeRatio=2 -XX:ParallelGCThreads=8
-XX:+UseParNewGC -XX:MaxGCPauseMillis=2000
-XX:+DisableExplicitGC
While I’m pretty sure that most of the applications do no need such an advanced VM configuration, it is interesting to see what strategies are employed when low latency is needed.
Option Details
-XX:+UseConcMarkSweepGC Sets the garbage collector policy to the concurrent (low pause time) garbage collector (also known as CMS)
-XX:+CMSIncrementalMode Enables the incremental mode. (works only with -XX:+UseConcMarkSweepGC)
-XX:+CMSIncrementalPacing Enables automatic adjustment of the incremental mode duty cycle based on statistics collected while the JVM is running
-XX:CMSIncrementalDutyCycleMin The percentage (0-100) which is the lower bound on the duty cycle when CMSIncrementalPacing is enabled
-XX:CMSIncrementalDutyCycle The percentage (0-100) of time between minor collections that the concurrent collector is allowed to run. If CMSIncrementalPacing is enabled, then this is just the initial value.
-XX:ParallelGCThreads Sets the number of garbage collector threads
-XX:+UseParNewGC Enables multi threaded young generation collection.
-XX:MaxGCPauseMillis A hint to the throughput collector that it’s desirable that the maximum pause time is lowed than the given value. (n.b. it looks like this value can also be used with the CMS garbage collector)
-XX:GCTimeRatio A hint to the virtual machine that it’s desirable that not more than 1 / (1 + GCTimeRation) of the application execution time be spent in the collector
-XX:+DisableExplicitGC Disables explicit garbage collection calls (System.gc())
There is no need to learn all these flags by heart as you can find them covered in various documents:
Custom settings was:
-Xms768m
-Xmx768m
-XX:NewSize=128m
-XX:MaxNewSize=128m
-XX:+UseParNewGC
-XX:ParallelGCThreads=8
-XX:MaxTenuringThreshold=1
-XX:SurvivorRatio=8
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:CMSInitiatingOccupancyFraction=65
-XX:+CMSScavengeBeforeRemark
-XX:+UseCMSInitiatingOccupancyOnly
-XX:MaxPermSize=250m
-XX:ReservedCodeCacheSize=64m
Recent Comments