Sunday, July 1, 2012

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.

No comments:

Post a Comment