Short answer
Out of memory means the Java heap ran out, not that your computer is slow. Give the server a heap it can actually use: leave 1 to 1.5 GB of your RAM for the OS, set -Xmx to what is left, and find what is holding memory, because a server that leaks reaches that ceiling again in a day.
The exception reads like a hardware problem and behaves like a software one. A Minecraft server with plenty of RAM can still throw OutOfMemoryError if the JVM was never told it may use it, and a server with 3 GB can run for months if nothing is leaking. The number on the crash screen is the heap size, not the memory your machine has.
This guide covers the two separate jobs: sizing the heap so it fits, and finding the thing that grows until it does not fit. Do the first before the second, because a heap that is too small makes every measurement misleading.
Before you start
- Access to the server start command or the memory setting in your panel
- The crash report from a recent OutOfMemoryError
- About an hour for the full process
1. Size the heap to the RAM you actually have
-Xmx is the maximum memory the JVM may use, and it is set when the server starts. On a shared host it does not default to all your memory, so check it. Paper recommends leaving roughly 1000 to 1500 MB on top of -Xmx for the OS and the JVM itself: 8 GB of RAM means about 6500 MB for -Xmx, not 8 GB.
Set -Xms equal to -Xmx so the JVM never has to resize at runtime, and restart. You should see the size in the startup line that prints the JVM arguments.
On PufferHost the memory is allocated for you and shown on the server page; the heap is set by the platform, so on the free tier you do not need to touch this at all.
java -Xms6G -Xmx6G -XX:+UseG1GC -jar paper.jar --nogui2. Turn on GC logging before the next crash
The exception tells you the heap ran out but not what filled it. Java can log every garbage collection with timestamps, and those logs show memory climbing steadily rather than spiking. Enable logging before the next crash, not after: the interesting line is the one from an hour before the failure.
Java 11 and later use one flag; Java 8 to 10 use the older set. Copy the line that matches your Java version into the start command, restart, and let it run.
-Xlog:gc*:logs/gc.log:time,uptime:filecount=5,filesize=1M-Xloggc:gc.log -verbose:gc -XX:+PrintGCDetails -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=1M- A line every few seconds with the heap near full is normal operation under load.
- Lines every second, with the heap barely dropping, is a leak: something holds references and garbage collection cannot reclaim it.
3. Find what is holding the memory
Three things account for nearly all of it on a small server. Chunks stay loaded around players and explorers, so a busy world uses memory that scales with how much of it is active. Plugins keep caches, tasks and worlds of their own; a dozen plugins can outweigh the vanilla server. And the world grows: every new chunk explored, every player inventory and container adds to what has to be held.
Check each in turn. Watch the memory graph while the server is empty: it should fall back to a baseline after players leave and the chunks unload. A baseline that climbs over days, restarts aside, is the leak. Restart, note the baseline, play a normal session, and compare.
/spark heap
/paper chunkinfo
/plugins4. Give the heap room to work and cap what you can
Once the heap is correctly sized and you know what is in it, two settings help. Aikar's flags, which Paper documents, tune the G1 garbage collector for Minecraft's access pattern and are what Paper's own start script uses. Copy them from the Paper documentation rather than a forum post.
Then cap the world. Pre-generating the map with a plugin such as Chunky means chunks are created once, offline, instead of on a player's first walk. Setting simulation-distance and view-distance lower stops the server from holding chunks in memory it does not need, and setting a world border stops players walking new chunks into existence.
java -Xms6G -Xmx6G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
-XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=30 \
-XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 \
-XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 \
-XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 \
-XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 \
-XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 \
-Dusing.aikars.flags=https://mcflags.emc.gs -Daikars.new.flags=true \
-jar paper.jar --noguiview-distance=6
simulation-distance=65. Restart and watch the baseline
Restart with the new flags and let the server run through its usual week. If the crash was a leak, the baseline after a day will be higher than the baseline after the restart, and the graph will show where it climbs.
If it still crashes with plenty of headroom in the log, the memory is being held somewhere the graph cannot see, and the next step is a heap dump taken while the server is under pressure and read with a tool such as Eclipse MAT. That is a last resort, not a first step.
Good to know
- Paper's own guidance is 6 to 10 GB of memory for a server no matter how few players it has. A 3 GB server is enough for a small world with a handful of plugins, and both numbers can be true at once.
- GC stutter and out-of-memory feel different. Stutter is a freeze every few seconds as the collector works; out-of-memory is a crash with the exception in the report. The lag guide covers the first.
- A single OOM crash right after an upgrade is usually the JVM flags changed, not a leak. Compare the start command before and after the update.
Common questions
How much RAM does a Minecraft server need?
A small vanilla world runs in about 2 GB. Paper with a modest plugin set wants 4 to 6 GB, and Paper recommends at least 6 to 10 GB whatever the player count. The free tier's 3 GB is fine for a small world and a short plugin list, and not fine for a large one. The RAM calculator sizes it for your setup.
Does the OutOfMemoryError message tell me which plugin leaked?
No. It tells you the heap is exhausted, not what exhausted it. /spark heap after a restart and /spark profiler under load show what is on the heap and what is using it, which is how you find the plugin.
Why did my server run out of memory after months without issue?
Something changed: a plugin update, a bigger explored area, more players, or a leak that grew slowly past the ceiling. Compare the memory graph against the date of the last change; the answer is usually in that comparison.
Can I just give it more memory and stop looking?
Sometimes. If the graph shows a flat line at the ceiling with no leak, the heap was simply too small and a bigger one fixes it. If the line climbs every day, more memory only delays the crash, and you still need to find what is holding it.
Sources
Official documentation this guide was checked against.
Rather not run this on your own machine? PufferHost gives every player a free Minecraft server with 3 GB of RAM and 10 slots. Create a free server.