How to Tuning JRockit ?

Tuning the Heap Size:

• 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.
• Should set the heap as large as the PHYSICAL memory in your system will allow, as long as it doesn’t cause paging.
• -Xms:, which sets the initial and minimum heap size.
• -Xmx:, which sets the maximum heap size.
• Set the initial/minimum heap size (-Xms) to the same value as the maximum heap size (-Xmx).

Tuning the Garbage Collection

• JRockit offers three garbage collection modes and a number of static garbage collection strategies. You can tune the garbage collection to suit your application’s needs.
• -XgcPrio:throughput: Defines that the garbage collection should be optimized for application throughput. This is the default garbage collection mode.
• -XgcPrio:pausetime : Defines that the garbage collection should be optimized for short garbage collection pauses.
• -XgcPrio:deterministic {Only with JRockit Real-Time}: Defines that GC should be optimized for very short and deterministic garbage collection pauses.

Tuning the Pause Target

• This parameter is used to tune JVMs which host ‘time critical applications’ (Ex: A banking application  that normally take 100 ms to complete and times out after 400 ms, cannot afford a GC pause time of 500ms)
• The pause time mode uses a pause target for optimizing the pause times; pause target should be as high as your application can tolerate
• This parameter is coupled and used with ‘-XgcPrio:pausetime’ (ex: java -XgcPrio:pausetime -XpauseTarget:300ms weblogic.Server); default ‘pauseTarget’ is not specified is 500ms

# Below given parameters should not be changes until you

feel a real need to tune your Weblogic server; incorrect

 tuning may lead to uneven performance degradation.

Tuning Compaction

• Whenever GC(old collection) runs it defragments the heap, making object allocation easier for the JVM this process is called heap compaction; compaction may lead to long pauses in GC because it takes up the CPU time to arrange and defragment the heap
• -XXcompactRatio:centage> : this specifies the percentage of heap which will be defragmented when GC runs;  a good value for the compact ratio is usually between 1 and 20; a too low value can also invite trouble as it slows down defragmentation and increases the amount of dark matter(“Dark matter” is wasted heap memory and fragments the heap)
• -XXcompactSetLimit:<references> : When compaction has moved objects, the references to these objects must be updated. JVM has to do this before threads have access to those memory references; this parameter defines how many references GC can compact within the compaction area (Ex: java -XXcompactSetLimit:20000 MyApplication)

Tuning the TLA (Thread Local Area)

• It is the chunk of memory reserved in the heap for a thread for its exclusive use.
• When this TLA gets filled up we see the ‘java.lang.OutOfMemoryError: nativeGetNewTLA’, to fix this we can tune the ‘-XXtlaSize:min=e>,preferred=’ parameter increase the TLA (Ex: -XXtlasize:min=8k,preferred=512k)
• Increasing the TLA size is beneficial for multi threaded applications; however increasing it too much may result in more fragmentation and more frequent garbage collections.