WebLogic Server Performance and Tuning

Tuning Java Virtual Machines (JVMs)

The Java virtual machine (JVM) is a virtual "execution engine" instance that executes the bytecodes in Java class files on a microprocessor. How you tune your JVM affects the performance of WebLogic Server and your applications.

The following sections discuss JVM tuning options for WebLogic Server:

• JVM Tuning Considerations

• JVM Heap Size and Garbage Collection

• Specifying Heap Size Values

• Automatically Logging Low Memory Conditions

• Manually Requesting Garbage Collection

• Setting Java HotSpot VM Options

For links to related reading for JVM tuning, see Related Reading: Performance Tools and Information.

JVM Tuning Considerations

Table 2-1 presents general JVM tuning considerations.

JVM Heap Size and Garbage Collection

Garbage collection is the JVM's process of freeing up unused Java objects in the Java heap.The Java heap is where the objects of a Java program live. It is a repository for live objects, dead objects, and free memory. When an object can no longer be reached from any pointer in the running program, it is considered "garbage" and ready for collection.

The JVM heap size determines how often and how long the VM spends collecting garbage. An acceptable rate for garbage collection is application-specific and should be adjusted after analyzing the actual time and frequency of garbage collections. If you set a large heap size, full garbage collection is slower, but it occurs less frequently. If you set your heap size in accordance with your memory needs, full garbage collection is faster, but occurs more frequently.

The goal of tuning your heap size is to minimize the time that your JVM spends doing garbage collection while maximizing the number of clients that WebLogic Server can handle at a given time. To ensure maximum performance during benchmarking, you might set high heap size values to ensure that garbage collection does not occur during the entire run of the benchmark.

You might see the following Java error if you are running out of heap space:

java.lang.OutOfMemoryError <<no stack trace available>>
java.lang.OutOfMemoryError <<no stack trace available>>
Exception in thread "main"

To modify heap space values, see Specifying Heap Size Values.

To configure WebLogic Server to automatically detect when you are running out of heap space and to address low memory conditions in the server, see Automatically Logging Low Memory Conditions.

Generational Garbage Collection

The 1.3 Java HotSpot JVM uses a generational collector that provides significant increases in allocation speed and overall garbage collection efficiency. While naive garbage collection examines every reachable object in the heap, generational garbage collection considers the lifetime of an object to avoid extra collection work. The Hotspot JVM operates on the assumption that a majority of objects die young, and do not need to be considered for collection, which makes for efficient garbage collection.

With generational garbage collection, the Java heap is divided into two general areas: Young and Old. The Young generation area is subdivided further into Eden and two survivor spaces. Eden is the area where new objects are allocated. When garbage collection occurs, live objects in Eden are copied into the next survivor space. Objects are copied between survivor spaces in this way until they exceed a maximum heap size threshold, and then they are moved out of the Young area and into the Old. For information about specifying the size and ratios of the Young and Old generation areas, see Specifying Heap Size Values.

Many objects become garbage shortly after being allocated. These objects are said to have "infant mortality." The longer an object survives, the more garbage collection it goes through, and the slower garbage collection becomes. The rate at which your application creates and releases objects affects the heap size, which in turn determines how often garbage collection occurs. Therefore, attempt to cache objects for re-use, whenever possible, rather than creating new objects.

Knowing that a majority of objects die young allows you to tune for efficient garbage collection. When you manage memory in generations, you create memory pools to hold objects of different ages. Garbage collection can occur in each generation when it fills up. If you can arrange for most of your objects to survive less than one collection, garbage collection is very efficient. Poorly sized generations cause frequent garbage collection, which can affect performance.

For a good overview of generational garbage collection, see Tuning Garbage Collection with the 1.3.1 Java Virtual Machine

Using Verbose Garbage Collection to Determine Heap Size

Verbose garbage collection (verbosegc) enables you to measure exactly how much time and resources are put into garbage collection. To determine the most effective heap size, turn on verbose garbage collection and redirect the output to a log file for diagnostic purposes.

The following steps outline this procedure:

1. Monitor the performance of WebLogic Server under maximum load while running your application.

