BPM is supported on various JVMs. The choice of JVM has an impact on performance. The general rule of thumb for BPM is to use HotSpot in preference to other JVMs. For SPARC, we have found that most applications will get better performance with HotSpot. Use the latest stable release of the JVM that is available. Use the same JVM and the same version of that JVM in all environments. The second main consideration, if running on a 64-bit platform, is whether to use a 32-bit or 64-bit JVM. The general recommendation is to use a 64-bit JVM unless there is some good reason not to. 64-bit JVMs do consume more memory than 32-bit JVMs, in part because they use twice as much memory to store each reference. If this is an issue, consider using the UseCompressedOops (or equivalent) JVM setting, which will cause the 64-bit JVM to use less memory for references.
It is reasonable to expect the use of UseCompressedOops to reduce memory usage by something in the order of 10%.
As a general rule of thumb, use a 64-bit processor architecture and operating system in preference to a 32-bit environment.
Some applications can benefit from having a larger number of smaller JVMs. If an application fits into that category, and it does not need to keep as much data in memory in any one JVM, consider using a number of 32-bit JVMs.
Because of the large amount of variation in applications built using BPM, it is not possible to give a recommendation that will work for every case. It is important to test each application and tune the JVM. This should be an iterative process to find the best configuration for the specific environment and workload.
When tuning your JVM(s) consider sizing of the heap and permanent generation (in HotSpot) as well as the garbage collection algorithm selection and configuration. Remember that the heap is not the only memory that is used by the JVM.
Recommended Settings
There are some basic JVM settings that are recommended in most cases. Consider using these settings in all of your environments. The table below summarizes the recommended settings, which are discussed in the following section.
Start with a small set of options which are as simple as possible, for example just Xms, Xmx and possibly the garbage collection algorithm. This will allow the JVM to make decisions about its behavior. Add additional settings only if there is a problem seen in the collected JVM statistics. In the table below, ‘recommended’ indicates settings the settings that are often found to be in use after this process of tuning.
42 RECOMMENDED JVM SETTINGS
HOTSPOT JROCKIT PURPOSE
-XX:PrintGCTimeStamps -XX:PrintGCDetails -Xloggc:filename.log -XX:PrintGCTimeStamps -XX:PrintGCDetails -Xloggc:filename.log
(Recommended) Enable verbose garbage collection logging in production. Logs will be written in to the file named in the –Xloggc setting.
-XX:+HeapDumpOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError (Recommended) request that the JVM dump the heap if an
OutOfMemoryException occurs.
-server n/a (Recommended) Tell the JVM to run
in ‘server’ mode.
-Xms -Xmx
-Xms -Xmx
(Recommended) Set the initial and maximum heap size. Generally set them the same to avoid the overhead of heap size adjustment.
-XX:PermSize -XX:MaxPermSize
n/a (Recommended) Set the initial and
maximum size of the permanent generation. Generally set them the same to avoid the overhead of permanent generation size adjustment.
-XX:+UseCompressedOops (default in JDK 1.6.0_23+)
-XXcompressedRefs (Optional) Tell a 64-bit JVM to use
less memory for references.
-XX:+UseParallelOldGC -XgcPrio:throughput (Optional) Tells the JVM to optimize
the garbage collection for best throughput – will run until the heap is nearly full, and then stop all threads to garbage collect. The alternative is to optimize for latency.
n/a -XXtlaSize:min=1k,preferred=512k (Optional) Thread local allocation size.
-XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC
-XgcPrio:pausetime or
-XgcPrio:deterministic
(Optional) If you are running ADF applications – like Human Task user interfaces on the same managed server as BPM, you should consider using the Concurrent Garbage Collection algorithm. This has been
RECOMMENDED JVM SETTINGS
HOTSPOT JROCKIT PURPOSE
shown to give better performance in this particular scenario.
Garbage collection logging is very useful when attempting to tune a JVM. The overhead of collecting this information is very low. Turn on garbage collection logging in all environments including production. If there is a need to do some performance tuning, it is helpful to have to have actual garbage collection data from the production environment. Leaving garbage collection logging on all the time will mean that the data will be available if it is ever needed. If a problem occurs, it will not be necessary to attempt to reproduce it in order to capture garbage collection data, and there are tools that will parse the garbage collection log data to produce information about the garbage collection behavior during the test.
Similarly, if there is an outage due to insufficient memory, it is extremely helpful to know what was happening when memory was exhausted. Use the settings in the table for the relevant JVM to collect and save information to help investigate the cause of memory exhaustion outages.
If using the HotSpot JVM, explicitly tell it to run in ‘server’ mode on 64-bit machines. This setting will enable various optimizations that will improve performance on modern 64-bit multicore processor architectures.
In large JVMs (those with more than 2GB heap is a good rule of thumb) working out if the heap needs to be resized and resizing it when necessary can consume a lot of resources. Generally the initial and maximum heap size should be set the same to avoid this additional overhead. This is also appropriate for heap sizes under 2GB, but is of reduced value in those environments compared to environments with larger heaps.
Similarly, in the HotSpot JVM set the initial and maximum size of the permanent generation the same for much the same reason.
If running in a 64-bit environment and the heap is approaching the size of the available memory, enable compressed references to reduce the amount of memory consumed by the JVM. This setting is listed as optional as it may or may not have a positive impact on performance depending on your application. However, it will reduce the memory footprint. If this is a consideration in the
environment, conduct some testing to analyze the impact of using this option. Note that JRockit will use compressed references by default in some circumstances.
Note that UseCompressedOops is supported and enabled by default in Java SE 6u23 and later. In Java SE 7, UseCompressedOops is the default for 64-bit JVM processes when Xmx isn't specified or is less than 32GB. For JDK 6 before the 6u23 release, use the -XX:+UseCompressedOops flag to enable the feature.
44
Garbage Collection Algorithm
The recommended garbage collection setting for SOA/BPM is UseParallelOldGC which will cause the JVM to use the Parallel Scavenger collector in the young generation and the Parallel Old collector in the tenured generation.
If running ADF applications (human task user interfaces) on the same managed server as BPM is running on, use the concurrent garbage collector (UseConcMarkSweepGC).
A new garbage collector, known as G1, has been introduced in JDK 7. Not enough testing has been done with this new garbage collector in order to give a recommendation at the date of writing this paper.