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:
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
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.
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:
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. |
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.
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.