An out of memory (OOM) crash happens when your server process tries to use more RAM than is available. The operating system's OOM killer terminates the process to prevent the entire system from freezing. The result: your server vanishes without a clean shutdown, and players lose recent progress.
Symptoms of OOM crashes
- The server freezes for several seconds, then the process disappears.
- Server logs end abruptly with no shutdown message.
- You see "java.lang.OutOfMemoryError" in Minecraft server logs.
- The hosting panel shows the server as "Stopped" without you stopping it.
- The Linux system log (
dmesgor/var/log/kern.log) contains "Out of memory: Killed process."
Common causes
- Too many players or entities. Each player and loaded entity consumes RAM. Thousands of mobs, dropped items or armor stands add up quickly.
- Memory leaks in plugins or mods. Some plugins allocate memory but never release it. Over hours or days, usage climbs until the limit is hit. Dynmap, poorly coded economy plugins and certain world editors are known offenders.
- Insufficient allocated RAM. A server with 50 plugins and 20 players on 2 GB of RAM will struggle. The base game, plugins and the world cache all need their share.
- World too large. Every loaded chunk consumes memory. Servers without a world border let players explore endlessly, loading more and more chunks.
- No restart schedule. Even without leaks, Java garbage collection works better with periodic restarts. Servers running for weeks accumulate fragmented memory.
Step-by-step fixes
1. Confirm it is actually OOM
Check your server's logs/latest.log for "OutOfMemoryError." If you have SSH access, run dmesg | grep -i "out of memory" to see if the kernel killed the process. In the hosting panel, check if the RAM usage graph hit 100% right before the crash.
2. Increase allocated RAM
If your server genuinely needs more memory, upgrade. For Minecraft: 3 to 4 GB handles a vanilla server with 10 to 15 players. Add 1 GB per 10 heavy plugins. Modded servers (Forge/Fabric with 100+ mods) often need 6 to 10 GB.
3. Find and remove leaking plugins
Identify the culprit by monitoring RAM usage over time. If memory rises steadily and never drops back, a plugin is leaking. Remove plugins one at a time and observe. Common approach: start the server with no plugins, add them back in batches of five, and watch which batch causes the climb.
4. Set up a restart schedule
Restart your server every 6 to 12 hours. Most hosting panels let you schedule this. A restart clears all accumulated garbage, resets entity counts and gives Java a clean heap. Warn players with a plugin like AutoRestart that announces countdowns.
5. Use Aikar's JVM flags for Minecraft
Aikar's flags optimize Java's garbage collector for Minecraft. They pre-allocate memory, reduce GC pauses and handle large heaps efficiently. The key flags are -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 along with several others. Check the Paper documentation for the full set.
6. Limit world size
Set a world border with /worldborder set 10000 (5000 blocks in each direction from spawn). This prevents players from exploring indefinitely and loading an ever-growing number of chunks. For most servers, a 10,000-block diameter is more than enough.
7. Reduce loaded chunks
Lower view-distance in server.properties to 8 or 6. Each reduction saves significant RAM. In Paper's config, also reduce simulation-distance separately from view distance, so players see far but the server only ticks nearby chunks.
Upgrade when optimization is not enough
If you have optimized settings, removed leaking plugins, set a world border and the server still runs out of memory, you need a bigger plan. HostValues Minecraft hosting offers plans up to 32 GB of RAM, so your server has room to grow.
Does swap space help prevent OOM crashes?
Swap delays the crash but makes the server nearly unplayable. When the server starts using swap (disk instead of RAM), performance drops dramatically because disk access is thousands of times slower than RAM. It is better to allocate enough real RAM and let the OOM killer act quickly than to limp along on swap.
How do I find which plugin is leaking memory?
Monitor RAM usage over several hours with a monitoring plugin like Spark. If memory climbs continuously, start removing plugins one by one (or in small batches), restarting after each removal. When memory stabilizes after removing a plugin, you have found the offender. Spark's heap analysis can also point directly to which classes hold the most memory.
How can I tell if it was OOM or a different crash?
OOM crashes leave specific signatures. The log contains "OutOfMemoryError" or the system log shows the OOM killer. Other crashes produce stack traces with different exceptions (NullPointerException, ConcurrentModificationException) or plugin-specific errors. If the log just stops with no error at all, check dmesg for the kernel's OOM killer message.
Need more RAM? HostValues VPS plans scale from 2 GB to 64 GB with instant upgrades, no migration needed.
