Excessive Heap Compaction Causes Performance Overhead

Technote (FAQ)


Question

How can I avoid performance overhead caused by heap compaction?

Cause

The JVM has a very flexible heap configuration which makes it adaptable to many different application environments. By setting the starting size of the heap (-Xms) and the maximum size of the heap (-Xmx) to different values, the JVM can dynamically adapt for an application's memory requirements. However, this flexibility can sometimes contribute to performance overhead. Specifically, when the application memory needs oscillate and the JVM must continuously manage the shrinking and the growing of the heap.

Answer

To diagnose this issue:

  1. Enable verbose GC:
  2. Reproduce the issue and collect the verbose GC output.
  3. Use the "Garbage Collection Memory Visualizer" (GCMV) tool in ISA (or stand-alone) to diagnose the issue:
    • developerWorks : IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer
      http://www.ibm.com/developerworks/java/jdk/tools/gcmv/
    • GCMV will provide "Tuning Recommendations" in the output which you may see:
      • "The garbage collector seems to be compacting excessively, compaction is an expensive operation and leads to long pause times. ... If compaction is occurring when the heap is resized consider fixing the heap size by setting -Xmx and -Xms to the same value as this will prevent the heap being resized automatically leading to more predictable pause times..."
  4. To further determine if compaction is an issue, look at the verbose GC data for messages such as this
    <compaction movecount="13105620" movebytes="660257992" reason="compact to aid heap contraction" />

      Only when these messages are in excess would this indicate that the performance issue is likely related to heap compaction.

To Remedy:

If excessive heap resizing is causing performance overhead set the heap to a fixed size by setting the minimum (-Xms) and maximum (-Xmx) heap sizes to the same value. While there is no "one-size-fits-all" configuration for heap sizing, a good starting place is to determine the maximum amount of heap the application requires and add 30%.

To determine the maximum amount of heap space an application requires, enable verbose GC, run the application over a period of time that includes the application's highest expected volume and then check the values for the largest amount of used heap aftergarbage collection. Add 30% to that value and monitor.

To set the -Xms and -Xmx See:

Summary:
Each JVM configuration needs to be taken into careful consideration of the application requirements. WebSphere Application Server has no limit to the types of applications it can run. Therefore, each serving environment will require it's own unique memory configuration tailored to the type of work the applications do and the lifetime of the objects it will hold.

Java Performance on POWER7 - Best Practice
http://public.dhe.ibm.com/common/ssi/ecm/en/pow03066usen/POW03066USEN.PDF

Tuning WebSphere Application Server - JVM heap size
http://www.ibm.com/developerworks/websphere/techjournal/0909_blythe/0909_blythe.html#sec3a

Related information

Java Performance on Power7 - Best Practice
Generational Concurrent Garbage Collector
Compaction Phase
Tuning WebSphere Application Server - Java Heap Size

Rate this page:

(0 users)Average rating

Document information


More support for:

WebSphere Application Server
Hangs/Performance Degradation

Software version:

6.1, 7.0, 8.0, 8.5

Operating system(s):

AIX, HP-UX, Linux, Solaris, Windows, z/OS

Reference #:

1608319

Modified date:

2013-05-19

Translate my page

Machine Translation

Content navigation