How much RAM a Minecraft server actually needs
Sizing is usually asked as players per gigabyte: ten friends, how much RAM? That framing produces the wrong answer, because a Minecraft server does not hold players in memory. It holds world: the chunks currently loaded, the entities and block entities inside them, and whatever your plugins cache alongside. Players matter only in that each drags a square of loaded chunks around.
Two players can cost more than eight
The view-distance setting is a radius in chunks, not a diameter. At the default of 10, one player keeps a square of 21 by 21 chunks loaded, 441 in total, plus a ring the server keeps at the edge for bookkeeping. That square is the unit of memory cost, and it is shared.
- Eight players in one base. Their squares overlap almost completely, so the server holds roughly one 441 chunk square, however many names are in the tab list.
- Two players 1000 blocks apart. 1000 blocks is about 62 chunks, so the squares do not touch: 882 chunks, twice the world of the eight player base.
- One player in a boat. Worse per head than either, because the square is moving and chunks are generated at the leading edge while the trailing edge is still resident.
So an honest answer starts with questions back: how far do they see, how spread out do they play, how much has been built. The official Minecraft Wiki server requirements page puts a player object at roughly 50 to 100 MB while noting the server often allocates much more per player, and ties its figures to default settings and a new world. The estimate moves with the world, not the roster.
Realistic sizing
Ranges with the reason attached; one confident number for a server nobody has looked at is a guess. These are heap sizes, not plan sizes.
| Case | Heap to start from | What actually drives it |
|---|---|---|
| A few friends, vanilla, one shared base | 2 to 4 GB | One overlapping chunk square, few entities. World size on disk matters less than how much is open. |
| Vanilla, 10 to 20 players, established world, spread out | 4 to 6 GB | Disjoint chunk squares. Every group elsewhere is another square, and old worlds carry more block entities per chunk. |
| Small Paper server, up to roughly 20 light plugins | 4 to 6 GB | The same chunk arithmetic plus per plugin class data and small caches. |
| Medium plugin server: economy, claims, block logging, web map | 6 to 10 GB | Plugin state, not chunks: loggers buffer edits, claim plugins hold region data, map renderers hold tiles. |
| Large plugin server or network, several worlds | 10 GB and up | Several worlds ticking at once, each with its own loaded set. Measure the live set rather than estimate it. |
| Modded: Forge, NeoForge, Fabric, any modpack | See the modpack page | Mod count sets boot memory before anyone connects, so sizing is per pack: modpack server sizing. |
The same wiki page suggests 1 GB as an absolute minimum, around 2 GB for a small group and 4 GB past ten players, assuming default settings and a fresh world. The ranges above sit higher because real servers are rarely fresh worlds.
View distance and simulation distance, the lever you control
Both default to 10, both accept 3 to 32, and they are constantly conflated. They do different jobs:
view-distancesets how much world data the server sends the client, in chunks in each direction of the player. It decides how many chunks are loaded and shipped, so it is the setting that moves memory.simulation-distancesets the maximum distance from a player at which living entities are still updated by the server. It decides how much of the loaded world actually ticks: mobs moving, crops growing, redstone running.
A chunk inside view distance but outside simulation distance is still in memory and still drawn, but it is cheap, because it is not ticking. Lowering view distance cuts loaded chunks, outbound traffic and memory together, which is why it is the first thing to touch. Lowering simulation distance cuts tick work and entity updates with a smaller memory saving, and players rarely notice, because the horizon is unchanged.
Going from view distance 10 to 6 takes a player's square from 441 chunks to 169, under 40 percent of the world per player, without touching a plugin. Nothing else an operator controls has that ratio.
Before you drop simulation distance: anything that depends on the world ticking while nobody stands next to it stops once it falls outside the radius. Mob farms, crop farms and villager breeders are the usual casualties, and they get reported as bugs long after the change that caused them.
More memory is not a performance setting
Raising -Xmx on a server that is not short of memory often makes things worse, and the result is easy to misread. A larger heap lets more garbage accumulate between collections and leaves more live data to trace when one runs. G1, the collector these servers use, treats its pause target as a goal, not a guarantee: Oracle's tuning guide states that G1 is not a real time collector and can fall back to a stop the world full heap compaction. Players do not read that as low memory. They read it as a freeze of about a second, at intervals, on a server whose memory graph looks fine.
Two further points get servers killed outright:
-Xmxis not your total footprint. Class metadata, which grows with every plugin and mod, plus thread stacks, network buffers and the collector's own structures live outside the heap. Setting-Xmxto the whole plan leaves nothing for them.- The heap is committed at startup. With
-Xmsequal to-Xmxand pre-touch on, which is what Aikar's flags do, the process claims all of it before anyone connects. Set it above the plan limit and the host kills the process instead of Java raising an error: the server vanishes with no crash report.
Telling a memory problem from everything else
| Symptom | Most likely cause | What to check |
|---|---|---|
| OutOfMemoryError: Java heap space, crash report written | Genuine heap exhaustion, or a leak | When it happened. During pregeneration it is a spike; hours in with a climbing heap it is accumulation. Read the log. |
| Process disappears, log stops mid line, no Java error, exit code 137 | The host killed it: committed memory exceeded the plan limit | -Xmx plus overhead against plan size. A Java out of memory writes a stack trace; a kernel kill writes nothing. |
| Freeze of about a second at intervals, healthy tick rate between | A collection pause, or the full auto save | Time the gap. Auto save defaults to 6000 ticks, five minutes, so save stutter is regular and pauses are not. Modded: save tick lag. |
| Tick rate steadily below 20, plenty of free heap | CPU, not memory: the tick is doing too much work | Entities, hopper chains, redstone and plugin cost, measured with Spark. RAM changes nothing. |
| Stutter only while someone explores | Chunk generation on demand | Pregenerate and set a border: Chunky pre-generation. |
| Long pause at save time, slow shutdown | Too many loaded and dirty chunks meeting disk | View distance, loaded chunk count, storage speed: slow chunk loading. |
The sentence the server is laggy is usually not a statement about memory. A low tick rate with a half empty heap is a CPU or workload problem, and a bigger plan will not move it.
When you genuinely are out of memory
- Confirm it: an out of memory error in the log, or a kill at the limit. Not a low tick rate.
- Drop
view-distancea step or two and setsimulation-distanceat or below it, in server.properties. - Pre-generate the world and set a border, so exploring no longer generates chunks under live load.
- Thin the loaded chunks: dropped items, stacked mob farms, decorative entities, hopper chains. Entity density is memory and tick time at once.
- Audit plugins for in-memory state: web maps, block loggers, chunk anchors. Bound the cache rather than dropping the feature.
- Check heap settings:
-Xmsequal to-Xmx, real headroom under the plan limit, current flags. - Measure. A Spark heap summary shows what is occupying the heap; guessing is how people buy memory they did not need.
- Then, if the live set is genuinely large, buy more.
When a bigger plan is the right answer, and when it is not
Upgrade when the live set is genuinely large: after a full collection the heap is still substantially occupied, view distance is sensible, the world is pregenerated, and the plugin list is what you want to run. That is real work in too small a box, and tuning will not shrink it.
Do not upgrade when the tick rate is low while the heap is free, when memory climbs from every restart until it dies (a leak follows you to the bigger plan), or when the symptom is a periodic freeze on a server with headroom, since a larger heap can lengthen that pause. The tell is timing: healthy after a restart and degrading over hours is accumulation; hitting the ceiling minutes after a restart means the workload really is larger than the plan.
Related guides
- Modpack server sizing for Forge, NeoForge and Fabric
- Aikar's flags, the collector settings for your heap size
- Fixing can't keep up lag, when tick rate is the problem
- Spark profiler, for measuring instead of guessing
- Server software comparison: Paper, Purpur, Folia
- Java 21 vs 26 for servers
- What a Minecraft server costs
Need a Minecraft Java server sized properly? Supercraft runs Minecraft dedicated servers on AMD EPYC nodes with NVMe storage, daily backups, in-place plan upgrades when a world outgrows its heap, and 4 region options.