WebLogic Server Performance and Tuning
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.
Table 3-1 presents general JVM tuning considerations for WebLogic Server.
The Supported Configurations pages are frequently updated and contains the latest certification information on various platforms.
For WebLogic Server heap size tuning details, see JVM Heap Size and Garbage Collection.
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.
Deployments using different JVM versions for the client and server are supported in WebLogic Server. See the support page for Mixed Client/Server JVMs.
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" on Sun Microsystems' Web site.
Although this section focuses on Sun Microsystems' J2SE 1.4 JVM for the Windows, UNIX, and Linux platforms, the BEA WebLogic 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 WebLogic JRockit Documentation.
For more information on JVMs in general, see the Introduction to the JVM specification. For links to related reading for JVM tuning, see Related Reading: Performance Tools and Information.
When you create a domain, if you choose to customize the configuration, the Configuration Wizard presents a list of SDKs that WebLogic Server installed. From this list, you choose the JVM that you want to run your domain and the wizard configures the BEA start scripts based on your choice. After you create a domain, if you want to use a different JVM, you can modify the scripts as follows. For more information, see "Changing the JVM That Runs Servers" .
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.
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.
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.
The HotSpot VM's 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.
-verbosegcoption to turn on verbose garbage collection output for your JVM and redirect both the standard error and standard output to a log file.
% java -ms32m -mx200m -verbosegc -classpath $CLASSPATH
>> logfile.txt 2>&1
weblogic.logfile, compare the time stamps around the garbage collection.
Note: For information about setting the appropriate heap sizes for the BEA WebLogic JRockit JVM, see WebLogic JRockit Documentation.
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.
Note: For information about using the BEA WebLogic JRockit JVM
-Xgcreport option to print a comprehensive garbage collection report at program completion, see WebLogic JRockit Documentation.
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, as explained in Using WebLogic Startup Scripts to Set Heap Size.
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. For more information on the heap size options, see Java Heap Size Options.
setEnv.sh(UNIX and Windows. On Windows, these scripts support the MKS and Cygnus BASH UNIX shell emulators.)
If you used the Configuration Wizard to create your domain, the WebLogic startup scripts are located in the domain-name directory where you specified your domain. By default, this directory is BEA_HOME
\user_projects\domain\domain-name, where BEA_HOME is the directory that contains the product installation, and domain-name is the name of the domain directory defined by the selected configuration template. For more information about creating domains using the Configuration Wizard, see "Creating Domains Using the Configuration Wizard" .
The WebLogic 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 start the JVM with WebLogic Server arguments. Be aware that the WebLogic Server startup scripts specify default heap size parameters; therefore, you need to modify them to fit your environment and applications. For instructions on how to modifying the startup scripts to set the Java heap size options, see "Specifying Java Options for a WebLogic Server Instance" .
You achieve best performance by individually tuning each application. However, configuring the Java HotSpot VM heap size options listed in Table 3-2 when starting WebLogic Server increases performance for most applications.
Set this value to a multiple of 1024 that is greater than 1MB. As a general rule, set
Set the minimum size of the memory allocation pool. Set this value to a multiple of 1024 that is greater than 1MB. As a general rule, set minimum heap size (
Note: For information about setting the appropriate heap sizes for WebLogic's JRockit JVM, see WebLogic JRockit Documentation.
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."
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 GCThresholdis 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 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.
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.
For a brief discussion of additional "non-standard" VM options that can also affect performance, see Non-Standard HotSpot VM Options for Windows, Solaris, and Linux.
Note: For information about using the WebLogic JRockit JVM command-line options to improve performance, see WebLogic JRockit Documentation.
You can use standard
java options to improve performance on Windows, Solaris, and Linux platforms. These options are supported on the current Java the run-time environment and will also be supported in future releases of HotSpot. When specifying one of the standard options listed Table 3-3 through the
java command, WebLogic Server invokes a particular version of the JVM.
Sun Microsystems' Java Virtual Machine document provides a detailed discussion of the Client and Server implementations of the Java virtual machine for J2SE 1.4.
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.