Tuning WebLogic JRockit 8.1 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, WebLogic JRockit JVM comes with default values that adapt automatically to the specific platform on which you are running WebLogic JRockit JVM. Tuning WebLogic JRockit JVM is accomplished by using non-standard—or
-X—command line options that you enter at startup.
-X options are exclusive to WebLogic JRockit JVM. Use them to set the behavior of WebLogic JRockit JVM to better suit the needs of your Java applications.
Note: If WebLogic JRockit behaves in some unexpected way, please consult the WebLogic JRockit FAQ. If that doesn't solve your problem, please send an e-mail to firstname.lastname@example.org
System performance is greatly influenced by the size of the Java heap available to the JVM. This section describes the commandline options you can use to define the initial and maximum heap sizes and the size of any nursery that might be required by generational garbage collectors.
Generally, the default maximum heap size (
-Xmx) is 75% of the physical memory in the machine. However, when running WebLogic JRockit with a small initial heap (that is, less than about 32MB) the default maximum heap size will depend on the initial heap size. The default maximum heap size is
-Xms2 (in megabytes), up to 75% of the physical memory; for example, if
-Xms is 8MB, the default maximum heap size will be 8MB2, or 64MB; if
-Xms is 128MB, the default maximum heap size would be 1282, or 16384MB (16 GB). Be aware that, if the machine has less physical memory than the value of
-Xms2, the default maximum heap will be restricted to 75% of the physical memory.
Be aware that fragmentation can occur if you rely on the default maximum heap size (described above). Fragmentation can cause paging, which can degrade system performance. This is because WebLogic JRockit grows the heap aggressively when fragmentation occurs, potentially out-stripping the physical memory available. To avoid this situation, you should override the default and manually set
-Xmx to 75% of the available physical memory, up to 1.8 GB. Note that if you have other processes running that require large amounts of the physical memory, you will have to account for their expense when calculating how much memory is available.
Under certain circumstances, the JVM will not have enough memory to continue processing and throw an OutOfMemory error. This section describes some of the most common reason for those errors and suggests some ways to work around them.
Occasionally, WebLogic JRockit won't be able to find memory to allocate a Java object on the heap. If this is happening, enable
-Xverbose:gc. If the java heap appears full, this is probably the cause. We recommend that you increase the java heap size.
WebLogic JRockit allocates memory outside the java heap for internal structures used for thread handling, garbage collection, code generation and so on. If the java heap is taking too much of the total process memory, the JVM could run out of memory during such activities as code generation of a large method. It will then throw an OutOfMemory error. When this happens, we suggest that you decrease the java heap size. You might also enable
-Xverbose:codegen to detect the methods that take long time to generate. These are probably the methods consuming the most memory.
WebLogic JRockit might not be able to commit reserved memory needed by the system because the disk where the swap file resides is full, preventing the swap file from growing. This usually happens when the process size is not too large, but many other processes are running concurrently and the disk on which the swap file resides is almost full. We suggest that you release memory on the disk or shut down some of the other processes.
-Xns sets the size of the young generation (nursery) in generational concurrent and generational copying garbage collectors (these are the only collectors that use nurseries). 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.
gencopy) the default nursery size is 320 KB per CPU; for example, the default for a ten CPU system using
gencopywould be 3200 KB (3.2 MB).
gencon) the default nursery size is 10 MB per CPU; for example, the default for a ten CPU system using
genconwould be 100 MB.
When memory is completely allocated, WebLogic JRockit JVM cannot expand its heap size if swap space is not available. This often occurs when several applications are running simultaneously. If it happens, WebLogic JRockit will exit after throwing an OutOfMemory error. To remedy this condition, increase the available swap space by doing either or both of the following:
You might also avoid this problem by setting the command-line flags
-Xms to the same value. This will prevent WebLogic JRockit JVM from trying to expand the heap. If you attempt this workaround, be aware that the heap cannot expand to the size specified by
-Xmx if the necessary physical and virtual memory is not available.
-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-1.
-Xcleartype:localoption is available only if the
-Xallocationtypeis set to
allocparameter is currently not available on IA64 systems.
-Xallocationtype sets the type of thread allocation,
local as described in Table 2-2.
The maximum heap size is very small (less then 128 MB) or if the number of threads used by the application is very high (several hundred). This is because every thread-local area consumes a fixed amount of memory (approximately 2 kilobytes). If the number of threads is very high or the heap size very small when using thread-local allocation the potential waste of space could cause excess fragmentation of the heap. This leads to more frequent garbage collections and may cause the application to run out of memory prematurely.
In addition to setting the thread stack size, if the number of threads is high, you should use
-Xallocationtype:global, as suggested in Setting the Type of Thread Allocation to reduce heap fragmentation.
You should be aware that the memory requirements described in this section are suggestions based upon out-of-the-box testing. Your actual requirements might vary, particularly as they apply to the garbage collection method you select and the application you are running. Please refer to the tuning guidelines in Basic Tuning Tips and Techniques for instructions and tips on optimally setting your memory requirements.