Tuning WebLogic JRockit with WebLogic Server on Linux
|
 |
 |
|
 |
 |
Running WebLogic JRockit JVM with WebLogic Server on Linux
This section describes how to start up and configure the BEA WebLogic JRockit JVM. It also provides some background on selecting and running both a thread system and a memory management system (called a "garbage collector"). This section includes information the following subjects:
- Starting BEA WebLogic JRockit
- Configuring WebLogic JRockit JVM by Using Command Line Options
- Using a Thread System
- Using a Memory Management System (Garbage Collection)
Starting BEA WebLogic JRockit
You can start BEA WebLogic JRockit either from the command line or from the WebLogic Server's Node Manager. This section describes both methods.
Starting BEA WebLogic JRockit JVM from the Command Line
Before starting WebLogic JRockit JVM, ensure that you have the following directory set in your PATH environment variable:
<jrockit-install-directory>/bin
(where <jrockit-install-directory> is the folder where you installed WebLogic JRockit, such as c:/bea/jrockit81_141_02/.)
To start the JVM, at the command line enter on of the following:
java
and any tuning or configuration and tuning options you want to use; for example, you might start WebLogic JRockit JVM with the following command string:
java -verbose -Xgc:gencopy -Xms:64 -Xmx:512 -Xns:64 -Xnopt myClass
Here, the standard configuration parameter -Verbose requests verbose output from the system and the non-standard option -Xgc:gencopy sets the generational copying memory management system (the "garbage collector"). The tuning parameters -Xms:64 and -Xmx:512 set the minimum (-Xms) and maximum (-Xmx) heap sizes, while the tuning parameter -Xns:64 set the size of the young generation (the "nursery"; required for generational collectors). myClass identifies the class that contains the main() method and is required whenever you start WebLogic JRockit.
All of the options in this example—along with others—are described in Configuring WebLogic JRockit JVM by Using Command Line Options, below, or in Tuning WebLogic JRockit JVM with WebLogic Server on Linux.
Note: You can also start JRockit from the command by specifying a fully-qualified path to the file; for example, enter:
<jrockit-install-directory>/bin/java
Starting BEA WebLogic JRockit from the Node Manager
You can also start WebLogic JRockit JVM from the WLS Node Manager. To do this, access the Node Manager and go to the Remote Start Page. In the Java Home field, enter the fully-qualifying path, as suggested in the example above. For more information on using the Node Manager, please see Overview of Node Manager in Configuring and Managing WebLogic Server.
Configuring WebLogic JRockit JVM by Using Command Line Options
Configure WebLogic JRockit JVM by using a number of standard and non-standard command line options that you enter at startup. These options work with WebLogic JRockit on all supported operating systems; none are specific to Linux.
If you start WebLogic JRockit JVM from the Remote Start page of the WLS Node Manager, simply enter the options, with the appropriate arguments, in the Arguments field on the Remote Start page. For more information on using the Node Manager,please see Overview of Node Manager in Configuring and Managing WebLogic Server. This section describes:
Standard Command Line Options
Standard command line configuration options work the same regardless of the JVM; in other words, these options work the same whether you are running WebLogic JRockit JVM, Sun Microsystem's HotSpot JVM, or any other third-party JVM.
Presenting General Information Options
The following standard command line options set general information about WebLogic JRockit JVM:
-classpath <directories and zips/jars separated by:>Tells the VM where to look for classes and resources. Alternately, you can use the option
-cpto represent-classpath; for example:-D<name>[=<value>]
Setting Logging Options
The following options determine if the system will provide messages to the operator and what the form and content of those messages should be.
-version-showversion-verbose[:<components separated by,>]Tells JRockit to display verbose output. This option is used mainly for debugging purposes and causes a lot of output to the console. Supported components are
memory,loadandcodegen. If no component is given, JRockit will display verbose information on everything.-help-X
Non-standard Command Line Options
The non-standard, or -X, command line options are options that are exclusive to WebLogic JRockit JVM that change the behavior of WebLogic JRockit JVM to better suit the needs of different Java applications. Non-standard options are used extensively with thread system and memory management. These options normally won't work on other JVMs (conversely, the non-standard options used by other JVMs normally won't work with WebLogic JRockit).
Warning: Since these options are non-standard, they are subject to change at any time.
Setting Behavioral Options
The following non-standard options define general WebLogic JRockit JVM behavior:
Displaying Logging Information
-Xverbose
-Xverbose causes WebLogic JRockit to print to the screen specific information about the system. The information displayed depends upon the parameter specified with the option; for example, specifying the parameter cpuinfo displays information about your CPU and indicates whether or not the JVM can determine if hyper threading is enabled. The valid parameters for -Xverbose are: .
codegen —The names of each method that is being compiled.cpuinfo—Any interesting information about your CPUs.load —The names of each loaded class.memory; gc —Information about the memory management system, including:- Start time of collection (seconds since JVM start)
- End time of collection (seconds since JVM start)
- Memory used by objects before collection (KB)
- Memory used by objects after collection (KB)
- Size of heap after collection (KB)
- Total time of collection (seconds or milliseconds)
- Total pause time during collection (milliseconds)
- The information displayed by -Xverbose:memory or -Xverbose:gc will vary depending upon the type of garbage collector you are using.
opt —Information about all methods that get optimized.
For descriptions and examples of the information these parameters display, please refer to Table 3-1 in Starting and Configuring WebLogic JRockit JVM (found in Using WebLogic JRockit 8.1 SDK).
Using a Thread System
The thread system allows WebLogic JRockit JVM to take optimal advantage of the underlying operating system. WebLogic JRockit JVM supports two types of thread systems:
- Native Threads, which maps Java threads directly to the operating system threads, taking advantage of the operating system's thread scheduling and load balancing policies. Native Threads is the default thread system for WebLogic JRockit JVM.
- Thin Threads, wherein multiple Java threads are run on a singe operating system thread. This allows WebLogic JRockit JVM to optimize thread scheduling, thread switching, and thread synchronization, while using less memory.
For more information on native and thin threads and on how to select a thread system that best meets your needs, please refer to Choosing the Thread System in Using WebLogic JRockit 8.1 SDK.
To start a thread system, include one of the options listed in Table 2-1 when you start WebLogic JRockit JVM:
Using a Memory Management System (Garbage Collection)
WebLogic JRockit JVM manages memory by employing four different garbage collectors. These collectors work during runtime to clear the memory heap of expired objects, or "garbage." The four garbage collectors are:
- Generational Copy, which divides the memory into two areas called "generations." Instead of allocating objects in one single space and garbage collecting that whole space when it gets full, most of the objects are allocated in the "young generation," called the nursery.
- Single-Spaced Concurrent, one of two types of concurrent collectors, which does its work in parallel with ordinary processing; that is, it does not stop all Java threads to do the complete garbage collection. This is designed to support garbage collection without disruption and to improve multiprocessor garbage collection performance.
- Generational Concurrent is the second type of concurrent collector WebLogic JRockit employs. Although very similar to a single-spaced concurrent collector, a generational concurrent garbage collector does its actual object allocation in a "nursery," reducing the need to do collection of the entire heap so often.
- Parallel garbage collection, which stops all Java threads and uses all CPUs to perform a complete garbage collection of the entire heap.
For information and tips on selecting a garbage collector, please refer to Choosing a Garbage Collection Method in Using WebLogic JRockit 8.1 SDK.
Starting a Garbage Collector
To start a garbage collector, simply include at the command line the -Xgc option and the type of collector you want to use, as shown in Table 2-2.
When started, JRockit will run with the specified garbage collector.
Default
If the garbage collector has not been set and the maximum heap size (set by using -Xmx or by using the default, as described in Setting the Maximum Heap Size) is less than 128 MB, the default garbage collector is generational copying (-Xgc:gencopy); otherwise the default is parallel (-Xgc:parallel).
Printing a Comprehensive Report
-Xgcreport
-Xgcreport causes WebLogic JRockit JVM to print a comprehensive garbage collection report at program completion. The option -Xgcpause causes the VM to print a line each time Java threads are stopped for garbage collection. Combining the two is a very good way of examining the memory behavior of your application.
