What the memory is actually holding
A Minecraft server's heap is dominated by a few things, and player count is a surprisingly small one. Loaded chunks are usually the biggest single consumer: every chunk within view-distance of every player is held in memory with its blocks, block entities and lighting data. Entities come next — mobs, item frames, armour stands, dropped items and especially large farms. Then plugin or mod state: caches, region data, economy tables, world-edit clipboards. Players themselves cost relatively little; what costs is the world they drag into memory around them.
That ordering explains most confusing memory behaviour. A server with 8 players spread across four corners of the map can hold more chunks — and use more RAM — than one with 40 players standing in the same spawn city. It is also why lowering `view-distance` is the single most effective memory lever you have.
Starting points by server type
| Vanilla, up to 10 players | 2 GB heap — comfortable, rarely the constraint |
| Paper + normal plugin set, 20–40 players | 4 GB heap — the sweet spot for most public servers |
| Paper, 50–100 players, several worlds | 6–8 GB heap, with view-distance tuned down |
| Proxy network (Velocity/BungeeCord) | 512 MB–1 GB for the proxy itself; it holds no world data |
| Light modpack, 50–80 mods | 4–6 GB heap |
| Large modpack, 200+ mods | 8–12 GB heap, set by the pack rather than the players |
Treat these as starting points, not targets to grow into. The correct allocation is the smallest one where your server does not spend meaningful time in garbage collection — and you find that by measuring, not by rounding up to the next power of two.
Why over-allocating hurts
This is the part that surprises people. Java does not use memory the way a spreadsheet does; it fills the heap and then a garbage collector reclaims it. A bigger heap means a bigger region to scan, so while collections happen less often, each one takes longer. On a 16 GB heap that a server never needed, the result is a game that runs fine for three minutes and then hitches for half a second — the classic "random lag spike every few minutes" report that no amount of extra memory ever fixes.
The other cost is invisible until it is fatal. The heap you set with `-Xmx` is not the process's total footprint — the JVM also needs metaspace, thread stacks, code cache and direct buffers on top. Allocate the machine's entire physical memory to the heap and the kernel's out-of-memory killer eventually terminates the server mid-tick, which is a far worse day than a mild GC pause. See the JVM flags and GC tuning guide for how to size and shape the heap properly.
Check whether RAM is even your bottleneck
- Run `/spark health` — it reports TPS, tick duration and GC activity in one place. If TPS is below 20 while GC time is negligible, memory is not your problem.
- Watch the pattern of the lag. Constant low TPS points at CPU or an expensive plugin; periodic freezes on an otherwise smooth server point at garbage collection.
- Check whether memory use plateaus or climbs forever. A healthy server settles into a sawtooth. A line that only goes up is a leak — usually a plugin or mod, and no allocation will outrun it.
- Drop `view-distance` from 10 to 8 and `simulation-distance` to 4–6, then re-measure. If memory pressure disappears, you had a chunk-loading problem wearing a RAM costume.
- Count your entities before blaming the heap. One badly-built mob farm can hold more objects than every player on the server combined.
The settings that move the needle
`view-distance` in server.properties is the heavyweight — it scales roughly with the square of the value, so going from 12 to 8 is a far larger saving than it looks. `simulation-distance` controls how far entities and redstone actually tick and can usually sit lower than view-distance without players noticing. Beyond that, Paper's entity limits and activation ranges do more for a struggling server than any allocation change.
If you are choosing server software as part of this, Paper, Purpur and Folia differ meaningfully in how aggressively they let you trade fidelity for headroom.
RAM will not save you from an attack
One failure mode gets misdiagnosed as a memory problem constantly: a bot join-flood. Thousands of fake connections spawn player objects, load spawn chunks and exhaust the heap in seconds, and the server dies with an out-of-memory error that looks exactly like under-allocation. Adding RAM buys you a few more seconds of survival and changes nothing else, because the traffic never should have reached the server at all. That work belongs at the edge, before a connection slot is spent — no allocation setting is a substitute for filtering upstream.
Common questions
How much RAM do I need for a 20-player Minecraft server?+
For a Paper server with a normal plugin set and a view-distance of 8–10, 4 GB of heap is a comfortable allocation for 20 players. Vanilla with the same player count can run in 2–3 GB. If you are running a large modpack, 20 players is a different conversation entirely — budget 8–10 GB and expect the mods, not the players, to dominate the number.
Does more RAM make a Minecraft server run faster?+
No, and past a point it makes things worse. Minecraft server performance is measured in TPS, which is bounded by how much work the main thread finishes each tick — a CPU limit, not a memory one. Extra heap does not speed up ticks; it just gives the garbage collector a larger area to sweep, which tends to produce rarer but much longer pauses that players feel as periodic freezes.
How much RAM does a modded Minecraft server need?+
Modpacks are the one case where memory genuinely is the constraint. A light pack of 50–80 mods usually wants 4–6 GB; a large kitchen-sink pack of 200+ mods commonly needs 8–12 GB before it stops thrashing. The mod list sets the floor before a single player joins, because every registry, recipe and worldgen feature is loaded at startup regardless of who is online.
Why is my server lagging when it has plenty of free RAM?+
Because RAM was not the bottleneck. Lag with memory to spare almost always means the main thread is saturated — heavy redstone, entity or hopper load, an expensive plugin task, or chunk generation from players exploring. Profile it with spark rather than adding memory: /spark profiler start, play through the lag, and read which methods are eating the tick.
Should I allocate all my server's RAM to Minecraft?+
No. The JVM needs headroom beyond the heap for metaspace, thread stacks, direct byte buffers and the operating system's own file cache, and the host still has to run everything else. A reasonable rule is to leave at least 1–2 GB unallocated. On a 8 GB machine that means a heap of around 6 GB, not 8 — setting -Xmx to the full physical memory is a reliable way to get the process killed under load.
Sized your server properly and still getting knocked offline? Start free with Arvoris — full L4/L7 mitigation and antibot on every plan, one DNS record, no plugin.