Configuration Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Tuning JVM Garbage Collection for Production Deployments

The following sections describe how to tune Java Virtual Machine (JVM) garbage collection performance for engine tier servers:


Goals for Tuning Garbage Collection Performance

Production installations of WebLogic SIP Server generally require extremely small response times (under 50 milliseconds) for clients at all times, even under peak server loads. A key factor in maintaining brief response times is the proper selection and tuning of the JVM's Garbage Collection (GC) algorithm for WebLogic SIP Server instances in the engine tier.

Whereas certain tuning strategies are designed to yield the lowest average garbage collection times or to minimize the frequency of full GCs, those strategies can sometimes result in one or more very long periods of garbage collection (often several seconds long) that are offset by shorter GC intervals. With a production SIP Server installation, all long GC intervals must be avoided in order to maintain response time goals.

The sections that follow describe GC tuning strategies for JRockit and Sun's JVM that generally result in best response time performance.


Modifying JVM Parameters in Server Start Scripts

If you use custom startup scripts to start WebLogic SIP Server engines and replicas, simply edit those scripts to include the recommended JVM options described in the sections that follow.

The BEA Configuration Wizard also installs default startup scripts when you configure a new domain. These scripts are installed in the BEA_HOME/user_projects/domains/domain_name/bin directory by default, and include:

If you use the BEA-installed scripts to start engines and replicas, you can override JVM memory arguments by first setting the USER_MEM_ARGS environment variable in your command shell.

Note: Setting the USER_MEM_ARGS environment variable overrides all default JVM memory arguments specified in the BEA-installed scripts. Always set USER_MEM_ARGS to the full list of JVM memory arguments you intend to use. For example, when using the Sun JVM, always add -XX:MaxPermSize=128m to the USER_MEM_ARGS value, even if you only intend to change the default heap space (-Xms, -Xmx) parameters.


Using JRockit Deterministic Garbage Collection (WebLogic Real Time)

Very short response times are most easily achieved by using JRockit's deterministic garbage collector, which is available with BEA WebLogic Real Time as a seaparate license. BEA recommends using the following JVM arguments for replicated cluster configurations:


Tuning Garbage Collection with JRockit

When using BEA's JRockit JVM without deterministic garbage collection (the default version installed with WebLogic SIP Server), the best response time performance is generally obtained by using the single-spaced, concurrent garbage collector with a very small (1%) compaction rate.

The full list of example startup options for a replica server are:

-Xgc:singlecon -XXcompactratio:1 -Xms1536m -Xmx1536m -XXtlasize=6k

The full list of example startup options for an engine tier server are:

-Xgc:singlecon -XXcompactratio:1 -Xms768m -Xmx768m -XXtlasize=6k -Dwlss.noExplictGC=true

It is important to use the low compaction ratio setting along with the single-spaced GC algorithm to obtain the best response time performance. Note, however, that using the indicated compaction ratio may be problematic if you deploy applications that periodically allocate drastically different sizes of memory in the heap (for example a 10K allocation followed by byte-sized increments).

WARNING: If you deploy applications that allocate varying sizes of memory, using a small compaction ratio may lead to Out Of Memory errors or forced compaction, both of which must be avoided in a production system. You must thoroughly analyze deployed applications in a stage environment to determine which JVM settings are acceptable for your system.

JRockit provides several monitoring tools that you can use to analyze the JVM heap at any given moment, including:

Use these and other tools in a controlled environment to determine the effects of JVM settings before you use the settings in a production deployment. See the BEA WebLogic JRockit 1.4.2 SDK Documentation for more information about JRockit and JRockit profiling tools.


Tuning Garbage Collection with Sun JDK

When using Sun's JDK, the goal in tuning garbage collection performance is to reduce the time required to perform a full garbage collection cycle. You should not attempt to tune the JVM to minimize the frequency of full garbage collections, because this generally results in an eventual forced garbage collection cycle that may take up to several full seconds to complete.

The simplest and most reliable way to achieve short garbage collection times over the lifetime of a production server is to use a fixed heap size with the default collector and the parallel young generation collector, restricting the new generation size to at most one third of the overall heap.

The following example JVM settings are recommended for most engine tier servers:

-server -XX:MaxPermSize=128m -XX:+UseParNewGC -XX:MaxNewSize=256m -XX:NewSize=256m -Xms768m -Xmx768m -XX:SurvivorRatio=128 -XX:MaxTenuringThreshold=0  -XX:+UseTLAB -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

If the engine tier server enables caching for call state data, the example settings are:

-server -XX:MaxPermSize=128m -XX:+UseParNewGC -XX:MaxNewSize=32m -XX:NewSize=32m -Xms768m -Xmx768m -XX:SurvivorRatio=128 -XX:MaxTenuringThreshold=0  -XX:+UseTLAB -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

For replica servers, use the example settings:

-server -XX:MaxPermSize=128m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxNewSize=64m -XX:NewSize=64m -Xms1536m -Xmx1536m -XX:SurvivorRatio=128 -XX:MaxTenuringThreshold=0 -XX:CMSInitiatingOccupancyFraction=60 -Dsun.rmi.dgc.server.gcInterval=0x7FFFFFFFFFFFFFFE -Dsun.rmi.dgc.client.gcInterval=0x7FFFFFFFFFFFFFFE

The above options have the following effect:

  Back to Top       Previous  Next