IBM Support

Excessive Heap Compaction Causes Performance Overhead

Question & Answer


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:
    • IBM Monitoring and Diagnostic Tools - Garbage Collection and Memory Visualizer (GCMV) https://marketplace.eclipse.org/content/ibm-monitoring-and-diagnostic-tools-garbage-collection-and-memory-visualizer-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 after garbage 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 its own unique memory configuration tailored to the type of work the applications do and the lifetime of the objects it will hold.

[{"Type":"MASTER","Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"ARM Category":[{"code":"a8m50000000CdFIAA0","label":"WebSphere Application Server traditional-All Platforms-\u003EPerformance"}],"ARM Case Number":"","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"},{"code":"PF035","label":"z\/OS"}],"Version":"All Versions"}]

Document Information

Modified date:
31 March 2022

UID

swg21608319