Tuning WebLogic JRockit with WebLogic Server on Linux

Tuning WebLogic JRockit JVM with WebLogic Server on Linux

This section describes how to tune BEA WebLogic JRockit JVM by using its command line options. It also provides tips that help Linux users to exploit the tuning options to achieve optimal performance by the VM.

This section includes information on the following subjects:

Basic JRockit Tuning

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. Depending upon the application you are running or the configuration of your machine, you might want to tune the JVM to take fullest advantage of its capabilities.

Tuning WebLogic JRockit JVM is accomplished by using non-standard—or -X—start-up options to change the default settings for elements such as heap size and thread stack size (for an example, see Starting BEA WebLogic JRockit). -X options are exclusive to WebLogic JRockit JVM.

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

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 defalt 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.8GB (which is the largest contigous address space the O/S will give a process).
Because IA64 macines have a larger address space, the 1.8GB 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.

Note: If you encounter OutOfMemory errors, you should increase the maximum heap size according to the preceding guidelines.

Default

If you are running -Xgc:gencopy, the default maximum heap size is the lesser of 75% of the physical memory and 400 MB; otherwise it is the lesser of 75% of physical memory and 1536 MB.

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.

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

Setting Thread Local Object Allocation

-Xallocationtype:<global|local>

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

Table 3-1 -Xallocationtype Parameters

Use this type...	When...
`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).
`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.

Use this type...

When...

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

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.

Default

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

Defining When a Memory will be Cleared

-Xcleartype:<gc|local|alloc>

-Xcleartype defines when the memory occupied by an object that has been garbage collected will be cleared. Specified parameters dictate when the memory will be cleared, as described in Table 3-2.

Table 3-2 -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

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

Note: The preferred options are local or alloc.

Default

If -Xcleartype is not set the default is alloc on IA32 systems and gc on IA64 systems.

Setting the Thread Stack Size

-Xss<size>[k|K]

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

In addition to setting the thread stack size, if the number of threads is high, you can reduce heap fragmentation by setting -Xallocationtype:global, as suggested in Setting the Thread Stack Size.

Default

If the thread stack size has not been set the default value depends on the threading system and the platform you are running on. When using thin threads the minimum thread stack size is 8 kilobytes and the default is 64 kilobytes. When using native threads the minimum thread stack size is 16 kilobytes. For Linux, the default thread stack size when using native threads is 128 kilobytes.

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

Tuning Tips and Techniques

When you install WebLogic JRockit 8.1 SDK, the VM includes a number of default start-up options that ensure a satisfactory out-of-the-box experience; however, often, these options might not provide your application with the optimal performance you should experience with WebLogic JRockit 8.1 JVM. Therefore, WebLogic JRockit 8.1 JVM comes with numerous alternative options and algorithms to suit different applications. This section describes some of these alternative options and some basic tuning techniques you can use at startup. It includes information on the following subjects:

Note: The tuning tips in this section create behaviors and performance that don't differ noticeably from those on other operating systems.

Determine What You Want to Tune For

Before you start WebLogic JRockit 8.1 JVM, you need to determine these two factors:

How much of your machine memory do you want WebLogic JRockit 8.1 JVM to use?
What do you want from WebLogic JRockit 8.1 JVM, the highest possible responsiveness or the highest possible performance?

Once you've answered these questions, use the information provided below to tune WebLogic JRockit 8.1 JVM to achieve those goals.

Set the Heap Size

Generally, 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 it to something less than the amount of memory in the machine. If you have multiple applications running on the computer at the same time the value could be much lower. It is recommend that you set the initial heap size (-Xms) the same size as the maximum heap size. Generally, you don't want the heap to exceed 75% of the available memory. However, some machines can have up to 4 GB of phsyical memory and when the heap exceeds about 1.8 GB, failure can occur. Therefore, you should limit the heap size to something less than 1.8 GB.

For specific guidelines for setting the heap size, please refer to Setting the Initial Heap Size and Setting the Maximum Heap Size.

Tune for High Responsiveness

If you want the highest responsiveness from your application and guarantee minimal pause times, set the following options at startup:

Accept the default Generational Concurrent garbage collector (-Xcg:gencon).
Set the initial (-Xms) and maximum (-Xmx) heap sizes, as described in Set the Heap Size. Since you're using a generational concurrent garbage collector, the heap size will not cause longer pauses.
Set the size of the nursery (-Xns).

If you are creating a lot of temporary objects you should have a large nursery. Larger nurseries usually result in slightly longer pauses, so, while you should try to make the nursery as large as possible, don't make it so large that pause times are unacceptable. You can see the nursery pause times in WebLogic JRockit JVM by starting the JVM with -Xgcpause.

