Tuning WebLogic JRockit 8.1 JVM
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
Before you start WebLogic JRockit 8.1 JVM, you need to determine these two factors:
Once you've answered these questions, use the information provided below to tune WebLogic JRockit 8.1 JVM to achieve those goals.
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.
If you want the highest responsiveness from your application and guarantee minimal pause times, set the following options at startup:
-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.-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
.
If you want the highest possible performance WebLogic JRockit 8.1 JVM can provide, set these tuning options at startup:
Xns
.-Xms
) and maximum (-Xmx
) heap sizes that your machine can tolerate, as described in Setting the Heap Size.
This section describes two other practices you can employ to improve WebLogic JRockit JVM performance.
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.
-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.-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.If you are running with more than 100 threads and you want to improve system performance, try the following:
-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.
-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.
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:
Finding Hotpaths is a two-step process:
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:
-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
To cluster the bottleneck methods together into hotpaths, do the following:
To prioritize the hotpaths, do the following:
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%.
Continue repeating the optimization process until you attain the desired system performance.