Minecraft RAM Calculator

How much RAM does a Minecraft server need?

This Minecraft RAM calculator estimates the memory a Java Edition server needs from four things you already know: how many players are online at peak, which server software you run, how many plugins or mods it loads and the view distance in server.properties. It adds up a rough cost for each and gives you three numbers: the least heap the server can start with, a recommended heap with room for garbage collection, and the total memory to plan for on the machine.

For a quick answer: a small Vanilla or Paper server for a group of friends runs well on 3 to 4 GB. A community server with 20 to 40 players and a normal set of plugins usually wants 6 to 8 GB. Modpacks are a different class. A light Fabric pack is comfortable at 5 to 6 GB, and a large Forge or NeoForge pack with 200 or more mods often needs 10 to 14 GB before the first player joins.

These are estimates. Two servers with the same player count can use very different amounts of memory, because one has pre-generated a small world and the other has players flying in every direction with elytra. Use the result as a starting heap, then measure (see "How to check real memory use" below) and adjust.

What the calculator counts

The estimate is the sum of four parts. The breakdown table under the result shows each one, so you can see which part dominates.

The server software

A server with no players online still uses memory: the game's registries, loaded classes, the spawn area and the server's own caches. The calculator starts from these figures:

Plugin servers start a little higher than Vanilla because Paper and Spigot keep extra caches and load the plugin system. Forge and NeoForge start highest because the loader itself, the mod registry and the patched game classes all take memory before a single mod adds anything.

Plugins and mods

The per-plugin and per-mod figures are averages. Most plugins use very little: a chat formatter or a small command plugin barely registers. A few use a lot: map renderers like Dynmap and BlueMap, large minigame frameworks, and anything that keeps its own copy of world data. If your plugin list includes those, add a gigabyte or two on top.

Mods are harder to average. A mod that adds one block is tiny. A mod that adds a dimension, a tech tree and hundreds of items is not. The calculator's 15 to 20 MB per mod works for typical packs. Kitchen-sink packs such as All the Mods land at the high end of the result or above it. The ATM9 hosting guide has real numbers for one of the biggest packs.

Players and view distance

Each player keeps a square of chunks loaded around them. The side of that square is twice the view distance plus one, so view distance 10 means 21 × 21 = 441 chunks per player. The calculator counts about 80 MB of chunk data per player at view distance 10 and about 25 MB for the player's own entity, inventory and network buffers.

The chunk part grows with the square of the view distance:

This is why lowering the view distance is the cheapest way to save memory on a busy server. Dropping from 10 to 8 saves about a quarter of the per-player cost, and most players will not notice the difference. The view distance calculator works the other way round: give it the RAM you have and it suggests a view distance.

The calculator treats every player as having their own chunks. On a real server, players who stand together share chunks, so a server where everyone plays in one town uses less than the estimate. A server where everyone spreads out to build their own base uses about what the estimate says.

Headroom

Java does not free memory the moment an object stops being used. The garbage collector cleans up in batches, and it needs free space in the heap to work in. If the heap is nearly full all the time, the collector runs constantly and the server stutters.

The recommended heap is the estimate plus 30%, rounded up to a whole gigabyte, and always at least one gigabyte above the minimum. That leaves the garbage collector room to work without pauses players can feel.

Heap size and machine memory are different numbers

The recommended RAM is the Java heap, the number you pass to -Xmx. Java uses memory outside the heap too: loaded classes (metaspace), thread stacks, the JIT compiler, and native buffers for networking and compression. On a Minecraft server that is usually 500 MB to 1 GB.

So a server with -Xmx6G needs about 7 GB on the machine, plus whatever the operating system and anything else on the box uses. The calculator shows this as "machine memory".

This matters most on hosting plans and in containers. If a plan is sold as 6 GB and you set -Xmx6G, the process can grow past the limit and the host kills it. The crash log then shows no Java error at all, because the operating system ended the process from outside. Set the heap about 1 GB below the plan's limit.

How to set the memory