Tune for High Performance

If you want the highest possible performance WebLogic JRockit 8.1 JVM can provide, set these tuning options at startup:

Select the Parallel garbage collector (-Xgc:parallel). A parallel garbage collector doesn't use a nursery, so you won't need to set -Xns.
Set the largest initial (-Xms) and maximum (-Xmx) heap sizes that your machine can tolerate, as described in Set the Heap Size.

Analyze Garbage Collection and Pause Times

Analyzing garbage collection and pause times together will give you a good idea of how well your application is performing while running with WebLogic JRockit JVM.

Use the option -Xgcreport to generate and end-of-run report that shows the garbage collection statistics. You can use this report to determine if you're using the most effective garbage collector for your application.
Use the option -Xverbose:memory (see Displaying Logging Information) to display the pause times for every garbage collection during a run. Note that this option is used mainly for debugging purposes and causes a lot of output to the console.

Modify Threading Options When Using a Large Number of Threads

If you are running with more than 100 threads and you want to improve system performance, try the following:

Switch to thin threads by using the option -Xthinthreads. Thin threads are particularly effective if you're running your application on a Linux machine (please read the Warning about thin threads, in Using a Thread System, before implementing them).
Turn off thread local allocation by using the option -Xallocationtype:global. Every thread-local area consumes a fixed amount of memory (approximately 2 kilobytes). If the number of threads is very high and you are 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. Using thread global allocation will result in less fragmentation, although actual allocation will be slower.

Check for Task and Open File Allowance

You should check the contents of /proc/sys/kernel/threads-max and /proc/sys/fs/file-max. The former tells you how many tasks the kernel will allow, which limits how many threads you can create at the Java level. The latter shows how many open files are allowed.

Optimizing WebLogic JRockit for Use with WebLogic Server

This section describes the tuning requirements for optimizing WebLogic JRockit on BEA WebLogoc Server.

Configuring JRockit for WebLogic Server

To use the WebLogic JRockit JVM instead of the Sun JVM, you need to increases the initial heap size to 64 MB (-Xms:64m)and the maximum heap size to at least 200 MB (-Xmx:200m). In addition, the following options are automatically set:

-Xnativethreads is set as the default thread system setting.
-Xallocationtype:local is set as the default thread allocation setting.

These settings are normally used for initial development. If you want to improve WebLogic JRockit performance, do any of the following:

Increase the heap initial and maximum size (-Xms and -Xmx).
Change the garbage collector to single space concurrent (-Xgc:singlecon) or parallel (-Xgc:parallel). Note that if you select parallel as your garbage collector, the -Xns setting will have no affect on processing (see Setting the Size of the Nursery).

Setting Options by Using the Node Manager

If you started the server or cluster of servers with the Node Manager and specified an absolute pathname to WebLogic JRockit JVM's top-level directory in the Java Home field on the Node Manager's Remote Start page, you can set any option from this page, too. Simply enter the option and any arguments in the Arguments field.

For more information on using the Node Manager, please refer to the Overview of Node Manager in Configuring and Managing WebLogic Server.

Monitoring WebLogic JRockit JVM from WebLogic Server

If you run WebLogic Server with WebLogic JRockit JVM, you can use the WebLogic Server Administration Console to view runtime data about the VM and the memory and processors on the computer hosting it. For instructions on monitoring WebLogic JRockit JVM from WebLogic Server, please see Monitoring WebLogic JRockit JVM from WebLogic Server in Using WebLogic JRockit 8.1 SDK.

Running JRockit with Thin Threads on WebLogic Server

Warning: Thin threads is experimental functionality in this version of JRockit, and is not recommended for general use. This feature is subject to change without notice.

The JRockit high performance thread system (Thin Threads, -Xthinthreads) and the native I/O system of WebLogic Server are incompatible as they both use asynchronous I/O. To avoid problems you must disable the native I/O system of WebLogic Server when running JRockit using thin threads. The native I/O is disabled automatically in WebLogic Server if JRockit is using thin threads, even if it is turned on in the corresponding WebLogic Server configuration file. In their respective default setups, WebLogic JRockit JVM does not use thin threads and WebLogic Server uses native I/O.

Switching to WebLogic JRockit JVM in WebLogic Server

When you switch to WebLogic JRockit JVM in WebLogic Server, any changes to the VM and start-up setting, should be handled by the WLS Configuration Wizard. Additionally, if any installation-wide scripts must be updated due to the switch, these will also be handled by the WLS Configuration Wizard. You will also need to restart any servers that are currently running.

For complete details on switching to WebLogic JRockit JVM from another JVM, please refer to Migrating to WebLogic JRockit with WebLogic Server on Linux.