This section contains the following guidelines for tuning your applications for the Oracle JRockit JVM deterministic garbage collector that is included with Oracle JRockit Real Time.
Note: | For more information on adjusting other non-standard start-up commands available with JRockit, see the JRockit Configuration and Tuning Guide. |
Use these guidelines for configuring your environment to use Oracle JRockit Real Time.
For information on tuning JRockit garbage collection threads, see Adjust the Amount of Garbage Collection Threads for Processors.
Use these guidelines when designing your applications for Oracle JRockit Real Time.
Use these guidelines when tuning your J2EE applications for Oracle JRockit Real Time.
max-beans-in-free-pool
property and tune thread pool sizes
Use these guidelines when using Oracle WebLogic JMS applications with JRockit Real Time.
For more information on JMS consumers, see Best Practices for Application Design in Programming WebLogic JMS.
1
enabled
ACKNOWLEDGE_PREVIOUS
For more information on configuring JMS connection factories, see Configure connection factories in the Administration Console Online Help.
Note: | Resource reference pooling is not suitable if the target destination changes with each call, in which case change application code to use regular JMS and cache the JMS connections, sessions, producers, and consumers. |
These tuning suggestions can further improve performance and decrease pause times when using the JRockit JVM deterministic garbage collector. For more information on the deterministic garbage collector, see the Oracle JRockit Diagnostics Guide.
There may be a warm-up period before response times achieve desired levels. During this warm-up, JRockit JVM will optimize the critical code paths. The warm-up period is application and hardware dependent, as follows:
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 Oracle JRockit JVM Command-Line Reference.
-Xgcprio:deterministic
without the pauseTarget
option, it will be set to a default value, which in this release is 30 milliseconds.-XpauseTarget
option. The maximum allowable value for the pauseTarget
option is currently 5000 milliseconds.-XpauseTarget
value down to a minimum value. In this release, the minimum value is 10 milliseconds.For more information, see -X Command-line Options in the Oracle JRockit Command-Line Reference.
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 Oracle JRockit JVM Command-Line Reference.
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.
JRockit JVM 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.
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.
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 the
Oracle JRockit JVM 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. |
With the variety of sophisticated processing hardware currently available (HyperTransport, Strands, Dual Core, etc.), the JRockit JVM 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 garbage collection 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 garbage collection threads that the JRockit JVM uses on your machine, start the JRockit JVM 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 Oracle JRockit JVM Command-Line Reference.
This section contains pointers to additional performance and tuning information.
See Oracle JRockit JVM Diagnostics Guide for additional diagnostic information about the Oracle JRockit JVM.