Minecraft Server Memory and Slot Sizing by Play Style

Minecraft memory sizing breaks down the moment you stop sizing for the player list and start sizing for the world. A 40-slot vanilla server needs roughly 8 GB of heap. The same 40 slots on a 180-mod Forge pack, with a 30,000-chunk world and six loaded dimensions, will exhaust 32 GB and still show garbage-collection pauses over 400 ms. The difference is not player count. It is the resident object graph the world carries between ticks.

This is a numbers-first sizing guide. It covers heap math by play style, off-heap and native memory that Java never reports, garbage-collector behaviour that decides whether you hit 20 TPS, NVMe requirements for chunk I/O, and the spec thresholds where renting dedicated hardware beats a shared container. If you want to anchor the numbers against real provider configurations, compare dedicated game server plans at the provider comparison hub before you commit to a spec sheet.

Baseline heap requirements by play style

The table below reflects measured steady-state heap for Java Edition 1.21.x after a two-hour warm-up, with chunks pre-generated and view-distance at 8. Values assume a 20 TPS target and no aggressive pre-generation running concurrently.

Play style	Players	Steady heap	Recommended -Xmx	CPU threads
Vanilla Paper	10	1.8 GB	3 GB	2
Vanilla Paper	30	4.2 GB	6 GB	4
Vanilla Paper	60	7.5 GB	10 GB	6
Paper + 40 plugins	60	10 GB	14 GB	6
Forge 120 mods	20	9 GB	12 GB	6
Forge 180 mods	40	16 GB	20 GB	8
ATM-style kitchen sink	30	22 GB	28 GB	8
Proxy network (Velocity)	500 routing	1.5 GB	2.5 GB	4

The recommended value is not steady heap plus a fixed buffer. It is roughly 1.4x measured steady state, because the collector needs headroom to copy live objects during evacuation. A server sitting at 85% heap utilisation spends more CPU on GC than on the simulation, and you will see tick time creep from 22 ms to 45 ms without any change in player count.

A useful cross-check: divide -Xmx by slots and compare against observed tick time. Vanilla workloads under 200 MB per slot rarely have memory as the bottleneck and should be examined for chunk-generation load instead. Modded packs that exceed 500 MB per slot are almost always dominated by entity or world-gen mods, and no amount of extra heap will fix the tick cost those impose.

Memory Java never shows you

Resident memory on the host is always higher than the heap. The gap is typically 1.5–3 GB per instance and comes from four sources: the JVM metaspace (200–600 MB with mods), thread stacks, the off-heap Netty buffers used by the network stack, and the file cache attached to region files. Plan host RAM as -Xmx + 2.5 GB minimum, and -Xmx + 4 GB for modded packs with heavy world-gen mods.

• Metaspace: grows with class count. Kitchen-sink packs with 180+ mods routinely allocate 500–700 MB of class metadata.
• Off-heap Netty: scales with connection count, not player count. A BungeeCord or Velocity proxy fronting 40 backend servers can hold 400 MB in direct buffers.
• Thread stacks: a default 1 MB stack across 60–90 JVM threads. Mods that spawn their own thread pools multiply this.
• Page cache: region files read through the kernel are cached outside the JVM. This is why a server with 32 GB RAM and 20 GB heap still shows 28 GB resident.

Collector choice changes the CPU budget, not the RAM budget

G1 is the default and remains correct for heaps under about 16 GB. Above that, the pause profile degrades because G1’s region-based compaction cannot keep up with the allocation rate of a large modded world. Two practical configurations dominate production Minecraft fleets:

• G1 for vanilla and light plugin servers. Set -XX:+UseG1GC -XX:MaxGCPauseMillis=150 -XX:G1HeapRegionSize=8M. Target allocation rate under 400 MB/s; above that, pause times exceed the target regardless of tuning.
• ZGC Generational for heaps above 16 GB. Set -XX:+UseZGC -XX:+ZGenerational -XX:+AlwaysPreTouch. Sub-5 ms pauses even at 32 GB, at a cost of 15–25% more CPU during collection and one extra thread per core for concurrent work.
• Never use AlwaysPreTouch on shared or metered hosts. It touches every page at startup, which turns a 20 GB heap into a 20 GB RSS spike and can trip a container memory limit.

Chunk I/O is the hidden CPU tax

Each region file is a 4 KB-aligned container holding up to 1,024 chunks. Loading a chunk requires reading its header, decompressing the NBT payload, and deserialising entities. On a SATA SSD with 60 ms p99 latency at queue depth 1, a player teleporting into ungenerated terrain stalls the main thread for 80–150 ms. On a datacentre NVMe with power-loss protection, the same operation lands at 12–20 ms.

Two practical consequences. First, storage is not a place to save $15/month — a consumer QLC drive will wear out from region writes and deliver inconsistent p99 latency long before it fails outright. Second, pre-generation is a CPU task, not a disk task, so run it before launch on a separate window rather than during peak hours. A 10,000-radius world on a 4-core node takes roughly 40 minutes per 1,000 chunks at default settings; schedule it overnight in batches.

Concurrency, autosaves and the peak that kills you

Steady-state heap is not the number that crashes servers. The failure mode is a coincident peak: an autosave writing every loaded region at the same moment a world-border expansion forces new chunk generation while 40 players are in combat. In that window, live set can grow 30–50% within seconds, and a heap sized to steady state will hit a full collection at the worst possible moment.

Mitigate in three places. Stagger saves per world with max-auto-save-chunks-per-tick set to 8 instead of the default 24, which spreads region writes across roughly 30 ticks rather than 10. Cap entity-activation-range so distant mobs do not tick, which cuts live-object count in large bases. And keep the view distance at 8 for anything above 40 players — dropping from 10 to 8 reduces loaded chunks per player by roughly 36%, which is the single largest RAM lever available in the config.

Matching a spec sheet to the sizing table

A modded 40-player server needing 20 GB of heap requires 22–24 GB of host RAM for that instance alone. Add a Velocity proxy at 2.5 GB, monitoring, and OS headroom, and you are at 28 GB before a second world exists. That pushes you into a 32 GB or 64 GB node. Clock matters as much as capacity here: Minecraft’s main thread is single-threaded for world ticks, so a 4.2 GHz sustained clock beats a 2.4 GHz core-dense Xeon every time. Look for parts that hold boost under all-core load rather than peak turbo figures.

Above those points, dedicated hardware is not about raw speed. It is about the removal of noisy-neighbour variance: a fixed single-thread clock you can budget against, an NVMe device nobody else shares, and a network path with a known congestion profile. For fleets of three or more instances, that predictability is usually worth more than the headline core count. You can review dedicated host configurations and hardware tiers here to match core density and RAM to the sizing table above.

When the numbers say “move off shared hosting”

Three thresholds reliably indicate that a Minecraft community has outgrown a shared game-hosting plan and needs dedicated silicon. Tick time p99 above 35 ms at your target player count. Heap above 16 GB for a single instance, because shared plans rarely offer that without overcommit. And sustained CPU steal above 3% on the node, which you can measure with vmstat 1 30 on the instance or infer from tick spikes that correlate with other tenants’ activity.

Above those points, dedicated hardware is not about raw speed. It is about the removal of noisy-neighbour variance: a fixed single-thread clock you can budget against, an NVMe device nobody else shares, and a network path with a known congestion profile. For fleets of three or more instances, that predictability is usually worth more than the headline core count. You can review dedicated host configurations and hardware tiers here to match core density and RAM to the sizing table above.