0

We migrated our application from CMS to G1GC and post that the heap monitoring system is triggering high heap usage alerts. Max heap usage is over 80% of total heap and is almost double of what we used to get with CMS. The memory graph is in zig-zag pattern with high and low usage.

Going through the GC log we noticed that in-order to reduce the frequency of GC cycle, G1GC is allocating around 50% of heap to Eden space. Majority of objects in Eden are temporary objects which get cleared on next GC. Since G1GC delays the GC cycle, major portion of reported high heap consists of temporary objects.

The monitoring system basically captures the Memory_HeapMemoryUsage MBean to get the memory snapshot. But with the way G1GC works, this data is misleading. We can change the way monitoring system captures the data but then it will become G1GC specific?

Is there any better approach which is independent of GC implementation?

vjmehta
  • 9
  • 1
  • 2
    `We can change the way monitoring system captures the data but then it will become G1GC specific` - well your current approach is obviously CMS specific, so what's the issue with having G1GC specific approach ? – Svetlin Zarev May 10 '19 at 14:06
  • Our current approach (capturing Memory_HeapMemoryUsage MXbean) is standard and generic which works fine for G1GC predecessors. – vjmehta May 10 '19 at 14:18
  • Note that the sawtooth pattern is normal for all Java GCs. The stats you are getting are not misleading. What is going on here is that the GC is behaving differently; e.g. G1 is scaling the memory spaces differently to CMS. You just need to get used to it. (And if you think too much memory is used, then reduce the max heap size.) – Stephen C May 10 '19 at 14:20
  • *"Is there any better approach which is independent of GC implementation?"* - Erm, no. The heap / memory usage patterns and the resulting usage stats are intrinsically dependent on the GC you use. – Stephen C May 10 '19 at 14:24

0 Answers0