|
|
Each Java application has its own behavior and its own requirements. The Oracle JRockit JVM can accommodate many of them automatically, but to get the optimal performance you should tune at least some basic parameters. This section gives an overview of the first steps of tuning the JRockit JVM and some best practices for tuning the JVM for a few different Oracle applications, covering the following topics:
For in-depth information on tuning the JRockit JVM, please see Tuning the Memory Management System and Tuning Locks.
The first steps of tuning are:
The heap is the area where Java objects reside. A large heap decreases the garbage collection frequency but may take slightly longer to garbage collect. Typically a heap should be at least twice the size of the live objects in the heap, meaning that at least half of the heap should be freed at each garbage collection. For server applications you can usually set the heap as large as the available memory in your system will allow, as long as this doesn’t cause paging.
Set the heap size using the following command line options:
For example a server application running on a machine with 2 GB RAM memory could be started with the following settings:
java -Xms:800m -Xmx:1000m MyServerApp
This starts the JVM with a heap of 800 MB and allows the heap to grow up to 1000MB.
For in-depth information on setting the heap size, see Setting the Heap Size.
Garbage collection is the process of reclaiming space from objects that are no longer in use, so that this space can be used for allocation of new objects. Garbage collection uses system resources in one way or another. By tuning the garbage collection you can decide how and when the resources are used. The JRockit JVM offers three garbage collection modes and a number of static garbage collection strategies. These allow you to tune the garbage collection to suit your application’s needs.
Select the garbage collection mode by using one of the following options:
-XgcPrio:throughput, which defines that the garbage collection should be optimized for application throughput. This is the default garbage collection mode.-XgcPrio:pausetime, which defines that the garbage collection should be optimized for short garbage collection pauses.-XgcPrio:deterministic, which defines that the garbage collection should be optimized for very short and deterministic garbage collection pauses. This option is only available as part of Oracle JRockit Real Time.For example a transaction based application which requires reasonably low latencies could be started with the following settings:
java -XgcPrio:pauseTime MyTransactionApp
This starts the JVM with the garbage collection optimized for short garbage collection pauses.
For in-depth information on selecting a garbage collection mode or a static garbage collection strategy, see Selecting and Tuning a Garbage Collector.
Some of the garbage collection modes and strategies in the JRockit JVM use a nursery. The nursery is an area of the heap where new objects are allocated. When the nursery becomes full it is garbage collected separately in a young collection. The nursery size decides the frequency and duration of young collections. A larger nursery decreases the frequency but slightly increases the duration of each young collection.
In the JRockit JVM R27.3.0 and later the nursery size is adjusted automatically to optimize for application throughput if you use -XgcPrio:throughput (default) or -Xgc:genpar. For other garbage collection modes and static strategies or older versions of the JVM you may want to tune the nursery size manually. Typically the nursery size should be as large as possible while maintaining reasonably short young collection pauses. Depending on the application, a reasonable nursery size can be anything from a few megabytes up to about half of the heap size.
Set the nursery size by using the following command line option:
For example a transaction based application running on a machine with 2GB RAM memory could be started with the following settings:
java -Xms:800m -Xmx:1000m -XgcPrio:pausetime -Xns:100m MyTransactionApp
This starts up the JVM with a heap of 800 MB, allowing it to grow up to 1000 MB. The garbage collection is set to optimize for pause times and the nursery size is set to 100 MB. Note that the dynamic garbage collection mode may choose to run without a nursery, but whenever a nursery is used it will be 100 MB.
For in-depth information on how to tune the nursery size, see Setting the Nursery and Keep Area Size.
-XgcPrio:pausetime and -XgcPrio:deterministic use a pause target for optimizing the pause times while keeping the application throughput as high as possible. A higher pause target usually allows for a higher application throughput, thus you should set the pause target as high as your application can tolerate.
Set the pause target by using the following command line option:
For example a transaction based application with transactions that normally take 100 ms and time out after 400 ms could be started with the following settings:
java -XgcPrio:pausetime -XpauseTarget:250 MyTransactionApp
This starts up the JVM with garbage collection optimized for short pauses with a pause target of 250 ms. This leaves a 50 ms margin before time-out for 100 ms transactions that are interrupted by a 250 ms garbage collection pause.
For in-depth information on tuning the pause target, see Setting a Pause Target for Pausetime Mode.
To be able to tune your JVM for better application throughput you must first have a way of assessing the throughput. A common way of measuring the application throughput is to time the execution of a pre-defined set of test cases. Optimally the test cases should simulate several different use cases and be as close to real scenarios as possible. Also, one test run should take at least a few minutes, so that the JVM has time to warm up.
This section describes a few optional performance features that improve the performance for many applications. Once you have a way of assessing the throughput of your application you can try out the following features:
The JRockit JVM R27.3 and later offers a feature called lazy unlocking. This feature makes synchronized Java code run faster when the contention on the locks is low.
Try this feature on your application by adding the following option to the command line:
For more information on this option, see the documentation for
-XXlazyUnlocking.
Call profiling enables the use of more advanced profiling for code optimizations and can increase the performance for many applications. This option is supported in the JRockit JVM R27.3.0 and later versions.
Try this feature on your application by adding the following option to the command line:
For more information on this option, see the documentation for
-XXcallProfiling.
The JRockit JVM can use large pages for the Java heap and other memory areas in the JVM. To use large pages, you must first configure your operating system for large pages. Then you can add the following option to the Java command line:
For complete instructions on how to use this option and configure your operating system for large pages, see the documentation for
-XlargePages.
Some applications may benefit from further tuning. It is important that you verify the results of the tuning by monitoring and benchmarking your application. Advanced tuning of the JRockit JVM can give you improved performance and predictable behavior if done correctly, while incorrect tuning may lead to uneven performance, low performance or performance degradation over time.
This section covers the following topics:
Compaction of objects is the process of moving objects closer to each other in the heap, thus reducing the fragmentation and making object allocation easier for the JVM. The JRockit JVM compacts a part of the heap at each garbage collection (or old collection, if the garbage collector is generational).
Compaction may in some cases lead to long garbage collection pauses. To assess the impact of compaction on garbage collection pauses you can either monitor the -Xverbose:gcpause outputs or create a JRA recording and look at the garbage collection pauses in the Java Runtime Analyzer (see Using Oracle JRockit Mission Control Tools for more information). Look for old collection pause times and pause parts called “compaction” and “reference updates”. The compaction pause times depend on the compaction ratio and the compact set limit.
The compaction ratio determines how many percent of the heap will be compacted during each garbage collection (old collection). The compaction ratio is set using the following option:
You can tune the compaction ratio if the garbage collection pauses are too long because of compaction. As a start, you can try lowering the compaction ratio to 1 and see if the problem persists. If it doesn’t, you should try gradually increasing the compaction ratio as long as the compaction times stay short. A good value for the compact ratio is usually between 1 and 20, sometimes even higher. If the problem persists even though you set the compaction ratio to 1, you can try changing the compact set limit.
Setting the compaction ratio too low may increase the fragmentation and the amount of “dark matter”, which is free space that is too small to be used for object allocation. You can see the amount of dark matter in JRA recordings.
The compact set limit prevents sets a limit for how many references there can be to objects within the compaction area. If the number of references exceeds this limit, the compaction is canceled. The compact set limit is set using the following option:
You can tune the compact set limit if the garbage collection pauses are too long due to compaction. As a start, you can try setting the compact set limit as low as 10.000. If the problem is solved you should try gradually increasing the compact set limit as long as the compaction times stay low. A normal value for the compact set limit is usually between 100.000 and several million, while lower values are used when the pause time limits are very low.
Setting the compact set limit too low may stop compaction from being done altogether, which you can see in the verbose logs or in a JRA recording, where all compactions are noted as “aborted”. Running without any compaction at all may lead to increasing fragmentation, which will in the end force the JVM to perform a full compaction of the whole heap at once, which may take several seconds. Thus we recommend that you do not decrease the compact set limit unless you really have to.
| Note: | -XXcompactSetLimit has no effect when -XgcPrio:deterministic or -XgcPrio:pausetime is used. For these garbage collection modes you should not tune the compaction manually, but instead use the -XpauseTarget option to tune the garbage collection pauses. |
For in-depth information on how to tune compaction, see Tuning the Compaction of Memory.
The thread local area (TLA) is a chunk of free space reserved on the heap or the nursery and given to a thread for its exclusive use. A thread can allocate small objects in its own TLA without synchronizing with other threads. When the TLA gets full the thread simply requests a new TLA. The objects allocated in a TLA are accessible to all Java threads and are not considered “thread local” in any way after they have been allocated.
Increasing the TLA size is beneficial for multi threaded applications where each thread allocates a lot of objects. Increasing the TLA size is also beneficial when the average size of the allocated objects is large, as this allows larger objects to be allocated in the TLAs. Increasing the TLA size too much may however cause more fragmentation and more frequent garbage collections. To assess the sizes of the objects allocated by your application you can do a JRA recording and view object allocation statistics in the Java Runtime Analyzer. See Using Oracle JRockit Mission Control Tools for more information on JRA.
The TLA size is set using the following option:
The “min” value is the minimum TLA size, while the “preferred” value is a preferred size. This means that TLAs will be of the “preferred” size whenever possible, but may be as small as the “min” size. Typically the preferred TLA size can be up to twice the size of the largest commonly used object size in the application. Adjusting the min size may have an effect on garbage collection performance, but is seldom necessary. A normal value for the min size is 2 KB.
For in-depth information about tuning the TLA size, see Optimizing Memory Allocation Performance.
Further information on tuning the JRockit JVM can be found in Tuning the Memory Management System and Tuning Locks.
This section lists some best practices for tuning the JRockit JVM for a number of specific applications and application types.
Oracle WebLogic Server is an application server, and as such it requires high application throughput. An application server is often set up in a controlled environment on a dedicated machine. Try the following when tuning the JRockit JVM for Oracle WebLogic Server:
Oracle WebLogic SIP Server is an application server specialized for the communications industry. Typically it requires fairly low latencies and is run in a controlled environment on a dedicated machine. Try the following when tuning the JRockit JVM for Oracle WebLogic SIP Server:
-Xms) to the same value as the maximum heap size (-Xmx).-XgcPrio:pausetime, or the static generational concurrent garbage collector, -Xgc:gencon.Oracle WebLogic Event Server is an application server for applications based on an event-driven architecture. Typically it requires very low latencies and is run in a controlled environment on a dedicated machine. Try the following settings when tuning the JRockit JVM for Oracle WebLogic Event Server:
-Xms) to the same value as the maximum heap size (-Xmx).-XgcPrio:deterministic. The deterministic garbage collection mode is only available as a part of JRockit Real Time. Oracle Workshop consists of several Eclipse plug-ins. Eclipse requires fast response times and is typically run on a workstation together with many other applications. Try the following settings when tuning the JRockit JVM for Eclipse together with Oracle Workshop.
-Xms) lower than the maximum heap size (-Xmx) to allow the JVM to resize the heap when necessary.-XgcPrio:pausetime, or the default garbage collection mode, -XgcPrio:throughput.Java utility applications that run for a short time and have a simple and specific purpose, for example javac, require a fast startup and often don’t need a lot of memory. To tune the JRockit JVM for this kind of applications, try the following recommendations:
Data processing applications that process large batches of data, for example applications for XML processing or data mining, require maximum application throughput but are seldom sensitive to long latencies. To tune the Oracle JRockit JVM for this kind of applications, try the following recommendations:
-Xms) to the same value as the maximum heap size (-Xmx).-XgcPrio:throughput.
|