Minecraft Server Out of Memory Error — What It Means and How to Fix It
java.lang.OutOfMemoryError isn't one error — it's a family of six, and only some of them mean "buy more RAM." Here's what each variant actually says about your server, and how to tell a real memory leak from a server that's simply undersized.
Read the exact second line before you do anything
Open logs/latest.log and find java.lang.OutOfMemoryError. The word right after the colon — Java heap space, Metaspace, Direct buffer memory, unable to create new native thread — tells you which memory pool actually filled up, and that changes the fix completely.
No Java error at all and the process just vanished? Skip to variant 6 — that's the OS, not the JVM.
java.lang.OutOfMemoryError: Java heap space
The most common one. Server slows down over minutes or hours, TPS drops, then it locks up and the log ends with this exact line followed by a huge stack trace.
The JVM heap (controlled by -Xmx) filled up completely and garbage collection couldn't free enough space to continue. Either the heap is too small for what the server is holding, or something is leaking memory that garbage collection can never reclaim.
Check your current -Xmx first — in the start command or panel's Java args field. Sizing floor: 4 GB for vanilla survival, 6-8 GB for Paper with a plugin stack, 10-16 GB for heavy modpacks (ATM-class). If you're already at the right size and still OOM-ing, it's a leak, not a sizing problem — see the diagnosis section below before adding more RAM.
java.lang.OutOfMemoryError: GC overhead limit exceeded
Same crash, different second line. The JVM spent more than 98% of recent CPU time on garbage collection and recovered less than 2% of the heap — so it gives up rather than hang forever doing GC.
This is heap exhaustion in slow motion. Something is allocating objects faster than they can be freed — a near-leak, not a hard leak. Common on servers that look "fine" for hours, then suddenly spiral.
Same root cause as heap space errors, just caught earlier by the JVM's safety valve. Profile with Spark (`/spark profiler --timeout 120`) during a period when TPS is dropping, not after the crash — post-crash profiles show nothing. Look at the GC log if you have `-Xlog:gc` enabled; frequent full GCs with small recovered space is the signature.
java.lang.OutOfMemoryError: Metaspace
Crash references "Metaspace" specifically, not heap. Often happens after the server has been running a long time, or after a `/reload` command.
Metaspace stores class metadata, not objects. It grows when classes are loaded and never grow back down when they should be unloaded — classic cause is plugin or datapack reloading without a full JVM restart, which loads duplicate class definitions each time.
Stop using `/reload`. It is explicitly unsupported by Paper/Spigot for exactly this reason — it reloads plugins without properly unloading their classes. Restart the whole server process instead. If Metaspace OOMs happen without any reloads, add `-XX:MaxMetaspaceSize=512m` explicitly and watch whether it's hit quickly (points to a plugin generating classes dynamically, e.g. some scripting plugins).
java.lang.OutOfMemoryError: unable to create new native thread
Crash names threads, not heap or metaspace. Usually paired with the OS showing very high thread counts for the java process right before the crash.
This is an operating-system limit, not a JVM heap limit — the process hit the OS's max-threads-per-process or the host's memory is so full that the OS can't allocate stack space for a new thread (each thread needs ~1 MB of native stack by default).
Almost always a plugin or mod leaking threads — creating a new thread per event instead of reusing a thread pool. Check `jstack <pid>` output (or ask your host to) and count threads with the same name prefix; hundreds of `Thread-1047`, `Thread-1048`... style names point straight at the offending plugin. Short-term: restart. Long-term: update or remove that plugin.
java.lang.OutOfMemoryError: Direct buffer memory
References "Direct buffer memory" specifically — distinct from heap. Common on servers with a lot of network traffic (big player counts, or a proxy like Velocity in front).
Netty (Minecraft's networking library) allocates direct (off-heap) buffers for packet I/O. This pool has its own limit, separate from -Xmx, and can fill up under heavy concurrent connections or packet floods.
Add `-XX:MaxDirectMemorySize=512m` (or higher) explicitly as a JVM flag — by default it's capped to the same size as -Xmx, which is often too small for the direct buffer pool specifically. If this happens during a sudden player spike, it may also be a sign of a connection flood; check for bot/crawler traffic hitting your server's port.
Server gets killed with no Java OOM message at all (exit code 137)
No `OutOfMemoryError` in the log at all — the process just vanishes. The log simply stops.
This is **not a Java OOM** — it's the operating system's OOM killer (or a container's cgroup limit) killing the whole JVM process from outside, because total memory use (heap + metaspace + direct buffers + thread stacks + OS overhead) exceeded what the host allows. The JVM never gets a chance to log anything.
Lower `-Xmx` to roughly 75-90% of your plan's total RAM, not 100% — the JVM needs headroom beyond the heap for metaspace, thread stacks, and native overhead. A 16 GB plan should run `-Xmx13G` to `-Xmx14G`, not `-Xmx16G`. If you're already well under your plan's RAM and still see silent kills, the host's memory accounting may be wrong — ask support to confirm the container limit matches the advertised plan size.
The 90% rule, in one sentence
Whatever RAM your hosting plan advertises, set -Xmx to about 75-90% of it, never 100%. The gap covers metaspace, thread stacks, direct buffers, and OS overhead — all memory the JVM uses that doesn't count toward the heap limit you set, but still counts toward your plan's hard ceiling. Running -Xmx at 100% of plan RAM is the single most common cause of silent exit-code-137 crashes.
This matters most on the packs that actually need the headroom — All the Mods 10 and RLCraft are the two packs most often reported OOM-ing on undersized plans.
FAQ
How much RAM does my Minecraft server actually need?+
Vanilla survival: 2-4 GB. Paper/Spigot with a moderate plugin list: 4-6 GB. Paper with a heavy plugin stack or Dynmap: 6-8 GB. Light modpacks (SkyFactory, Create): 6-8 GB. Heavy modpacks (All the Mods, RLCraft-class): 10-16 GB. These are JVM heap sizes (-Xmx) — your hosting plan should have 10-20% more total RAM than the heap you set.
Does giving a Minecraft server more RAM than it needs help?+
No, and it can actively hurt. A heap that's much larger than what the server actually uses means garbage collection has to scan a bigger space when it does run, which can mean longer (if less frequent) GC pauses. Size -Xmx to match real usage, measured with /spark heap, not to the maximum your plan allows.
What's the difference between OutOfMemoryError and exit code 137?+
OutOfMemoryError is the JVM itself reporting that its heap, metaspace, or another internal memory pool is full — it has time to log a stack trace before dying. Exit code 137 means the operating system (or a container's memory cgroup) killed the process from outside before the JVM could log anything, because total memory use exceeded the host's limit. The fix for 137 is the same — lower -Xmx — but you won't see a Java error for it.
How do I find a memory leak on a Minecraft server instead of just adding RAM?+
Install the Spark plugin (or mod) and run /spark heap during normal play, well before the server is close to crashing. It produces a heap dump summary ranked by retained size — the top entries after a few hours of play, compared against a fresh restart, point at what's accumulating. Common leaks: Dynmap tile caching, old item-frame/map-item storage, entity count creep from unculled mob farms, and plugins that cache per-player data without clearing it on logout.
Why does my server OOM only after running for several days?+
Classic slow leak signature. Something accumulates a small amount of unreclaimable memory per event — per chunk load, per player join, per tick — and it only becomes visible once enough events have happened. Compare /spark heap output taken a few hours after restart against the same command taken just before the next crash; whatever grew the most between the two snapshots is the leak.
Correctly-sized RAM from the start
CoalHost caps -Xmx automatically to leave the right headroom for your plan, and our crash agent reads OutOfMemoryError traces to tell you heap vs. leak before you even ask. From €10.69/month.
View Minecraft Hosting →