Introduction to WebLogic Real Time, Core Edition

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

Tuning Real Time Applications for Deterministic Garbage Collection

This section contains the following guidelines for tuning your applications for the JRockit deterministic garbage collector that is included with WebLogic Real Time, Core Edition.

Note: For more information on adjusting other non-standard start-up commands available with JRockit, see the JRockit Configuration and Tuning Guide.


Basic Environment Tuning

Use these guidelines for configuring your environment to use WebLogic Real Time, Core Edition.


Basic Application Tuning

Use these guidelines when designing your applications for WebLogic Real Time, Core Edition.


J2EE Application Tuning

Use these guidelines when tuning your J2EE applications for WebLogic Real Time, Core Edition.


JMS Application Tuning

Use these guidelines when using WebLogic JMS applications with WebLogic Real Time, Core Edition.


JVM Tuning for Real-Time Applications

These tuning suggestions can further improve performance and decrease pause times when using the JRockit deterministic garbage collector. For more information on the deterministic garbage collector, see Minimal Transaction Latency (The Deterministic Garbage Collector) in the BEA JRockit Diagnostics Guide.

Allow For a Warm-up Period

There may be a warm-up period before response times achieve desired levels. During this warm-up, JRockit will optimize the critical code paths. The warm-up period is application and hardware dependent, as follows:

Adjust Min/Max Heap Sizes

Setting the minimum heap size (-Xms) smaller or the maximum heap size (-Xmx) larger affects how often garbage collection will occur and determines the approximate amount of live data an application can have. To begin with, try using the following heap sizes:

   java -Xms1024m -Xmx1024m -XgcPrio:deterministic -XpauseTarget=30

For more information, see -X Command-line Options in the BEA JRockit Reference Manual.

Increase or Decrease Pause Targets

For more information, see -X Command-line Options in the BEA JRockit Reference Manual.

Set the Page Size

Increasing the page size (-XXlargePages) can increase performance and lower pause times by limiting cache misses in the translation look-aside buffer (TLB). See -XX Command-line Options in the BEA JRockit Reference Manual.

Determine Optimal Load

Do not be overcautious in terms of load. The deterministic garbage collector can handle a fair amount of load without breaking its determinism guarantees. Too little load means the JVM's optimizer and GC heuristics have too little information to work with, resulting in sub-par performance. A best practice is to run your benchmarks at various loads (with and without deterministic GC) to determine the optimal load.

Analyze GC With JRockit Verbose Output

JRockit verbose output normally doesn't incur a measurable performance impact, and is quite useful for analyzing JVM memory and GC activity. Table 2-1 defines recommended verbose options for analyzing JVM memory and GC activity.

Table 2-1 JRockit Verbose Output Options
What it does...
For GC and memory analysis.
Redirects verbose output to the designated file.
Prints a formatted date before each verbose line.

Limit Amount of Finalizers and Reference Objects

Try to limit the amount of Finalizers and reference objects that are used, such as Soft-, Weak-, and Phantom- references. These types require special handling, and if they occur in large numbers then pause times can become longer than 30ms.

Adjust the GC Trigger

Try adjusting the garbage collection trigger (-XXgctrigger) to limit the amount of heap space used. This way, you can force the garbage collection to trigger more frequent garbage collections without modifying your applications. The garbage collection trigger is somewhat deterministic, since garbage collection starts each time the trigger limit is hit. See Adjust the Garbage Collection Trigger in the BEA JRockit Diagnostics Guide.

Note: If the trigger value is set to low, the heap might get full before the garbage collection is finished, causing even longer pauses for threads since they have to wait for the garbage collection to complete before getting new memory. Typically, memory is always available since a portion of the heap is free and any pauses are just the small pauses when the garbage collection stops the Java application.

Adjust the Amount of GC Threads for Processors

With the variety of sophisticated processing hardware currently available (HyperTransport, Strands, Dual Core, etc.), JRockit may not be able to determine the appropriate number of GC threads it should start. The current recommendation is to start one thread per physical CPU; that is, one thread per chip not per core. However, having too many GC threads could affect the latency of applications since more threads will be running on the system, which might saturate the CPUs, and thus affect the Java application. Conversely, setting them too low could increase the mark phase of the GC, since less parallelism is possible. For example, on a dual core Intel Woodcrest machine with four cores the recommended number of GC threads is two, which is the same as the number of processors in the machine.

To see how many GC threads that JRockit uses on your machine, start JRockit with -verbose:memdbg and then check for the following lines that are printed during startup:

   [memdbg ] number of oc threads: <num>
[memdbg ] number of yc threads: <num>

If necessary, adjust the number of GC threads using the -XXgcthreads:<# threads> parameter.

For more information, see -XX Command-line Options in the BEA JRockit Reference Manual.


More Tuning Information

This section contains pointers to additional performance and tuning information.

JRockit JVM

See BEA JRockit Diagnostics Guide for additional diagnostic information about BEA JRockit.

WebLogic Server

  Back to Top       Previous  Next