Tuning Java Virtual Machines (JVMs)

 

The Java virtual machine (JVM) is is an abstract computing machine designed to support the Java programming language. How you tune your JVM affects the performance of WebLogic Server and your applications.The following sections discuss JVM tuning considerations:

• JVM Tuning Considerations

• Tuning Heap Size

• Using Non-Standard Java Command Line Options

JVM Tuning Considerations

Table 2-1 discusses general JVM tuning considerations.

Table 2-1 General JVM Tuning Considerations 

Issue	Description
JVM vendor and version	The JVM vendor and version affect performance. 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. Check this page often for the most current JVM information.
Mixed client/server JVMs	Deployments using different JVM versions for the client and server are supported in WebLogic 6.0. For information about support for mixed client/server JVMs. Check the Platform Support page often for the most current information.
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 because the Java HotSpot Client and Server Virtual Machines are two separate JITs accessing the same runtime system. See Java Virtual Machine (JVM) Information.
UNIX threading models	On UNIX, two threading models are available: green threads and native threads. To get the best performance and scalability with WebLogic Server, choose a JVM that uses native threads, not green threads. See your VM documentation for more information about threading. For Solaris, see "Threading Models and Solaris Versions Supported" on the JavaSoft web site.
Tuning heap size	See Tuning Heap Size.

Tuning Heap Size

The JVM heap size determines how often and how long the VM spends collecting garbage (de-allocating unused Java objects).The JVM heap is a repository for live objects, dead objects, and free memory. When a JVM runs out of memory in the heap, all execution in the JVM stops while a garbage collection algorithm goes through memory and frees space that is no longer required by an application. This process affects performance because server-side work cannot proceed during garbage collection.

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.

Determining Heap Size

This section describes how to determine the most effective heap size:

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

2. Redirect -verbosegc messages to a file.

   • On HPUX, the following non-standard option redirects 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 it

   • On Solaris, use the following command:

     weblogic.Server > server.out 2>&1

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

   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.

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

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

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

Setting Minimum Heap Size Equal to Maximum Heap Size

Set the minimum heap size equal to the maximum heap size. This yields higher performance throughput than setting the values differently, and prevents the JVM from spending time incrementing the heap. You specify the minimum and maximum values for Java heap memory when starting the WebLogic Administration Server from the Java command line.

For example:

$ java ... -XX:NewSize=128m -XX:MaxNewSize=128m -XX:SurvivorRation=2 -Xms512m -Xmx512m

Setting High Heap Size for Benchmarking

To ensure maximum performance, you might set high heap size values to ensure that garbage collection does not occur during the entire run of the benchmark.

Using Non-Standard Java Command Line Options

You can use non-standard java options to improve performance. Be aware that use of these options depends on how your application is coded.

Non-Standard Options for Hotspot VM on NT

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

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

Option	Description
-Xnoclassgc	This option disables garbage collection for the class, preventing re-loading of the class when it is referenced after all references to it have been lost. This option requires a greater heap size.
-XX:NewSize, -XX:MaxNewSize, -XX:NewSizeThreadIncrease	These options control the amount of heap reserved for object creation. -XX:NewSize sets the initial size. -XX:MaxNewSize sets the maximum size. -XX:NewSizeThreadIncrease sets the increment-size. For applications that frequently create a lot of objects modifying the values of these options could boost performance.
-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.

Non-Standard Options for HotSpot VM on Solaris

See non-standard options for Solaris VMs at .