2. Use the -verbosegc option to turn on verbose garbage collection output for your JVM and redirect both the standard error and standard output to a log file.

   This places thread dump information in the proper context with WebLogic Server informational and error messages, and provides a more useful log for diagnostic purposes.

   For example, on Windows and Solaris, enter the following:

   % java -ms32m -mx200m -verbosegc -classpath $CLASSPATH
   -Dweblogic.Name=%SERVER_NAME% -Dbea.home="C:\bea"
   -Dweblogic.management.username=%WLS_USER%
   -Dweblogic.management.password=%WLS_PW%
   -Dweblogic.management.server=%ADMIN_URL%
   -Dweblogic.ProductionModeEnabled=%STARTMODE%
   -Djava.security.policy="%WL_HOME%\server\lib\weblogic.policy" weblogic.Server
   >> logfile.txt 2>&1

   where the logfile.txt 2>&1 command redirects both the standard error and standard output to a log file.

   On HPUX, use the following option to redirect stderr stdout to a single file:

   -Xverbosegc:file=/tmp/gc$$.out

   where $$ maps to the process ID (PID) of the Java process. Because the output includes timestamps for when garbage collection ran, you can infer how often garbage collection occurs.

3. Analyze the following data points:

   1. How often is garbage collection taking place? In the weblogic.log file, compare the time stamps around the garbage collection.

   2. How long is garbage collection taking? Full garbage collection should not take longer than 3 to 5 seconds.

   3. What is your average memory footprint? In other words, what does the heap settle back down to after each full garbage collection? If the heap always settles to 85 percent free, you might set the heap size smaller.

4. If you are using 1.3 Java HotSpot JVM, set the New generation heap sizes.

   See Specifying Heap Size Values and Table 2-2.

5. Make sure that the heap size is not larger than the available free RAM on your system.

   Use as large a heap size as possible without causing your system to "swap" pages to disk. The amount of free RAM on your system depends on your hardware configuration and the memory requirements of running processes on your machine. See your system administrator for help in determining the amount of free RAM on your system.

6. If you find that your system is spending too much time collecting garbage (your allocated "virtual" memory is more than your RAM can handle), lower your heap size.

   Typically, you should use 80 percent of the available RAM (not taken by the operating system or other processes) for your JVM.

7. If you find that you have a large amount of available free RAM remaining, run more instances of WebLogic Servers on your machine.

   Remember, the goal of tuning your heap size is to minimize the time that your JVM spends doing garbage collection while maximizing the number of clients that WebLogic Server can handle at a given time.

Specifying Heap Size Values

Java heap size values must be specified whenever you start WebLogic Server. This can be done either from the Java command line or by modifying the default values in the sample startup scripts that are provided with the WebLogic distribution for starting WebLogic Server.

For example, when starting WebLogic Server from a Java command line, the heap size values could be specified as follows:

$ java -XX:NewSize=128m -XX:MaxNewSize=128m -XX:SurvivorRatio=8  -Xms512m -Xmx512m
-Dweblogic.Name=%SERVER_NAME% -Dbea.home="C:\bea"
-Dweblogic.management.username=%WLS_USER%
-Dweblogic.management.password=%WLS_PW%
-Dweblogic.management.server=%ADMIN_URL%
-Dweblogic.ProductionModeEnabled=%STARTMODE%
-Djava.security.policy="%WL_HOME%\server\lib\weblogic.policy"
 weblogic.Server

The default size for these values is measured in bytes. Append the letter `k' or `K' to the value to indicate kilobytes, `m' or `M' to indicate megabytes, and `g' or `G' to indicate gigabytes. For more information on the heap size options, see Java Heap Size Options.

Using WebLogic Startup Scripts to Set Heap Size

Sample startup scripts are provided with the WebLogic Server distribution for starting the server and for setting the environment to build and run the server:

• startWLS.cmd and setEnv.cmd for Windows systems.

• startWLS.sh and setEnv.sh for UNIX systems.

These scripts are located in WL_HOME\server\bin, where WL_HOME is the location in which you installed WebLogic Server. The startup scripts set environment variables, such as the default memory arguments passed to Java (that is, heap size) and the location of the JDK, and then starts the JVM with WebLogic Server arguments.

Be aware that the WebLogic Server startup scripts specify default heap size parameters; therefore, you will need to modify them to fit your environment and applications. See "Starting an Administration Server Using a Script".

Java Heap Size Options

You achieve best performance by individually tuning each of your applications. However, configuring the JVM heap size options listed in Table 2-2 when starting WebLogic Server increases performance for most applications.

These options may differ depending on your architecture and operating system. See your vendor's documentation for platform-specific JVM tuning options.

Automatically Logging Low Memory Conditions

