This chapter describes how to configure JVM tuning options for WebLogic Server. 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 table presents general JVM tuning considerations for WebLogic Server.
Table 5-1 General JVM Tuning Considerations
| Tuning Factor | Information Reference |
|---|---|
|
JVM vendor and version |
Use only production JVMs on which WebLogic Server has been certified. This release of WebLogic Server supports only those JVMs that are Java SE 5.0-compliant. See "Supported Configurations" in What's New in Oracle WebLogic Server for links to the latest certification information on various platforms. |
|
Tuning heap size and garbage collection |
For WebLogic Server heap size tuning details, see Garbage Collection. |
|
Choosing a GC (garbage collection) scheme |
Depending on your application, there are a number of GC schemes available for managing your system memory, as described in Choosing a Garbage Collection Scheme. |
|
Mixed client/server JVMs |
Deployments using different JVM versions for the client and server are supported in WebLogic Server. See "Supported Configurations" in What's New in Oracle WebLogic Server for links to the latest supported mixed client/server JVMs. |
|
UNIX threading models |
Choices you make about Solaris threading models can have a large impact on the performance of your JVM on Solaris. You can choose from multiple threading models and different methods of synchronization within the model, but this varies from JVM to JVM. See "Performance Documentation For the Java Hotspot Virtual Machine: Threading" at |
Although this section focuses on the Java SE 5.0 JVM for the Windows, UNIX, and Linux platforms, the JRockit JVM was developed expressly for server-side applications and optimized for Intel architectures to ensure reliability, scalability, manageability, and flexibility for Java applications. For more information about the benefits of using JRockit on Windows and Linux platforms, see "Introduction to JRockit JDK" at http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/webdocs/index.html.
For more information on JVMs in general, see "Introduction to the JVM specification" at http://java.sun.com/docs/books/vmspec/2nd-edition/html/Introduction.doc.html#3057.
When you create a domain, if you choose to customize the configuration, the Configuration Wizard presents a list of JDKs that WebLogic Server installed. From this list, you choose the JVM that you want to run your domain and the wizard configures the Oracle start scripts based on your choice. After you create a domain, if you want to use a different JVM, see "Changing the JVM That Runs Servers" in Managing Server Startup and Shutdown for Oracle WebLogic Server.
Garbage collection is the VM's process of freeing up unused Java objects in the Java heap. The following sections provide information on tuning your VM's garbage collection:
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. A best practice is to tune the time spent doing garbage collection to within 5% of execution time.
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 detect automatically when you are running out of heap space and to address low memory conditions in the server, see Automatically Logging Low Memory Conditions and Specifying Heap Size Values.
Depending on which JVM you are using, you can choose from several garbage collection schemes to manage your system memory. For example, some garbage collection schemes are more appropriate for a given type of application. Once you have an understanding of the workload of the application and the different garbage collection algorithms utilized by the JVM, you can optimize the configuration of the garbage collection.
Refer to the following links for in-depth discussions of garbage collection options for your JVM:
For an overview of the garbage collection schemes available with Sun's HotSpot VM, see "Tuning Garbage Collection with the 5.0 Java Virtual Machine" at http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html.
For a comprehensive explanation of the collection schemes available, see "Improving Java Application Performance and Scalability by Reducing Garbage Collection Times and Sizing Memory Using JDK 1.4.1" at http://www.oracle.com/technetwork/java/index-jsp-138820.html.
For a discussion of the garbage collection schemes available with the JRockit JDK, see "Using the JRockit Memory Management System" at http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/webdocs/index.html.
For some pointers about garbage collection from an HP perspective, see "Performance tuning Java: Tuning steps" at http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,1604,00.html.
The verbose garbage collection option (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:
Monitor the performance of WebLogic Server under maximum load while running your application.
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:\Oracle\Middleware" -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.
Analyze the following data points:
How often is garbage collection taking place? In the weblogic.log file, compare the time stamps around the garbage collection.
How long is garbage collection taking? Full garbage collection should not take longer than 3 to 5 seconds.
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.
Review the New generation heap sizes (Sun) or Nursery size (Jrockit).
For Jrockit: see JRockit JVM Heap Size Options.
For Sun: see Java HotSpot VM Heap Size Options.
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.
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.
If you find that you have a large amount of available free RAM remaining, run more instances of WebLogic Server 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.
JVM vendors may provide other options to print comprehensive garbage collection reports. For example, you can use the JRockit JVM -Xgcreport option to print a comprehensive garbage collection report at program completion, see "Viewing Garbage Collection Behavior", at http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/webdocs/index.html.
System performance is greatly influenced by the size of the Java heap available to the JVM. This section describes the command line options you use to define the heap sizes values.You must specify Java heap size values each time you start an instance of 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.
The following section provides general guidelines for tuning VM heap sizes:
The heap sizes should be set to values such that the maximum amount of memory used by the VM does not exceed the amount of available physical RAM. If this value is exceeded, the OS starts paging and performance degrades significantly. The VM always uses more memory than the heap size. The memory required for internal VM functionality, native libraries outside of the VM, and permanent generation memory (for the Sun VM only: memory required to store classes and methods) is allocated in addition to the heap size settings.
When using a generational garbage collection scheme, the nursery size should not exceed more than half the total Java heap size. Typically, 25% to 40% of the heap size is adequate.
In production environments, set the minimum heap size and the maximum heap size to the same value to prevent wasting VM resources used to constantly grow and shrink the heap. This also applies to the New generation heap sizes (Sun) or Nursery size (Jrockit).
Although JRockit provides automatic heap resizing heuristics, they are not optimal for all applications. In most situations, best performance is achieved by tuning the VM for each application by adjusting the heaps size options shown in the following table.
Table 5-2 JRockit JVM Heap Size Options
| TASK | Option | Description |
|---|---|---|
|
Setting the Nursery |
-Xns |
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 your application is creating a lot of temporary objects. The maximum size of a nursery cannot exceed 95% of the maximum heap size. |
|
Setting initial and minimum heap size |
-Xms |
Oracle recommends setting the minimum heap size ( |
|
Setting maximum heap size |
-Xmx |
Setting a low maximum heap value compared to the amount of live data decrease performance by forcing frequent garbage collections. |
|
Setting garbage collection |
-Xgc: parallel |
|
|
Performs adaptive optimizations as early as possible in the Java application run. |
-XXaggressive:memory |
To do this, the bottleneck detector will run with a higher frequency from the start and then gradually lower its frequency. This options also tells JRockit to use the available memory aggressively. |
For example, when you start a WebLogic Server instance from a java command line, you could specify the JRockit VM heap size values as follows:
$ java -Xns10m -Xms512m -Xmx512m
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. The example above allocates 10 megabytes of memory to the Nursery heap sizes and 512 megabytes of memory to the minimum and maximum heap sizes for the WebLogic Server instance running in the JVM.
For detailed information about setting the appropriate heap sizes for WebLogic's JRockit JVM, see "Tuning the JRockit JVM" at http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/webdocs/index.html.
Oracle provides other command-line options to improve the performance of your JRockit VM. For detailed information, see "Command Line Reference " at http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/index.html.
You achieve best performance by individually tuning each application. However, configuring the Java HotSpot VM heap size options listed in the following table 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.
Table 5-3 Java Heap Size Options
| Task | Option | Comments |
|---|---|---|
|
Setting the New generation heap size |
-XX:NewSize |
As a general rule, set Be sure to increase the New generation as you increase the number of processors. Memory allocation can be parallel, but garbage collection is not parallel. |
|
Setting the maximum New generation heap size |
-XX:MaxNewSize |
Set the maximum size of the New Generation heap size. |
|
Setting New heap size ratios |
-XX:SurvivorRatio |
The New generation area is divided into three sub-areas: Eden, and two survivor spaces that are equal in size. Configure the ratio of the Eden/survivor space size. Try setting this value to 8, and then monitor your garbage collection. |
|
Setting initial heap size |
-Xms |
As a general rule, set initial heap size ( |
|
Setting maximum heap size |
-Xmx |
Set the maximum size of the heap. |
|
Setting Big Heaps and Intimate Shared Memory |
-XX:+UseISM -XX:+AggressiveHeap |
For example, when you start a WebLogic Server instance from a java command line, you could specify the HotSpot VM heap size values as follows:
$ java -XX:NewSize=128m -XX:MaxNewSize=128m -XX:SurvivorRatio=8 -Xms512m -Xmx512m
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. The example above allocates 128 megabytes of memory to the New generation and maximum New generation heap sizes, and 512 megabytes of memory to the minimum and maximum heap sizes for the WebLogic Server instance running in the JVM.
Oracle provides other standard and non-standard command-line options to improve the performance of your VM. How you use these options depends on how your application is coded.
Test both your client and server JVMs to see which options perform better for your particular application. See http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html for more information on the command-line options and environment variables that can affect the performance characteristics of the Java HotSpot Virtual Machine.
For additional examples of the HotSpot VM options, see:
"Standard Options for Windows (Win32) VMs" at http://download.oracle.com/javase/6/docs/technotes/tools/windows/java.html.
"Standard Options for Solaris VMs and Linux VMs" at http://download.oracle.com/javase/6/docs/technotes/tools/solaris/java.html.
The Java Virtual Machine document provides a detailed discussion of the Client and Server implementations of the Java virtual machine for Java SE 5.0 at http://download.oracle.com/javase/1.5.0/docs/guide/vm/index.html.
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." See "Log low memory conditions" in Oracle WebLogic Server Administration Console Help.
You may find it necessary to manually request full garbage collection from the Administration Console. When you do, remember that garbage collection is costly as the JVM often examines every living object in the heap. See "Manually request garbage collection" in Oracle WebLogic Server Administration Console Help.
You may find it necessary to display thread stacks while tuning your applications. See "Display thread stacks" in Oracle WebLogic Server Administration Console Help.
If you are running a high-stress application with heavily contended locks on a multiprocessor system, you can attempt to improve performance by using spinning. This option enables the ability to spin the lock for a short time before going to sleep.
Sun has changed the default lock spinning behavior in JDK 5.0 on the Windows IA32 platform. For the JDK 5.0 release, lock spinning is disabled by default. For this release, Oracle has explicitly enabled spinning in the environment scripts used to start WebLogic Server. To enable spinning, use the following VM option:
-XX:+UseSpinning
For better performance, you may need to increase the heap size for each Managed Server in your environment.
The following sections provide information on how to modify the java heap size for managed servers.
See "Configuring Remote Startup Arguments" in Node Manager Administrator's Guide for Oracle WebLogic Server.
If you use Node Manager to start the Managed Servers, you can specify a heap size as a Java argument on the Server Start tab for each Managed Server. See "Increasing the Java Heap size for a managed server" in the Oracle WebLogic Server Administration Console Help. Your heap size values are then persisted in the startup.properties file for the server.
You can update the startManagedWebLogic script with the required heap size in JAVA_OPTIONS. For example:
JAVA_OPTIONS="-Xms2g -Xmx2g" ${JAVA_OPTIONS}
See "Starting Managed Servers with a Startup Script" in Managing Server Startup and Shutdown for Oracle WebLogic Server.
You can pass JVM parameters when starting a managed server by invoking weblogic.Server class in a Java command. See "weblogic.Server Command-Line Reference" in the Command Reference for Oracle WebLogic Server.
Start scripts and the Administration Console (the startup.properties file) are common ways to configure memory arguments in managed servers. Often, they are set in multiple places and with different values. How do you determine which values are actually used by a running managed server?
A running managed server always uses the last set of memory arguments passed to the server during startup. You can verify this by looking through the log files. If you see the memory arguments listed multiple times, the last set in the output contains the values used by the server. If you used the Administration Console to set the values, see Using the Administration Console to Set Java Heap Size, the startup.properties file is always processed last, after all scripts. This provides a convenient method to tune memory size for an individual managed server when using common scripts. If you prefer not to include memory arguments that are not actually used in the environment, you will need to remove any extraneous memory arguments such as MEM_ARGS and JAVA_OPTONS from the scripts used to start a managed server.