Tuning Java Virtual Machines (JVMs)

 

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

This document discusses the following JVM tuning topics:

• JVM Tuning Considerations

• About JVM Heap Size

• About Generational Garbage Collection

• Forcing Garbage Collection

• Setting Java HotSpot VM Options

• Setting Non-Standard Java Command Line Options

For links to related reading, see Java Virtual Machine (JVM) Information.

 

---

JVM Tuning Considerations

Table 2-1 presents general JVM tuning considerations.

Table 2-1 General JVM Tuning Considerations

Issue	Description
JVM vendor and version	Use only production JVMs on which WebLogic Server has been certified. WebLogic Server 6.x supports only those JVMs that are Java 1.3-compliant. The Platform Support page is frequently updated and contains the latest certification information on various platforms.
Tuning heap size and garbage collection	For tuning details, see About JVM Heap Size. For a good overview of garbage collection, see Tuning Garbage Collection with the 1.3.1 Java Virtual Machine
Generational garbage collection	See About Generational Garbage Collection.
Mixed client/server JVMs	Deployments using different JVM versions for the client and server are supported in WebLogic Server. For information about support for mixed client/server JVMs.
UNIX threading models	There are two UNIX threading models: green threads and native threads. To get the best performance and scalability with WebLogic Server, choose a JVM that uses native threads. For Solaris, see "Threading Models and Solaris Versions Supported" on the JavaSoft web site.
Just-in-Time (JIT) JVMs	Use a JIT compiler when you run WebLogic Server. Most JVMs use a JIT compiler, including those from Sun Microsystems and Symantec. See your JVM supplier documentation for more information. Note: Sun's JVM 1.3.x, JIT options are no longer valid. See Java Virtual Machine (JVM) Information.

 

---

About JVM Heap Size

Garbage collection is the VM process of de-allocating 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, the object is garbage.

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 you spend doing garbage collection while maximizing the number of clients that you 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.

 

---

About Generational Garbage Collection

The 1.3 Java HotSpot JVM uses generational garbage collection. While naive garbage collection examines every living object in the heap, generational garbage collection considers the lifetime of an object to avoid extra work.

The heap is divided into two general areas: New and Old. The New generation area is sub-divided 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 threshold, and then they are moved out of the New area and into the Old. For information about specifying the size and ratios of the New 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 determines how often garbage collection occurs. 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, impacting your performance.

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

 

---

Determining Heap Size

This section describes basic steps for determining the most effective heap size:

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

2. Use the -verbosegc option to measure exactly how much time and resources are put into garbage collection.

3. Turn on verbose garbage collection output for your Java VM and redirect both the standard error and standard output to a log file.

   See Turning On Verbose Garbage Collection and Redirecting Output.

4. Analyze the following:

   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% free, you might set the heap size smaller.

5. If you are using 1.3 Java HotSpot JVM, set generation sizes.

   Specifying Heap Size Values.

6. 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.

7. 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% of the available RAM (not taken by the operating system or other processes) for your JVM.

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

See also Specifying Heap Size Values

Turning On Verbose Garbage Collection and Redirecting Output

This section describes how to turn on verbose garbage collection and redirect output to a log file for diagnostic purposes:

1. Turn on verbose garbage collection output for your Java VM when you start WebLogic Server, as shown in the example in the following step.

2. 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:

   % java -ms64m -mx64m -verbosegc -classpath $CLASSPATH
   -Dweblogic.domain=mydomain -Dweblogic.Name=clusterServer1
   -Djava.security.policy==/bea/weblogic6x/lib/weblogic.policy
   -Dweblogic.management.server=192.168.0.101:7001 -Dweblogic.management.username=system
   -Dweblogic.management.password=systemPassword weblogic.Server >> logfile.txt

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

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

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

On Solaris, use the following command:

weblogic.Server > server.out 2>&1

 

---

Specifying Heap Size Values

You can specify Java heap size values when starting the WebLogic Administration Server from the Java command line. For example:

$ 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.

Be aware that WebLogic Server startup and environment scripts affect these parameters. Sample scripts are provided with the WebLogic distribution for starting the default server and for setting the environment to build and run the server:

• startWebLogic.cmd and setEnv.cmd for Windows systems

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

You will need to modify these scripts to fit your environment and applications. See Starting and Stopping WebLogic Servers.

Java Heap Size Options

You achieve best performance by individually tuning each of your applications. Configuring the JVM heap size options listed in Table 2-2 increases performance for most applications.

The options listed in Table 2-2 may differ depending on your architecture and operating system. See your vendor's documentation for platform-specific JVM tuning options.

Table 2-2 Java Heap Size Options

Task	Option	Description
Setting the New generation heap size	-XX:NewSize	Use this option to set the New generation Java heap size. Set this value to a multiple of 1024 that is greater than 1MB. As a general rule, set -XX:NewSize to be one-fourth the size of the maximum heap size. Increase the value of this option for larger numbers of short-lived objects. 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	Use this option to set the maximum New generation Java heap size. Set this value to a multiple of 1024 that is greater than 1MB.
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. Use the -XX:SurvivorRatio=X option to configure the ratio of the Eden/survivor space size. Try setting this value to 8 and then monitor your garbage collection.
Setting minimum heap size	-Xms	Use this option to 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 (-Xms) equal to the maximum heap size (-Xmx).
Setting maximum heap size	-Xmx	Use this option to set the maximum Java heap size. Set this value to a multiple of 1024 that is greater than 1MB.

 

---

Forcing Garbage Collection

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

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

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

2. Click the Monitoring tab.

3. Click the JVM tab.

4. Check the Memory Usage graph for high usage.

   Note that the Memory Usage graph displays only for servers that are currently running.

5. Click the Force Garbage Collection text link to force garbage collection.

   A message displays indicating that the collection operation was successful.

 

---

Setting Java HotSpot VM Options

You can use standard java options to improve performance. Be aware that 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.

You need to test both your client and server JVMs and see what performs better for your particular application.

See Setting Non-Standard Java Command Line Options for more VM options that affect performance.

Standard Options for NT

For NT, WebLogic Server invokes the JVM via the java command. Use the options listed in listed in Table 2-3.

Table 2-3 Standard options for HotSpot VM on NT

Option	Description
-hotspot	Selects the Client HotSpot VM.
-server	Selects the server VM.
-classic	Selects the classic VM.

Standard Options for UNIX

For UNIX, the WebLogic Server invokes the JVM via the java command. Use the options listed in listed in Table 2-4.

Table 2-4 Standard options for HotSpot VM on UNIX

Option	Description
-client or -hotspot	Selects the Client HotSpot VM.
-server	Selects the server VM.

 

---

Setting Non-Standard Java Command Line Options

You can use non-standard java options to improve performance. Be aware that 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.

Non-Standard Options for NT

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

Table 2-5 Non-standard options for HotSpot VM on NT

Option	Description
-Xnoclassgc	This option disables garbage collection for the class, It prevents re-loading of the class when the class is referenced after all references to it have been lost. This option requires a greater heap size.
-oss	This option controls the Java thread stack size. Setting it too high (>2MB) severely degrades performance.
-ss	This option controls the native thread stack size. Setting it too high (>2MB) severely degrades performance.
-Xverbosegc:file=/tmp/gc$$.out	This option redirects -verbosegc messages to a file, allowing you to separate your garbage collection messages from the rest of the messages on stderr. It also provides a performance advantage because writes to files are buffered better than writes to a character stream like stderr. See also Turning On Verbose Garbage Collection and Redirecting Output.

Non-Standard Options for Solaris

See non-standard options for Solaris VMs.