Minecraft Server RAM Requirements: How Much You Actually Need

How much RAM does a Minecraft server need?

For a plain vanilla server, plan on 2 GB for up to five players. Paper with around ten players needs 3 to 4 GB. Once you pass twenty players, give it 6 GB. Modded servers are different. A light modpack needs 6 to 8 GB. A heavy ATM-class pack needs 10 to 12 GB to run without stuttering.

These numbers are total server-side memory. You still need to subtract headroom for the operating system, which the next section explains. They also assume a reasonable render distance and a tuned server jar. Modded servers are the wild card here. Two packs with the same name can differ by gigabytes depending on mod count and world generation load. If you run Fabric packs, our Fabric hosting page lists the RAM for each tier. Treat the modded numbers as a floor, not a ceiling. Add memory as you add mods, chunk pre-generation, and concurrent players.

Why more RAM does not fix low TPS

Throwing more memory at a slow server is a common mistake. It will not raise your tick rate. A Minecraft server runs the world on a single main thread. That means ticks per second are limited by per-core clock speed, not by how many gigabytes you hand the JVM. Our Ryzen vs EPYC benchmarks show why we run Minecraft plans on the Ryzen 9 7950X3D.

Entity ticking, redstone, mob AI, block updates, and chunk loading all queue on that one thread. When it cannot finish a tick in under 50 milliseconds, TPS drops below 20 and the game slows for everyone. Throwing more RAM at that server changes nothing. The bottleneck is compute, not memory.

RAM only helps TPS in one indirect way. When the heap is too small for the workload, garbage collection pauses stall the tick loop. Give that server enough headroom and the pauses shrink. Past that point, you need a faster core. The 7950X3D has 96 MB of 3D V-Cache. That keeps more of the hot tick-loop data close to the core and improves single-thread throughput on exactly the kind of pointer-chasing work a Minecraft tick does.

JVM heap vs system RAM: leave headroom

Do not give the JVM every gigabyte on the box. The heap you set with -Xmx is only part of what the process uses. The JVM also needs off-heap memory for threads, buffers, and metadata. The operating system needs its own share too. Leave 1.5 to 2 GB free on top of the heap.

Set -Xms equal to -Xmx. Locking the minimum and maximum heap to the same value allocates it once at startup and stops the JVM from resizing the heap under load. That resizing is where a lot of avoidable stalls come from. On an 8 GB plan, that means a 6 GB heap with roughly 2 GB left for the OS and off-heap use.

# On an 8 GB plan, leave ~2 GB for the OS and off-heap memory.
# Heap is allocated once at start-up and never resized.
java -Xms6G -Xmx6G -jar server.jar --nogui

Aikar's flags for garbage collection

Aikar's flags are a tuned set of G1GC options for Minecraft that cut garbage-collection pauses. They are the community default for Paper and its forks. Paste them into your start command, set both heap values to your allocation minus headroom, and leave the rest alone.

The set below is the published reference from the PaperMC Aikar's flags documentation. Replace 10G with your own allocation on both -Xms and -Xmx.

java -Xms10G -Xmx10G --add-modules=jdk.incubator.vector \
  -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M \
  -XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 \
  -XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 -Dusing.aikars.flags=https://mcflags.emc.gs \
  -Daikars.new.flags=true -jar server.jar --nogui

These flags use G1GC, which is the right collector for heaps up to roughly 12 GB. The documentation notes a few adjustments for heaps at 12 GB and above. G1NewSizePercent, G1MaxNewSizePercent, G1HeapRegionSize, and InitiatingHeapOccupancyPercent all move up. On very large heaps, such as a heavy modpack on 16 GB or more, generational ZGC can hold pauses to a millisecond or two where G1 pauses start to climb. That comes at some cost to raw throughput. Switch to ZGC only when you measure long G1 pauses under real load. For most servers, G1GC with the flags above is the better default.

view-distance and simulation-distance

The easiest way to cut both RAM and CPU is to lower two settings in server.properties. view-distance controls how many chunks the server streams to each player. simulation-distance controls how far it keeps ticking entities and redstone. Trimming both frees memory and main-thread time at once.

Lowering simulation-distance is the bigger win because it reduces the single-thread CPU cost that caps TPS. Dropping view-distance mainly saves memory and bandwidth. A common starting point for a busy server is a view distance of 8 with simulation held lower still.

# server.properties — trim what the server streams and ticks
view-distance=8
simulation-distance=6

Symptoms of wrong sizing

You can read the sizing straight from the logs. Too little RAM shows up as garbage-collection thrash and repeated "Can't keep up" warnings as ticks run long. Too much RAM on an oversized heap shows up as rare but long GC pauses that freeze the server for a second or more.

When the heap is starved, the JVM spends more and more time collecting garbage and less time running the game. The console fills with lines about ticks taking too long. The server appears to stutter every few seconds. That is the signal to add memory, not to lower it.

The opposite mistake is quieter and easy to miss. An enormous heap on a low-activity server lets garbage pile up between collections. When G1GC finally runs a full pass it has a mountain to clear, and the world hangs for a noticeable beat. If a mostly-idle server hitches on a regular interval, the heap is probably larger than the workload justifies.

Which Minecraft plan fits your server

Match the sizing table to a plan, then account for operating-system headroom on top. Our Minecraft plans use dedicated DDR5 ECC RAM, so the figure you buy is the figure you get. MC-4-GB suits vanilla and small Paper servers. MC-32GB carries the heaviest modpacks at high player counts.

Read the plan RAM as total, not heap. On a 4 GB plan you set a 2 to 2.5 GB heap and leave the rest for the OS. That is why it works for vanilla and small Paper servers rather than modded ones. Step up whenever your heap plus the 1.5 to 2 GB headroom no longer fits inside the plan.

FAQ

Start here

Pick the row that matches your player count and server type. Add 1.5 to 2 GB of headroom. Buy the plan whose total RAM covers the sum. If you are between two tiers, size up. Heap you do not use costs little. A heap that runs out takes the server down. When your pack or player count grows, change the tier and restart on the same world.