WebLogic Server enables you to automatically log low memory conditions observed by the server. WebLogic Server detects low memory by sampling the available free memory a set number of times during a time interval. At the end of each interval, an average of the free memory is recorded and compared to the average obtained at the next interval. If the average drops by a user-configured amount after any sample interval, the server logs a low memory warning message in the log file and sets the server health state to "warning."

If the average free memory ever drops below 5 percent of the initial free memory recorded immediately after you start the server, WebLogic Server logs a message to the log file.

You configure each aspect of the low memory detection process using the Administration Console:

1. Start the Administration Server if it is not already running.

2. Access the Administration Console for the domain.

3. Click the Servers node in the navigation tree to display the servers configured in your domain.

4. Click the name of the server instance that you want to configure. Note that you configure low memory detection on a per-server basis.

5. Select the Configuration —> Memory tab in the right pane.

6. Modify the following attributes as necessary to tune low memory detection for the selected server instance:

   • Low Memory GCThreshold: Enter a percentage value (0-99 percent) to represent the threshold after which WebLogic Server logs a low memory warning and changes the health state to "warning." By default, Memory GCThreshold is set to 5 percent. This means that by default the server logs a low memory warning after the average free memory reaches 5 percent of the initial free memory measured at the server's boot time.

   • Low Memory Granularity Level: Enter a percentage value (1-99 percent) to use for logging low memory conditions and changing the server health state to "warning." By default this value is set to 5 percent. This means that if the average free memory drops by 5 percent or more over two measured intervals, the server logs a low memory warning in the log file and changes the server health state to "warning."

   • Low Memory Sample Size: Enter the number of times the server samples free memory during a fixed time period. By default, the server samples free memory 10 times each interval to acquire the average free memory. Using a higher sample size can increase the accuracy of the reading.

   • Low Memory Time Interval: Enter the time, in seconds, that define the interval over which the server determines average free memory values. By default WebLogic Server obtains an average free memory value every 3600 seconds.

7. Click Apply to apply your changes.

8. Reboot the server to use the new low memory detection attributes.

Manually Requesting Garbage Collection

Make sure that full garbage collection is necessary before forcing it on a server. When you perform garbage collection, the JVM often examines every living object in the heap.

To use the Administration Console to request garbage collection on a specific server instance:

1. On the Administration Console, click the server instance node in the navigation tree for the server whose memory usage you want to view. A dialog box in the right pane shows the tabs associated with this instance.

2. Select the Monitoring —> Performance tab.

3. Check the Memory Usage graph for high usage. Note that the Memory Usage graph displays information only for a server that is currently running.

4. Click the Force garbage collection button to request garbage collection. The Force garbage collection button calls the JVM's System.gc() method to perform garbage collection. Note, however, that the JVM implementation itself decides whether or not the request actually triggers garbage collection.

Setting Java HotSpot VM Options

You can use standard java command-line options to improve the performance of your JVM. How you use these options depends on how your application is coded. Although command-line options are consistent across platforms, some platforms may have different defaults.

Test both your client and server JVMs to see which options perform better for your particular application. The Sun Microsystems Java HotSpot VM Options document provides information on the command-line options and environment variables that can affect the performance characteristics of the Java HotSpot Virtual Machine.

See Non-Standard Java Options for Windows and UNIX for more VM options that affect performance.

Standard Java Options for Windows and UNIX

In Windows, WebLogic Server invokes a particular version of the JVM through the java command and by specifying one of the options listed in Table 2-3.

In UNIX, the WebLogic Server invokes a particular version of the JVM through the java command and by specifying one of the options listed in Table 2-4.

The Sun Microsystems The Java HotSpot Client and Server Virtual Machines document discusses the two implementations of the Java virtual machine that are available for J2SE 1.3.

Non-Standard Java Options for Windows and UNIX

You can also use non-standard java options to improve performance. How you use these options depends on how your application is coded. Although command-line options are consistent across platforms, some platforms may have different defaults. Note that non-standard command-line options are subject to change in future releases.

Two examples of non-standard options for improving performance on the Hotspot VM on Windows are listed in Table 2-5.

For additional examples of non-standard Windows options, see Non-Standard Options (for Windows VMs).

Two examples of non-standard options for improving performance on the Hotspot VM on UNIX Solaris are listed in Table 2-6.

For more examples of non-standard options for Solaris, see Non-Standard Options (for Solaris VMs).