Tuning the JVM

Clearly, the JVM's performance also affects WebLogic's performance. Most aspects of JVM tuning relate to the efficient management of the memory heap, an efficient garbage collection scheme, and the choice between two Unix threading models: green and native threads.

15.3.1 Choosing a JVM

WebLogic publishes a list of certified JVM and operating system combinations on its web site; we recommend that you only use one of these certified combinations. This list also indicates what JVM version can be used. For example, WebLogic 8.1 supports JDK 1.4.1, whereas WebLogic 7.0 supports JDK 1.3.1.

SunSoft's JVM and BEA's JRockit are the two most commonly used JVMs. JRockit is a production VM optimized for server-side applications on Intel platforms. WebLogic 8.1 installs with a version of JRockit 8. You can download a version of JRockit 7 for WebLogic 7.0 from BEA's dev2dev web site.

The right JVM will strike a balance between several constraints, such as operating system, hardware and JVM stability, and performance. You can reference third-party documents for an overview of the general performance characteristics of the various JVMs.

15.3.2 Heap Size and Garbage Collection

The Java heap represents the memory space for all runtime objects. At any time, the heap consists of live objects, dead objects, and free memory. When an object is no longer referenced by anyone, it is considered "garbage" and is ready to be reclaimed as free memory. Garbage collection is the JVM's way of managing the JVM heap it refers to the process of reclaiming unused Java objects from the heap. JVM heap size impacts the frequency and duration that a JVM spends on garbage collection.

Ultimately, you need to tune the JVM's heap size to ensure that the VM spends as little time on garbage collection as possible while still maximizing the number of clients that WebLogic supports. We look at how to adjust the heap size for a WebLogic instance, and how to automatically log low memory conditions for the server. In order to understand Java's heap size options, we also look at the generational garbage collection scheme used by Sun's Java 1.4 Hotspot VM. There are many other garbage collection schemes, and you will need to read your JVM's documentation to familiarize yourself with them.

15.3.2.1 Configuring the heap size

You must specify Java heap size values each time you start WebLogic. You can do this either from the Java command line or by modifying heap size values used by WebLogic's startup scripts. For instance, here's how you can specify the minimum and maximum heap sizes from the Java command line:

$ java -Xms512m -Xmx512m -Dweblogic.Name=%SERVER_NAME% -Dbea.home="C:ea" -Dweblogic.management.username=%WLS_USER% -Dweblogic.management.password=%WLS_PW% -Dweblogic.management.server=%ADMIN_URL% -Dweblogic.ProductionModeEnabled=%STARTMODE% -Djava.security.policy="%WL_HOME%serverlibweblogic.policy" weblogic.Server

The -Xms and -Xmx options enable you to set the minimum and maximum sizes for the JVM heap, respectively. In this case, the JVM heap size is set to 512 MB of the system's memory. In general, you can minimize the number of garbage collections if you set the minimum heap size (-Xms) equal to the maximum heap size (-Xmx).

In WebLogic 7.1, you can modify WebLogic's startup script, startWLS, located in the WL_HOMEserverin directory. This script specifies default arguments for the JVM's heap size using environment variables, which are then used to start WebLogic Server.

You also should consider the following guidelines when configuring the JVM's heap size:

• Ensure that the heap's size is not larger than the available free RAM on the machine. You should allocate as much of the free RAM as possible without causing your machine to unnecessarily swap pages to disk.
• You may discover that the JVM is spending too much time on garbage collection. In that case, consider lowering the JVM's heap size. In general, you may allocate up to 80% of the available free memory for your JVM while still monitoring the time the server spends on garbage collections.

15.3.2.2 Generational garbage collection

Both the Java 1.3 and 1.4 VMs rely on a generational collector that significantly improves the overall speed of object allocation and the efficiency of the garbage collection. It works on the principle that most objects created during the lifetime of a program are short-lived. By creating separate spaces for different generations of objects, the JVM can limit the scope of its garbage collection. A generation refers to the set of objects in the heap that survive an iteration of the JVM's garbage collection. Older generations survive more iterations than their younger counterparts. Infant mortality refers to those objects that become garbage very shortly after being allocated in the heap.

The JVM's heap is divided into two areas: young and old. The young generation area is further subdivided into Eden and two survivor spaces (of equal size). Eden refers to the area where new objects are allocated. After a pass of the JVM's garbage collector, all surviving live objects are copied into either one of the two survivor spaces. On successive iterations of garbage collection, objects are copied between these survivor spaces until they exceed a maximum heap size threshold value, in which case they are transferred to the old generation area.

By setting aside separate memory pools to hold objects of different generations, the garbage collector needs to run in each generation only when it fills up. You can therefore fine-tune the JVM's garbage collection by relying on the fact that the majority of the objects die young, thereby optimizing the garbage collection cycles. However, improperly configured sizes for different generations also can degrade the performance of garbage collection.

