|Oracle® Communications Converged Application Server Administration Guide
Part Number E17647-03
This chapter describes how to tune Java Virtual Machine (JVM) garbage collection performance for engine tier servers:
Production installations of Oracle Communications Converged Application 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 Converged Application 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.
Note:For more information on JRockit, see Introduction to Oracle WebLogic Server in the WebLogic Server documentation.
If you use custom startup scripts to start Converged Application Server engines and replicas, simply edit those scripts to include the recommended JVM options described in the sections that follow.
The Configuration Wizard also installs default startup scripts when you configure a new domain. by default, these scripts are installed in the
/bin directory, where
CAS50_home is where you installed the Converged Application Server software and
domain_name is the name of the domain's directory. The
/bin directory includes:
startWebLogic.sh: These scripts start the Administration Server for the domain.
startManagedWebLogic.sh: These scripts start managed engines and replicas in the domain.
If you use the Oracle-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.
USER_MEM_ARGSenvironment variable overrides all default JVM memory arguments specified in the Oracle-installed scripts. Always set
USER_MEM_ARGSto the full list of JVM memory arguments you intend to use. For example, when using the Sun JVM, always add
USER_MEM_ARGSvalue, even if you only intend to change the default heap space (
-Xms, -Xmx) parameters.
JRockit provides several monitoring tools that you can use to analyze the JVM heap at any given moment, including:
JRockit Runtime Analyzer: provides a view into the runtime behavior of garbage collection and pause times.
JRockit Stack Dumps: reveals applications' thread activity to help you troubleshoot and/or improve performance.
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.
The following sections describe suggested starting JVM options for use with the JRockit. If you use JRockit with the deterministic garbage collector (recommended), use the options described in "Using Oracle JRockit Real Time (Deterministic Garbage Collection)".
Very short response times are most easily achieved by using JRockit Real Time, which implements a deterministic garbage collector.
Oracle recommends using the following JVM arguments for engine tier servers in replicated cluster configurations:
-Xms1024m -Xmx1024m -XgcPrio:deterministic -XpauseTarget=30ms -XXtlasize:min=8k -XXnosystemgc
Note:The above settings are configured by default in the
$WL_HOME/common/bin/wlssCommenv.shfile when you use the Configuration Wizard to create a new domain with the JRockit JVM.
You may need to increase the
-XpauseTarget value for allocation-intensive applications. The value can be decreased for smaller applications under light loads.
Adjust the heap size according to the amount of live data used by deployed applications. As a starting point, set the heap size from 2 to 3 times the amount required by your applications. A value closer to 3 times the required amount generally yields the best performance.
For replica servers, increase the available memory:
-Xms3072m -Xmx3072m -XgcPrio:deterministic -XpauseTarget=30ms -XXtlasize:min=8k -XXnosystemgc
These settings fix the heap size and enable the dynamic garbage collector with deterministic garbage collection.
-XpauseTarget sets the maximum pause time and
-XXtlasize=3k sets the thread-local area size.
System.gc() application calls from forcing garbage collection.
When using Oracle's JRockit JVM without deterministic garbage collection (not recommended for production deployments), the best response time performance is obtained by using the generational concurrent garbage collector.
The full list of example startup options for an engine tier server are:
-Xms1024m -Xmx1024m -Xgc:gencon -XXnosystemgc -XXtlasize:min=3k -XXkeeparearatio=0 -Xns:48m
Note:Fine tune the heap size according to the amount of live data used by deployed applications.
The full list of example startup options for a replica server are:
-Xms3072m -Xmx3072m -Xgc:gencon -XXnosystemgc -XXtlasize:min=3k -XXkeeparearatio=0 -Xns:48m
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 -Xmx1024m -XX:MaxPermSize=128m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=256 -XX:CMSInitiatingOccupancyFraction=60 -XX:+DisableExplicitGC
For replica servers, use the example settings:
-server -Xmx3072m -XX:MaxPermSize=128m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=256 -XX:CMSInitiatingOccupancyFraction=60 -XX:+DisableExplicitGC
The above options have the following effect:
-XX:+UseTLAB: Uses thread-local object allocation blocks. This improves concurrency by reducing contention on the shared heap lock.
-XX:+UseParNewGC: Uses a parallel version of the young generation copying collector alongside the concurrent mark-and-sweep collector. This minimizes pauses by using all available CPUs in parallel. The collector is compatible with both the default collector and the Concurrent Mark and Sweep (CMS) collector.
-Xms, -Xmx: Places boundaries on the heap size to increase the predictability of garbage collection. The heap size is limited in replica servers so that even Full GCs do not trigger SIP retransmissions.
-Xms sets the starting size to prevent pauses caused by heap expansion.
-XX:MaxTenuringThreshold=0: Makes the full NewSize available to every NewGC cycle, and reduces the pause time by not evaluating tenured objects. Technically, this setting promotes all live objects to the older generation, rather than copying them.
-XX:SurvivorRatio=128: Specifies a high survivor ratio, which goes along with the zero tenuring threshold to ensure that little space is reserved for absent survivors.