Tuning WebLogic JRockit 8.1 JVM

Tuning WebLogic 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, 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.

This section describes how to use these options to tune WebLogic JRockit. It includes information on the following subjects:

• Setting Heap Size Parameters
• Defining When a Memory Space will be Cleared
• Setting the Type of Thread Allocation
• Setting the Thread Stack Size
• Memory Requirements and Garbage Collection Types

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 [e-mail]

 

---

Setting Heap Size Parameters

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.

Setting the Initial Heap Size

-Xms<size>

-Xms sets the initial size of the heap. For this, we recommend that you set it to the same size as the maximum heap size; for example:

-java -Xgc:gencon -Xmx:64m -Xms:64m myClass

Default

The default initial heap size is 16 MB if maximum -Xmx is less than 128 MB; otherwise it is 25% of available physical memory up to, but not exceeding, 64 MB.

Setting the Maximum Heap Size

-Xmx:<size>

-Xmx sets the maximum size of the heap. Use the following guidelines to determine this value:

• On IA32 the maximum possible heap size is about 1.8 GB (which is the largest contiguous address space the O/S will give a process). This is helpful because, while the O/S limitation for the maximum memory size per a process is 2 GB on IA-32 platform, you cannot fully use 2 GB for JVM heap. This is because other purpose spaces are included in that 2 GB; for example the memory used by WebLogic JRockit internally, native library space, and so on. Be aware that 1.8 GB is just a suggested heap size; you have to tune it according to your application.
• Because IA64 machines have a larger address space, the 1.8 GB limit does not apply.
• Typically, for any platform you don't want to use a larger maximum heap size setting than 75% of the available physical memory. This is because you need to leave some memory space available for internal usage in the JVM.

Default

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 -Xms² (in megabytes), up to 75% of the physical memory; for example, if -Xms is 8MB, the default maximum heap size will be 8MB², or 64MB; if -Xms is 128MB, the default maximum heap size would be 128², or 16384MB (16 GB). Be aware that, if the machine has less physical memory than the value of -Xms², the default maximum heap will be restricted to 75% of the physical memory.

Note: These figures are subject to any platform limitations that determine how much contiguous memory a process can allocate.

Setting -Xmx to Avoid Fragmentation

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.

Encountering OutOfMemory Errors

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.

Can't Find Memory to Allocate an Object on the Heap

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.

OOM Errors When Compiling Large Methods

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.

Can't Commit Reserved 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.

Setting the Size of the Nursery

-Xns:<size>

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

Note: To display pause times, include the option-Xgcpause when you start WebLogic JRockit JVM.

The maximum size of a nursery may not exceed 25% of the total heap size if you're using gencon and 15% of the total heap size if you're using gencopy.

Default

If the nursery size (-Xns) has not been set the default size depends on the type of garbage collector and the number of CPUs:

• For the generational copying garbage collector (-Xgc:gencopy) the default nursery size is 320 KB per CPU; for example, the default for a ten CPU system using gencopy would be 3200 KB (3.2 MB).
• For the generational concurrent garbage collector (-Xgc:gencon) the default nursery size is 10 MB per CPU; for example, the default for a ten CPU system using gencon would be 100 MB.

Working Around Limits to Expanding Heap Size

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:

• Allocate more of your disk for virtual memory.
• Limit the number of applications that can run simultaneously.

You might also avoid this problem by setting the command-line flags -Xmx and -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.

 

---

Defining When a Memory Space will be Cleared

-Xcleartype:<gc|local|alloc>

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

Table 2-1 -Xcleartype Parameters

Use this parameter...	To clear space...
gc	During the garbage collection
local This option is available only if the -Xallocationtype is set to local.	When a thread-local area is allocated
alloc This option is currently not available on IA64 systems. Additionally, it is the preferred option if the objects allocated are very large (1 to 2 kilobytes).	When that space is allocated for a new object

The preferable options are either alloc or local.

Note these additional conditions:

• The -Xcleartype:local option is available only if the -Xallocationtype is set to local.
• The alloc parameter is currently not available on IA64 systems.

Default

If the clear type is not set the default is alloc on IA32 systems and gc on IA64 systems.

Note: The option alloc is currently not available on IA64 systems.

 

---

Setting the Type of Thread Allocation

-Xallocationtype:<global|local>

-Xallocationtype sets the type of thread allocation, global or local as described in Table 2-2.

Table 2-2 -Xallocationtype Parameters

Use this type...	When...
Global	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.
local	The maximum heap size is large (more then 128 MB) or if the number of threads used by the application is low (less than several hundred).

Default

If the allocation type (-Xallocationtype) is not set, the default is global for the generational copying (gencopy) garbage collector and local for all others (singlecon, gencon, and parallel).

 

---

Setting the Thread Stack Size

-Xss<size>[k|K][m|M]

-Xss<size>[k|K] [m|M] sets the thread stack size in kilobytes.

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.

Minimum Thread Size

Minimum thread size is determined as follows:

• Thin threads—the minimum thread stack size is 8 kilobytes and the default is 64 kilobytes.
• Native threads—the minimum thread stack size is 16 kilobytes.

If -Xss is set below the minimum value, thread stack size will default to the minimum value automatically.

Default

If the thread stack size has not been set the default value depends on the threading system and the platform on which WebLogic JRockit is running:

32-bit Default

On either Windows or Linux IA32 machines, the default thread stack size values for native threads are:

• Win32: 64 kB
• Linux32: 128 kB

64-bit Default

On either Windows or Linux IA64 machines, the default thread stack size values for native threads are:

• Win64: 320 kB
• Linux64: 1 MB

 

---

Memory Requirements and Garbage Collection Types

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.