In order to specify the sizes for the Eden and survivor spaces for WebLogic, you need to run the following command:

java -Xms768m -Xmx768m -XX:NewSize=192m -XX:MaxNewSize=192m -XX:SurvivorRatio=8 -Dweblogic.Name=%SERVER_NAME% -Dbea.home="C:ea" -Dweblogic.management.username=%WLS_USER% -Dweblogic.management.password=%WLS_PW% -Dweblogic.management.server=%ADMIN_URL% -Dweblogic.ProductionModeEnabled=%STARTMODE% -Djava.security.policy="%WL_HOME%serverlibweblogic.policy" weblogic.Server

The -XX:NewSize and -XX:MaxNewSize options let you specify the minimum and maximum sizes of the new generation area, respectively. As a general rule, you should ensure the size of the new generation area is one-fourth of the maximum heap size. If you have a larger number of short-lived objects, you also may consider increasing the size of the new generation area. As mentioned earlier, the new generation area is further subdivided into Eden and two survivor spaces of equal size. Use the -XX:SurviverRatio=Y option to set the ratio of the Eden/survivor spaces 8 is a good starting point for the Eden/survivor ratio. You then can monitor the frequency and the duration of garbage collection during the lifetime of the server and adjust this setting accordingly.

These additional JVM heap size configuration options may differ depending on the platform or operating system on which the JVM runs. In that case, you need to consult the vendor documentation to learn more about the platform-specific equivalents for these JVM heap tuning options.

In order to enable the HotSpot VM, you may need to explicitly pass additional options to the Java command line. On Windows platforms, use the -hotspot or -client option to select the HotSpot VM for client-side applications, and use the -server option to enable the HotSpot VM for server-side applications. For an in-depth discussion on the Java HotSpot VM, refer to http://java.sun.com/docs/hotspot/.

In some cases, the generational garbage collector may not give you optimal performance. For example, if you have deployed a WebLogic server to a multi-CPU machine, using WebLogic's JRockit and its parallel garbage collector could be more optimal.

15.3.2.3 Automatically logging low memory conditions

WebLogic can log low memory conditions automatically. It samples the available free memory a set number of times during a fixed time interval. At the end of each interval, it computes the average free memory for that interval. If the average drops by a user-configured amount after any sample interval, WebLogic logs a warning message indicating the low memory and changes the server's health status to "warning." In addition, WebLogic logs a warning message if at any time the average free memory after any interval drops below 5% of the initial free memory.

Use the Administration Console to adjust the low memory detection behavior for a particular server. Select the desired server from the left pane of the Administration Console and then choose the Configuration/Tuning tab from the right pane. Table 15-3 lists the parameters that determine how the server detects low memory conditions.

Once you've applied your changes, you need to restart the server for them to take effect.

15.3.2.4 Explicit request for garbage collection

You can use the Administration Console to explicitly request garbage collection on a particular WebLogic instance. Choose the desired server from the left pane of the Administration Console and then select the Monitoring/Performance tab. Examine the Memory Usage graph to verify high memory utilization on a server. You then can click the "Force garbage collection" button to explicitly invoke System.gc( ) on the particular JVM. This call's behavior will differ between different JVMs. If you must go to these lengths, your application's memory allocation needs probably suffer from a more fundamental problem.

15.3.3 Green Versus Native Threads

On many Unix platforms, the JVM has a choice between two threading models: green threads and native threads. Green threads are Java threads provided by the JVM itself. Native threads are kernel-based threads provided by the OS on which the JVM runs.

Green threads are lightweight and have a smaller memory footprint than native threads. A JVM typically runs multiple green threads within a single OS thread. Therefore, green threads enable the JVM to optimize thread-management tasks such as scheduling, switching, and synchronization. Alternatively, a JVM can rely on native threads directly, in which case each JVM thread maps to a single OS thread. Native threads have a larger memory footprint and also incur a higher overhead during creation and context switching. It also means that the number of concurrent JVM threads is limited by the number of processes/threads built into the kernel.

Native threads offer better performance on multi-CPU machines because they can benefit from the OS support for thread scheduling and load balancing across multiple CPUs. On a single-CPU machine, green threads probably offer better performance for most applications.

Most JVMs for Unix platforms provide a -native or -green option that lets you choose the threading model for your application.

15.3.4 Monitoring the JVM's Performance

It is a good idea to occasionally monitor the performance of the JVM, especially the garbage collection behavior. Most JVMs have a -Xverbosegc switch that can help trace the garbage collection behavior, and additional tools that can be used to analyze these traces. Some JVMs, such as BEA's JRockit, have management consoles that provide real-time information about the JVM and the application running in the JVM.