Diagnostics Guide

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Tuning For Stable Performance

An incorrectly tuned JVM may perform well initially, but start showing lower performance or longer latencies over time or display severe performance variations. This section shows you how to tune your JVM for stable performance over time. The following topics are covered:

 


Measuring the Performance Variance

To be able to measure and analyze performance variance over time you need a long-running test that continuously reports the current performance. The test scenario should be as realistic as possible and cover as many use cases as possible.

When you have identified a variance in performance you can start monitoring the Oracle JRockit JVM to see if this variance correlates to events within the JVM, for example garbage collection, fragmentation or lock deflation. The tools in Oracle JRockit Mission Control will help you do this, as well as the verbose outputs that you can enable with the -Xverbose command line option.

Events to look for and the proper tools for finding these are listed in Table 14-1

Table 14-1 JVM Events
Event Type
What to Look For
Tools
Heap size change
The heap increases or decreases
-Xverbose:memdbg, JRA, Oracle JRockit Mission Control
Nursery size change
The nursery size increases or decreases
-Xverbose:memdbg, JRA, Oracle JRockit Mission Control
Garbage collector strategy change
A dynamic garbage collection mode changes the garbage collection strategy
-Xverbose:memdbg, JRA
Increased fragmentation
The amount of dark matter increases
JRA
Full compaction
Compaction of all heap parts at once
-Xverbose:memdbg, JRA

 


Tune the Heap Size

Heap size changes in runtime may cause performance variations. You can monitor the heap size in -Xverbose:memdbg outputs and in JRockit Mission Control tools. A JRA recording will also tell you if the heap size has changed during the recording.

For an even performance over time, you should set the initial heap size (-Xms) to the same value as the maximum heap size (-Xmx), for example:

java -Xms:1g -Xmx:1g myApplication

For more information on tuning the heap size, see Setting the Heap Size.

 


Manually Tune the Nursery Size

Nursery size changes in runtime may cause performance variations, but may also help keeping the performance high when the load changes. You can monitor the nursery size in -Xverbose:memdbg outputs and JRockit Mission Control tools. A JRA recording will also tell you if the nursery size has changed during the recording. If you find that performance variations in your application correlate to nursery size changes, you can set a static nursery size with the command line option -Xns:<size>, for example:

java -Xns:100m myApplication

For more information on tuning the nursery size, see Setting the Nursery and Keep Area Size.

Note: Overriding the dynamic nursery sizing heuristics may have a negative impact on the performance or cause performance variations in applications where the amount of live data varies during the run.

 


Tune the Garbage Collector

The dynamic garbage collection modes in the JRockit JVM select a garbage collection strategy based on runtime information. Changes in application behavior may cause the garbage collection strategy to change. If such changes happen often and cause a performance variations, you may want to select a static garbage collection strategy rather than a dynamic garbage collection mode. Set a static garbage collection strategy with the command line option -Xgc:<strategy>, for example:

java -Xgc:parallel myApplication

For more information on selecting a static garbage collection strategy, see Selecting a Static Garbage Collection Strategy.

 


Tune Compaction

The Oracle JRockit JVM uses the mark and sweep garbage collection model as described in The Mark and Sweep Model. This garbage collection model may cause the heap to become fragmented, which means that the free areas on the heap become many but small. The JVM performs partial compaction of the heap at each garbage collection to reduce the fragmentation. Sometimes the amount of compaction isn’t enough. This leads to increasing fragmentation, which in turn leads to more and more frequent garbage collections until the heap is so fragmented that a full compaction is performed. After the full compaction the garbage collection frequency goes down, but will gradually increase as the fragmentation increases again.

This behavior will cause the performance of the Java application to vary. As the garbage collection frequency increases the performance drops. During the full compaction you may experience a prolonged garbage collection pause, which pauses the entire Java application for a while. After this the performance is high again, but starts going down as the garbage collection frequency increases again.

You can monitor the compaction ratio and garbage collection frequency in -Xverbose:memdbg outputs, the Management Console and JRA recordings. A JRA recording will also show you how much dark matter (severe fragmentation) there is on the heap. If you find that the garbage collection keeps increasing until a full compaction is done, you need to increase the compaction ratio. For information on how to tune the compaction, see Tuning the Compaction of Memory.

You can also decrease the fragmentation on the heap by using a generational garbage collector. See Selecting and Tuning a Garbage Collector for information on different garbage collectors.


  Back to Top       Previous  Next