java.lang.OutOfMemoryError: GC overhead limit exceeded
This error means the JVM spent over 98% of its time in garbage collection while recovering less than 2% of the heap. The server usually feels awful before it dies — TPS crawls, then the error lands. It is a memory-pressure signature: the heap is slightly too small for the live workload, or something is leaking.
Fastest path: paste your crash report into the Crash Doctor — it identifies this pattern and 40+ others automatically. No signup.
How to fix it
- 1
Raise the heap if the host allows
If -Xmx sits below the plan's RAM (minus OS headroom), raise it. Many 'lag then die' cases are simply a 4 GB heap on a 6 GB plan that was never raised.
- 2
Use G1GC with tuned flags
Aikar-style G1GC flags reduce both pause times and the odds of triggering the overhead limiter on modded servers. Defaults from years ago (or ParallelGC) handle modern packs poorly.
- 3
Reduce the live set
Lower view-distance and simulation-distance, cap mob farms, and pre-generate chunks so exploration doesn't spike allocation.
- 4
Profile for a leak
If raising the heap only delays the crash, something leaks. Install spark, run a 10-minute profile under normal load, and look for a mod whose allocations never release.
- 5
Schedule restarts as a stopgap
A daily quiet-hours restart resets the leak clock while you hunt the cause. It is a mitigation, not a fix.
Alternative causes
These can produce the same error message — worth ruling out if the steps above don't resolve it.
Heap sized for the old pack version
Pack updates grow. A heap that fit version 1.0 can start GC-thrashing after the 1.2 update added two dimensions' worth of content.
Too many entities in one place
A runaway mob farm holds enormous live object graphs. The GC keeps working but never reclaims enough — same error, different root cause.
Frequently asked
How is this different from a normal OutOfMemoryError?
Plain OOM means allocation truly failed. Overhead-limit means the JVM predicted failure — it was GC-thrashing and chose to die cleanly before that.
Can flags alone fix it?
If the workload fits in the heap with efficient GC, yes. If the live set genuinely exceeds the heap, no flag combination saves it.
Why did it start after a pack update?
Updates add content, mobs and dimensions — the live set grows. Re-check heap sizing after every major pack version bump.
Want this auto-fixed on your server?
CoalHosting's Minecraft hosting runs the same pattern database against every crash and applies the known fix before your players notice. Free crash diagnosis works on any server, hosted or not.
Related crashes
java.lang.OutOfMemoryError: Java heap space
Fix Minecraft server OutOfMemoryError crashes — the JVM ran out of allocated heap. Most modpacks need 8–16 GB;…
Server exited with code 137 (SIGKILL / OOM)
Exit code 137 means the OS killed the Java process — almost always host-level out-of-memory pressure, not a Mi…
Watchdog tick timeout (single server tick took)
Fix Minecraft server watchdog crashes — a tick took longer than 60s and the server killed itself. Usually a he…
Last reviewed 2026-09-06. If a step is wrong or out of date, tell us — we'll fix the article and the auto-pattern at the same time.