Java continuous GC, ParOldGen exhausted

Question

We have a large Java app running on Google Cloud Managed VMs (which limits our ability to control the JVM tuning parameters I think).

We have many millions of objects (some 15GB) in RAM.

While doing a task which may involve creating tens of thousands more objects (parsing a huge Excel) the system freezes for many minutes probably due to Garbage Collection.

We noticed that overall we are not low on RAM but ParOldGen seems 99% used. Any suggestions how to avoid this please?

Heap
 PSYoungGen      total 6083072K, used 267497K [0x000000064eb00000, 0x0000000800000000, 0x0000000800000000)
  eden space 6078464K, 4% used [0x000000064eb00000,0x000000065f03a438,0x00000007c1b00000)
  from space 4608K, 0% used [0x00000007c1b00000,0x00000007c1b00000,0x00000007c1f80000)
  to   space 528384K, 0% used [0x00000007dfc00000,0x00000007dfc00000,0x0000000800000000)
 ParOldGen       total 14198272K, used 14197939K [0x00000002ec180000, 0x000000064eb00000, 0x000000064eb00000)
  object space 14198272K, 99% used [0x00000002ec180000,0x000000064eaacc60,0x000000064eb00000)
 PSPermGen       total 65536K, used 50669K [0x00000002e1b80000, 0x00000002e5b80000, 0x00000002ec180000)
  object space 65536K, 77% used [0x00000002e1b80000,0x00000002e4cfb640,0x00000002e5b80000)

Answer 1

As described in this article on Java GC, ParOldGen (or Concurrent Old Gen (Mark Sweep) GC) can take a long time during its "stop the world" phase when dealing with lots of fragmentation in memory, something that you'd expect to see in such an object-heavy pattern. Perhaps this is worth reading as an explanation of what's happening?

As to increasing the heap size, this can be done with JVM options, which can be manipulated when using Custom Runtimes / Flexible Environment apps. You can also configure the amount of memory each instance will have.

Finally, you can also select which GC algorithms should run using JVM options. You might find the app performs better without ParOldGen at all.