Tuning WebLogic JRockit 8.1 JVM

Basic Tuning Tips and Techniques

When you install WebLogic JRockit 8.1 JVM, the VM includes a host 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 settings discussed in this section refer to standard and non-standard tuning options which are not thoroughly described in the present context. For more information on these options, refer to Command Line Options by Name

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.

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

Tuning for High Responsiveness

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

Select the Generational Concurrent garbage collector. Since this is the default garbage collector, you don't actually need to set anything for garbage collection.
Set the initial (-Xms) and maximum (-Xmx) heap sizes, as described in Setting the Heap Size. Since you're using a generational concurred 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.

Tuning 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. A parallel garbage collector doesn't use a nursery, so you don't need to set -Xns.
Set the largest initial (-Xms) and maximum (-Xmx) heap sizes that your machine can tolerate, as described in Setting the Heap Size.

Other Tuning Tips

This section describes two other practices you can employ to improve WebLogic JRockit JVM performance.

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 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 particulalry effective if you're running your application on a Linux machine.

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

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.

Analyzing and Improving Your Application

This section describes how you can improve application performance by uncovering "hotpaths," or bottlenecks in processing, and either working around those hotpaths or eliminating them completely.

Generally, analyzing and improving your application is a four-step process:

Find the hotpaths

Prioritize them

Fix the most important hotpaths

Repeat steps 1 through 3 until application performance is satisfactory

Step 1: Find the Hotpaths

Finding Hotpaths is a two-step process:

Find the Bottleneck Methods

As their name implies, bottleneck methods are those methods that require excessive time and processing resources to execute. These bottlenecks can greatly affect system performance and need to be identified. To find bottleneck methods, do the following:

Use the Intel VTune profiling tool with JRockit to analyze performance. VTune uses features on the processor to gather information about which code the processor is currently executing. This is done after a fixed number of either clock ticks (wall clock time) or after a fixed number of instructions retired (actual instructions executed in the processor). VTune then uses this data together with symbol information from Java code to present information about where the application spends most of its time.
Use the Java Virtual Machine Profiling Interface (JVMPI) by setting the option -Xjvmpi:allocs=off,monitors=off,entryexit=off.

JVMPI is a two-way function call interface between the Java virtual machine and an in-process profiler agent. On one hand, the VM notifies the profiler agent of various events, corresponding to, for example, heap allocation, thread start, and so on. Concurrently, the profiler agent issues controls and requests for more information through the JVMPI.
For a list of recommended -Xjvmpi settings, please refer to Table 4.1 in Profiling and Debugging with WebLogic JRockit

Cluster the Bottleneck Methods Together into Hotpaths

To cluster the bottleneck methods together into hotpaths, do the following:

Run your favorite profiler, such as OptimizeIt or JProbe.

Review the call-traces produced by it.

Combine these call-traces with the bottleneck methods discovered in Find the Bottleneck Methods, above. This combination of bottleneck methods and call-traces will identify your hotpaths.

Step2: Prioritize the Hotpaths

To prioritize the hotpaths, do the following:

Sum all of the time spent in each hotpath to compute a total hotpath time.

Remove all individual hotpaths that represent less than a prescribed percentage of the total hotpath time; for example, a good initial percentage might be 5%. This is the hotpath threshold.

Ignore any hotpath that falls below the hotpath threshold. Any hotpath time above the threshold should be optimized.

Step 3: Fix the Hotpath

You need to rely on your own judgement and knowledge of the application to fix hotpaths. Once you've identified and prioritized the hotpaths, look at each one and decide if the code is really needed or if you can make some simple changes, perhaps to the coding or to an algorithm, to avoid it or eliminate it as a hotpath. If you determine that you cannot remove the hotpath, what can you do to make it faster? Rewrite the code so it's more efficient?

Also, are you sure that anything you do will actually improve performance. Any optimization you attempt should at least double performance of the hotpath or your efforts might be wasted. For example, a performance increase of 5% or a hotpath that takes only 5% of the time is only going to improve performance .25%.

Step 4: Repeat Steps 1-3

Continue repeating the optimization process until you attain the desired system performance.