For Vanilla, Paper, Purpur, Spigot and Fabric, the heap goes on the start command:

java -Xms6G -Xmx6G -jar server.jar nogui

• -Xmx is the largest the heap may grow
• -Xms is the size it starts at

Setting both to the same value is the usual advice for servers. The heap never has to grow or shrink while players are online, and with -XX:+AlwaysPreTouch (part of Aikar's flags) Java claims all of it at start, so you find out immediately if the machine does not have the memory.

Forge 1.17 and later, and NeoForge, start through run.sh or run.bat instead of java -jar. Those scripts read JVM options from user_jvm_args.txt in the server folder. Put the two flags there, one per line:

-Xms10G
-Xmx10G

The calculator's output switches to this form when you pick Forge or NeoForge.

The memory flags are only the start. The JVM arguments generator takes your heap size and adds Aikar's garbage collector flags, which tune G1 for the short-lived objects Minecraft creates every tick. Aikar's flags change some settings above 12 GB, and the generator handles that for you.

If you are writing a start script from scratch, the RAM requirements guide walks through the same numbers with more examples for specific modpacks.

How to check real memory use

The operating system's view is misleading. A Java process with -Xms6G and AlwaysPreTouch shows 6 GB or more in top or Task Manager from the first second, however little of the heap holds live data.

Look inside the JVM instead:

• spark (a plugin and mod for Paper, Fabric, Forge and NeoForge) shows heap use with /spark health, and /spark heapsummary lists what fills the heap
• Recent Paper builds bundle spark, so /spark works there without installing anything
• The garbage collection log, turned on with -Xlog:gc*:file=gc.log, shows how full the heap is after each collection

The number to watch is heap use right after a garbage collection. That is the memory the server actually needs. If it stays under half of -Xmx during peak hours, you can lower the heap. If it climbs above 80% and stays there, raise it, lower the view distance, or find out what is filling it.

Common mistakes

Giving the server all the machine's memory

On an 8 GB machine, -Xmx8G leaves nothing for Java's own overhead or the operating system. The machine swaps or the process gets killed. Leave at least 1 to 2 GB free.

Adding RAM to fix lag

Most lag is CPU, not memory. Minecraft runs the main game loop on one thread, and a server with too many entities, hoppers or redstone clocks lags at 4 GB and at 16 GB alike. More memory only helps when the heap is actually full, which spark will tell you. For everything else, start with the server lag guide and the TPS explainer.

A heap just over 32 GB

Below about 32 GB, Java stores object references in 4 bytes (compressed object pointers). Above it, every reference takes 8 bytes, so the same data uses more memory. A 32 to 40 GB heap can hold less than a 31 GB one. The calculator warns when the recommendation crosses this line. In practice, a single Minecraft server that needs more than 31 GB is usually a sign to split players across several servers.

Forgetting the proxy

A network with a Velocity or BungeeCord proxy needs memory for the proxy too, but far less than a game server: 512 MB to 1 GB is typical. Count each backend server separately with this calculator, then add the proxy. The Velocity config builder sets up the proxy itself.

Not pre-generating the world

Generating new chunks is expensive in CPU and in memory, because the server holds partly built chunks while it works on them. Players exploring in several directions at once cause memory spikes that the estimate does not include. Pre-generating the world with Chunky removes most of that load. See the Chunky guide.

Ways to need less RAM

• Lower the view distance. It is the biggest per-player cost. 8 is a common choice for busy servers, and the server.properties generator sets it along with simulation-distance
• Use Paper or Purpur instead of Vanilla or Spigot. They load and save chunks more efficiently and ship many performance fixes. The Paper config generator covers the settings that matter most
• Remove plugins you do not use. Each one loads classes and often keeps its own caches
• Limit entity counts. Mob farms and item piles hold memory and CPU. The spigot.yml generator sets entity activation ranges and item merge radius
• Set a world border. It caps how far the world can grow, which caps how much map data exists

If you are choosing between server software, the Paper, Spigot, Fabric and Forge comparison explains what each is for.