Tuning the Java Virtual Machine (JVM) | BEA WebLogic Platform 7

WebLogic Server is a Java-based application server and runs inside the Java Virtual Machine. To achieve optimum performance for your application deployed on WebLogic Server, you need to fine-tune various JVM parameters too. This section describes these parameters and how you can tune them.

Tuning the JVM Heap Size

To understand the process of tuning the JVM heap size, you need to understand what the JVM heap consists of, how it grows and shrinks, and how garbage collection is done. In this section, we explain these concepts. The Java heap consists of free memory, live objects (ones that are in use), and dead objects (ones that are not referenced). All the Java objects live in the Java heap. During the lifetime of a Java program, new objects may be created, and objects that were active earlier may become unused. The unused or dead objects cannot be reached from any pointer in a running program. During the execution of a Java program, more objects are created and the JVM starts running out of free memory in the heap. When the heap in use reaches a certain limit, the JVM initiates garbage collection. This process cleans up the unused objects and frees some memory. In the nave garbage collection technique, also known as stop and run , when the garbage collection starts, the JVM stops execution. This is not good for server performance. The 1.3 Java HotSpot Virtual Machine provides another flavor known as generational garbage collection, which is better in performance.

Tuning the size parameter of the JVM heap is important because it controls the frequency of the garbage collection process as well as how long the garbage collection will run when the JVM starts it. If the heap size is large, the full garbage collection cycle will run longer but less frequently. If the heap size is smaller, the garbage collection will be much more frequent but run much faster. The heap size should be tuned such that the JVM spends less time doing the garbage collection and, at the same time, the server gives the maximum throughput.

Determining Heap Size for the WebLogic Server

You can specify the minimum and maximum heap size for a JVM using the -ms and -mx parameters, respectively. The minimum heap size parameter means that amount of memory will always be allocated for the virtual machine. The heap can grow until the -mx limit as more objects are created. After you determine the maximum heap required by your WebLogic server, set the minimum heap size equal to the maximum heap size. This will give better performance because the maximum heap required will be allocated while starting up instead of as needed after the server has started.

You should set the maximum heap size to be 80 to 85% of the actual available RAM. This will prevent swapping of pages to disk, which decreases performance. In addition, it is a good practice to run WebLogic Server instance on a dedicated machine so that its maximum heap size can be configured to 80 to 85% of the total RAM available on that machine.

You can specify the verbose garbage collection parameter -verbosegc to the JVM so that it logs out all the garbage collection related information. The information printed out by the JVM includes the amount of time the garbage collection cycle ran as well as the amount of memory that was freed. You can redirect the -verbosegc output to a log file and then analyze it to determine the optimum heap size for your application. Set the -verbosegc flag as follows while starting WebLogic Server:

 java -ms256m -mx256m -verbosegc ..... weblogic.Server >> log.txt 2>&1

This command sets the -verbosegc flag for the JVM and redirects both stdout and stderr to the log.txt file.

You get the following output when the -verbosegc flag is passed to the JVM:

 [GC 25299K->23266K(204544K), 0.0512523 secs] [GC 25314K->23175K(204544K), 0.0039530 secs] [GC 25222K->23179K(204544K), 0.0058421 secs] [GC 25227K->23209K(204544K), 0.0045444 secs] [Full GC 24838K->23271K(204544K), 0.8871415 secs]

The Full GC cycle freed 24838KB 23271KB = 1567KB of heap and took 0.8871415 seconds to do so. The number in parentheses is the total memory available, which is 204544KB, or 200MB. Therefore, after the Full GC cycle, the amount of memory in use is 23271KB.

In the verbosegc output, the line beginning with GC indicates a minor garbage collection cycle and the line beginning with Full GC indicates a major garbage collection cycle. The minor cycle reclaims memory in the young generational area, whereas the major cycle runs longer and reclaims memory in the old generation area. The generation areasyoung and oldare concepts that are part of the generational garbage collection algorithm that the Java HotSpot VM uses and are explained later in this section.

With the verbosegc flag set, run a realistic load test and capture the garbage collection information. Analyze the following points from the log file:

The period for which the full garbage collection ran. When the full garbage collection cycle runs, the JVM pauses the execution of other threads. As a result, the WebLogic Server would not be able to respond to client requests during the period of the garbage collection cycle. A full garbage collection cycle should not take more than 3 to 5 seconds usually. If the cycle runs for a longer period of time, consider decreasing the heap size.
The frequency of the full garbage collection cycle. If this happens, the heap is set too low for your application and the client load it is handling, so the JVM runs out of heap frequently and has to start the full garbage collection cycle to free memory. You should increase the heap size and reprofile the application.
The heap size in use after a full garbage collection cycle. The verbosegc parameter outputs the amount of heap that was freed in a garbage collection cycle as well as the amount of heap that is in use currently by the JVM. Monitor the amount of heap in use after a full garbage collection cycle. This is the footprint of your application. Tune the heap such that the footprint size is at 80 to 85% of your available RAM.

In all these cases, you should tune the heap size, reprofile WebLogic Server with the new heap settings, and analyze the garbage collection information.

If you have a large amount of available free RAM on your machine, consider running more instances of WebLogic Server instead of increasing the heap for one instance.

Setting the JVM Heap Size Options

