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 SizeTo 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 ServerYou 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:
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 OptionsThe 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.
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:
Monitoring the WebLogic Server Heap and Forcing Garbage CollectionThe Administration Console allows you to monitor the memory usage of WebLogic Server. To monitor the heap through the console, follow these steps:
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 ServerWebLogic 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:
|