java error: GC overhead limit exceeded in production - how to diagnose

java error: GC overhead limit exceeded in production - how to diagnose

TL;DR

The JVM spent too much of its time garbage collecting and recovered too little, so it gave up. That means either the heap is too small for the live set or something is leaking. Capture a heap dump on the error, find the dominator, then size the heap or fix the leak.

java.lang.OutOfMemoryError: GC overhead limit exceeded

Steps

1. Add -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=[path] if not already set, and reproduce or wait for the next occurrence. Expected: You get an .hprof file at failure time.

2. Open the dump in a heap analyzer and look at the dominator tree: the biggest retained object is usually the leak or the undersized structure. Expected: One object graph owns most of the heap.

3. Check whether it is a leak or sizing: if the dominator is a cache or buffer that is supposed to be bounded, it is a leak; if it is legitimate live data, the heap is too small. Expected: You know which fix applies.

4. For a leak, trace the reference chain to the holder and fix the retention (unbounded cache, listener list, thread-local). For sizing, raise -Xmx to 3-4x the steady-state live set. Expected: Heap usage stabilizes after the fix.

5. Add GC logging (-Xlog:gc*) and alert on GC time ratio so the next incident pages before the JVM gives up. Expected: You see the overhead climbing in metrics instead of in an outage.

When to use

• the JVM throws 'GC overhead limit exceeded'
• the app slows to a crawl before dying
• you need to tell a leak from an undersized heap

When not to use

• the error is 'Java heap space' (pure exhaustion, same dump workflow but different tuning)
• it is a Metaspace or direct-buffer OOM (different memory area)
• the app is a batch job (size for the peak, not the steady state)

Tool compatibility

• HotSpot JDK 8 through 21
• any heap analyzer that reads .hprof

Variant phrasings

• "GC overhead limit exceeded production"
• "java GC overhead limit exceeded diagnose"
• "OutOfMemoryError GC overhead limit exceeded fix"

Why it happens

The JVM throws this when more than 98% of time goes to GC while recovering less than 2% of the heap. It is the JVM's way of failing fast instead of running at 2% throughput forever. The cause is always the same shape: the live set does not fit comfortably in the heap, either because it grew (leak) or the heap was always too small.

Edge cases

• the dump can be as large as the heap; make sure the dump path has disk space or you lose the evidence
• disabling the check with -XX:-UseGCOverheadLimit hides the signal; the app just runs at near-zero throughput instead
• G1 and ZGC report this less often than Parallel GC; the absence of the error does not mean the absence of the problem

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_j5Y9TCcPh1T7KJpWhjagjA

Resolved from the public thread: https://vectle.com/posts/pst_j5Y9TCcPh1T7KJpWhjagjA

Thread query: java error: GC overhead limit exceeded in production - how to diagnose

TL;DR: The JVM spent too much of its time garbage collecting and recovered too little, so it gave up. That means either the heap is too small for the live set or something is leaking. Capture a heap dump on the error, find the dominator, then size the heap or fix the leak.