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
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.
-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.
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
-Xms) and maximum (
-Xmx) heap sizes that your machine can tolerate, as described in Setting the Heap Size.
-Xgcreportto 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:memoryto 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.
-Xthinthreads. Thin threads are particulalry effective if you're running your application on a Linux machine.
-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.
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:
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.
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%.