Tuning JRockit JVM
Have you ever seen strange pauses in your application that you haven't been able to explain? Have you seen one or all CPUs pegged on 100% utilization and all the others on 0% and still very few transactions in your system? If you answered yes to either of these two questions, your application might have been suffering from the effects of a poorly performing garbage collector. Some fairly simple tuning of the memory management system can improve performance dramatically for many applications.
To provide the optimal out-of-the-box experience, BEA JRockit JVM comes with default values that adapt automatically to the specific platform on which you are running BEA JRockit JVM. Tuning BEA JRockit JVM is accomplished by using non-standard—or
-X—command line options that you enter at startup.
-X options are exclusive to BEA JRockit JVM. Use them to set the behavior of BEA JRockit JVM to better suit the needs of your Java applications.
Note: If BEA JRockit behaves in some unexpected way, please consult the BEA JRockit Developers FAQ. If that doesn't solve your problem, please send an e-mail to email@example.com
System performance is greatly influenced by the size of the Java heap available to the JVM. This section describes the command line options you use to define the initial and maximum heap sizes and the size of any nursery that might be required by generational garbage collectors. It also includes key guidelines for help you determine the optimal heap size for your BEA JRockit implementation.
As a rule, you want to set the maximum heap size as high as possible, but not so high that it causes page faults for the application or for some other application on the same computer. Set the maximum heap size by using the
-Xmx command-line option; for example:
What these options configure is subject to change between releases.This depends on many things, for example your hardware platform, your operating system, and which BEA JRockit version you use. Some guidelines based upon these criteria are listed in Table 2-1.
On 32-bit platforms running with normal operating systems, processes are limited to less than 2 GB. Additionally, the heap must share this memory with all other memory used, including all JNI memory used by the application, generated code, the thread stacks, heap control, and other internal structures. Although you can run with as much and more than 1.8 GB of heap, it is seldom recommended. A normal initial heap would be 1.6GB.
Some Linux operating systems support larger process size by default (for example, Red Hat Enterprise Linux 4.0) and others can be started with the
64-bit platforms are not physically limited by the pointer size and the process size can grow to the supported limit. The limit is usually the amount of memory installed, but there can be further limitations imposed by the operating system version (different releases support different amounts, for example Windows 2003/Itanium only supports 16 GB, unless you're running the EE variant).
-Xns sets the size of the young generation (nursery) in generational garbage collectors. Optimally, you should try to make the nursery as large as possible while still keeping the garbage collection-pause times acceptably low. This is particularly important if you are creating a lot of temporary objects.
The following guidelines offer some hints on how best to size a heap to achieve optimal performance. Be aware that these guidelines are mainly valid for the -server (default) start-up option (see Setting the Default Garbage Collector).
-Xmxto the same value.
-Xmsto at least the approximate amount of live data. You can set
-Xmsto as much as twice the minimum amount of live data without disturbing automatic heap resizing. If
-Xmxisn't set, or is set too low, frequent garbage collections can slow startup until BEA JRockit has grown the heap.
-Xmxhigher than the amount of available physical memory in the system. Also, you must account for of the memory usage of other applications intended to run simultaneously with the JVM, as these will impact memory availability.
-Xmxat all. This will prevent BEA JRockit from growing the heap when there is too little memory in the system. Be aware that this will throw an OutOfMemoryError if object allocation fails with the current heap size and the heap cannot grow without causing paging.
-Xmxisn't set. BEA JRockit will not shrink the heap if more than half the heap is filled with live data. Thus, BEA JRockit might not always be able to shrink the heap if the amount of free memory is reduced after JRockit has been started; for example, when another application is started.
-Xmx)compared to the amount of live data can affect performance by forcing BEA JRockit to perform frequent garbage collections. If you anticipate a "tight" heap (that is, the amount of live objects is close to the size of the heap) and the application allocates many short lived objects, we suggest you use a generational garbage collector (
-Xgc:gencon) instead of a single-spaced garbage collector (
-Xcleartype defines when the memory space occupied by an object that has been garbage collected will be cleared. When clearing is actually performed is specified by the selected parameter, as described in Table 2-2.
If the thread stack size has not been set the default value depends on the platform on which BEA JRockit is running. Table 2-3 shows these defaults: