Tuning WebLogic JRockit 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.
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.
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.
-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.
gencopy) the default nursery size is 320 KB per CPU; for example, the default for a ten CPU system using
gencopywould be 3200 KB (3.2 GB).
gencon) the default nursery size is 10 MB per CPU; for example, the default for a ten CPU system using
genconwould be 100 MB.
-Xallocationtype sets the type of thread allocation,
local as described in Table 3-1.
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.
-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.
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.
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.
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:
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.
-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.
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
-Xgc:parallel). A parallel garbage collector doesn't use a nursery, so you won't need to set -
-Xms) and maximum (
-Xmx) heap sizes that your machine can tolerate, as described in Set 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: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.
-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).
-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.
You should check the contents of
/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.
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:
-Xnativethreadsis set as the default thread system setting.
-Xallocationtype:localis set as the default thread allocation setting.
-Xgc:singlecon) or parallel (
-Xgc:parallel). Note that if you select parallel as your garbage collector, the
-Xnssetting will have no affect on processing (see Setting the Size of the Nursery).
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.
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.
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.
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.