How much RAM does a Minecraft server need?

How much to allocate by what you actually run, why more can make things worse, and how to measure what you need instead of guessing.

The short answer is a table. The rest of this page is the reasons it is not that simple.

These are Java heap allocations, not machine totals. Leave headroom on top.

#Why player count is the wrong input

Nearly every RAM calculator asks how many players you expect. It is a weak predictor.

Memory is consumed mostly by things that exist whether or not anyone is online: loaded mods and their registries, chunks held in memory, entities and block entities inside them, and plugin data.

A pack with three hundred mods allocates its registries at startup, before a single player connects. A vanilla server with thirty players does more work per tick than an idle modded one while holding far less in memory.

Players do add memory, mainly through chunks loaded around them, and spread-out players keep more chunks resident than players standing together. This is why view distance is among the most effective settings for reducing memory pressure, and why player count on its own tells you little.

#Why more RAM can make a server slower

This is the counterintuitive part, and the reason "just give it everything" is bad advice.

Java reclaims memory with a garbage collector. Periodically it traces live objects and frees the rest, and during parts of that work the application pauses. The larger the heap, the more there is to trace, and the longer the worst-case pause.

A Minecraft server targets 20 ticks per second, which is one tick every 50 milliseconds. A 200 millisecond pause means four missed ticks, which players experience as a freeze. A server with a very large heap can show better average performance and noticeably worse worst-case behaviour, and players remember the freezes rather than the average.

Symptoms of an oversized heap: smooth play interrupted by brief stalls at intervals, memory graphs with a deep sawtooth, and stalls that lengthen as the heap fills.

#Leave room outside the heap

The -Xmx figure is the maximum heap, not the total the process uses. On top of it the JVM needs thread stacks, class metadata, compiled code and direct buffers for network and file work. The operating system needs memory, and so does the file cache that keeps world data fast to read.

On a machine you own, a workable rule is to give the heap no more than about two thirds of physical memory. On a 16 GB desktop that means a 10 GB server with 6 GB left for everything else, including the game client if you are playing on the same machine.

Allocating 15 GB of a 16 GB machine is a reliable way to make everything worse, the server included, because the system starts swapping.

#Setting Xms and Xmx

Set them to the same value. -Xms10G -Xmx10G for a 10 GB server.

Java grows the heap toward its maximum as needed, and growing costs work. Starting at the maximum avoids repeated resizing during exactly the period when the server is busiest, loading a modpack and generating spawn chunks.

The common advice to leave Xms low so the server "only uses what it needs" suits a desktop application. It does not suit a server whose memory use is dominated by an allocation it will make anyway.

#Measuring what you actually need

Guesswork is unnecessary. Run it for a few sessions and look.

Check TPS first. Use /tps on Paper and most modded servers. If it sits at 20 the server is keeping up, and memory is not your problem whatever the graphs suggest.

Read the heap after a collection, not the peak. Java fills what it is given before collecting, so a heap graph sitting near the maximum is normal rather than a shortage. What matters is the level it falls to after a full collection. If that floor climbs steadily over hours something is leaking. If it settles comfortably below the maximum, you have enough.

Look for repeated full collections that reclaim little. That is a server actually short of memory, and the signal to increase the allocation.

The common mistake is reading a nearly full heap as "needs more RAM". Nearly full is what a healthy Java heap looks like.

#When adding RAM will not help

If TPS is falling while memory is fine, more RAM changes nothing. The usual causes:

• A single expensive mod or plugin doing work every tick
• Large numbers of entities concentrated in one area
• Hopper and item transport chains, individually cheap and collectively expensive
• Chunk generation from players exploring, which is CPU-bound
• A single core that is not fast enough, since the main tick loop is single-threaded

Diagnosing server lag properly works through these in order.

#Where Hostd fits

We sell RAM tiers, so treat this accordingly. Our Minecraft Java plans are 3, 6, 10 and 14 GB, which map onto the table at the top, and memory is reserved for each server rather than oversold.

We would rather sell the tier that matches your pack than the one above it. A server that stutters produces support tickets and refunds, so if your pack fits in 6 GB, buy 6 GB.

Written and maintained by the Hostd engineering team. Last updated 2026-08-11. Notice a mistake? Tell us.