Tuning JRockit for Content Cortex components

To improve response time and CPU utilization consider tuning the following JVM switches.

Improving JRockit response times and CPU utilization

Start by using the values that are listed in the examples and then adjust them accordingly.

Table 1. JRockit JVM switches that help to improve response time and CPU utilization
JRockit JVM switch	Description
-XXtlaSize	Defines the size of thread local areas (TLAs), which are used for object allocation. The default value is 2 KB. Format: -XXltaSize:size[k\|K] [m\|M] [g\|G] For example: java -XXtlaSize:64k
-XXlargeObjectLimit	Defines the size of a large object. Objects that exceed the defined size limit are considered large and are not allocated in TLAs. Format: -XXlargeObjectLimit:size[k\|K] [m\|M] [g\|G For example: java -XXlargeObjectLimit:64k
-Xns	Defines the nursery size. Consider setting the JRockit nursery size to 25% of the total heap. Format: -Xns:size[k\|K] [m\|M] [g\|G For example: java -Xns:300m

Preventing JRockit Java™ Virtual Machine (JVM) out-of-memory errors

Under certain conditions, an application server can throw out-of-memory errors when the heap still had ample memory available. An example of these errors is the following message:

“Error starting thread: Not enough storage is available to process this command."

The cause of this message can be either improper sizing of the JRockit heap generations or memory fragmentation caused by system class placement in the heap, or both. Unlike the Java Hotspot and IBM® JVMs, JRockit does not have permanent system class heap space, which can cause fragmentation problems in certain scenarios.

To avoid this issue, consider setting your JRockit nursery size to 25% of the total heap. Depending upon the workload, this setting might require some additional adjustments. You can monitor the nursery size by using VerboseGC collection and analysis.