The most straightforward garbage collection algorithms examine every living object in the heap to check whether it is in use. This technique is prohibitively costly, especially for large Java applications, because the garbage collection algorithm takes time proportional to the number of living objects.

The 1.3 Java HotSpot VM uses a generational garbage collection algorithm that considers the lifetime of an object to avoid the extra collection work. It is based on the basic premise that a majority of objects die young and hence should not be considered for garbage collection at all. To do this, the JVM divides the heap into memory pools holding objects of different ages. The heap is divided into two areas: young and old . The young generation area is further divided into Eden and two survivor areas. There is also a portion of the heap called permanent generation , which holds the classes and method objects (see Figure 28.13).

Figure 28.13. Division of heap into young and old generational areas in the 1.3 Java HotSpot VM.

graphics/28fig13.gif

New objects are created in the Eden generational area. Because most objects are short lived, they die in this area. One survivor space is kept empty at any time, and it allows for moving objects when the Eden area or the other survivor space fills up. This causes a minor garbage collection. When the number of objects in the survivor space reaches a certain threshold, the objects are moved out from the survivor space into the old generational area. When the old generational area is filled, there is a major or full garbage collection cycle.

The memory management based on the lifetime of objects provides significant improvement in the garbage collection efficiency of the Java HotSpot VM.

Because the default garbage collection parameters were designed for small applications, they are not optimal for large server applications such as WebLogic Server. To achieve optimum performance for your application deployed on WebLogic Server, consider tuning the following parameters depending on your application, client load, and available RAM:

Minimum heap size This is specified with the -Xms optionfor example:
```
 
```
```
 -Xms=64M 
```
This sets the minimum heap with which the JVM starts.
Maximum heap size This is specified with the -Xms optionfor example:
```
 
```
```
 -Xmx=200M 
```
This sets the maximum heap size allocated for the JVM. As more Java objects are created, the heap size will be increased until it reaches this limit.
NewRatio This is specified with the -XX:NewRatio optionfor example:
```
 
```
```
 -XNewRatio=3 
```
This controls the ratio between the young and the old generational areas. In this example, the ratio between young and old areas is 1:3.

Note

Because the entire heap is divided into the young and old areas, the larger the young area, the smaller will be the old area. If the ratio divides the heap such that the older area is smaller, this will increase the frequency of the major garbage collection cycles. This ratio should be tuned based on the lifetime distribution of objects created by your application.
New generation heap size This is specified with the -XX:NewSize optionfor example:
```
 
```
```
 -XXNewSize=128M 
```
This sets the minimum young generation size. Increase the young generation heap size if your application creates a large number of short-lived objects.
Maximum new generation heap size This is specified with the -XX:MaxNewSize optionfor example:
```
 
```
```
 XXMaxNewSize=128M 
```
This sets the maximum young generation size.
New heap size ratio This is specified with the -XX:SurvivorRatio optionfor example:
```
 
```
```
 -XX:SurvivorRatio=6 
```
This option configures the ratio between the Eden and survivor spaces. If the ratio is set to 6, the ratio of survivor space to Eden space will be 1:6. Because there are two survivor spaces, each survivor space will be one eighth of the young generation space.

Monitoring the WebLogic Server Heap and Forcing Garbage Collection

The Administration Console allows you to monitor the memory usage of WebLogic Server. To monitor the heap through the console, follow these steps:

Start the Administration Server and access the Administration Console.
Click the Servers node in the left pane to display the servers configured in your domain.
Click the name of the server instance that you want to monitor the heap usage.
Select the Monitoring, Performance tab in the right pane, as shown in Figure 28.3.
Monitor the memory usage graph on this page. The graph shows the total memory in the top-left corner and the actual heap in use above the line graph.

To manually force garbage collection on the server, click the Force Garbage Collection button. If WebLogic Server was started with the -verbosegc option, you will see a Full GC cycle run in the server and the message printed to the stdout when the garbage collection is manually forced through the console.

Detecting Low Memory Conditions in WebLogic Server

WebLogic Server allows you to automatically detect and handle low memory conditions in the server. The server samples the available free memory over a period of time and, depending on the thresholds set, forces garbage collection if a low memory condition is detected .

To configure automatic detection of low memory, follow these steps:

Start the Administration Server and access the Administration Console.
Click the Servers node in the left pane to display the servers configured in your domain.
Click the name of the server instance for which you want to configure the low memory detection.
Select the Configuration, Memory tab in the right pane.
Set the various attributes as follows:
- Low Memory GCThreshold Set this value as a percentage to represent the threshold at which the server will perform automatic garbage collection. The default value is 5%, which means that if the amount of free memory drops down to 5% of the free memory available at bootup time, the server will start garbage collection.
- Low Memory Granularity Level Set this value as a percentage that will be used by the server to log low memory conditions. The server's health state is changed to Warning when this threshold is reached. By default, the value is set to 5%. The server samples the free heap periodically, and if the average free memory available drops by 5% or more over two sample intervals, it logs a low memory warning and changes the server's health to Warning.
- Low Memory Sample Size Set this value to set the number of times the server will check the amount of free memory during a fixed time period. The default value is 10.
- Low Memory Time Interval Set this value to a time in seconds that will control the frequency at which the server calculates the average free memory. The default value is set to 3600 seconds. By default, the server will determine the average free heap with 10 samples taken over an hour .
Click the Apply button to persist the changes to the config.xml file.
Shut down and restart the server for the changes to take effect.