How to Allocate More RAM to a Minecraft Server

1. Decide whether memory is the constraint

Two observations settle it. Run /tps during a busy session: 20.0 means the tick loop is keeping up, whatever the memory graph shows. And read the memory graph itself: a server that runs out is one where usage climbs to the ceiling and stays there.

If TPS is fine and memory is not full, stop here. What you are feeling is lag, and it is fixed by reducing server lag, not by allocating more memory.

/tps
/mspt

• TPS 20.0, memory 60% used: memory is not your problem.
• TPS 15, memory 95% used, climbs each day: memory is your problem, and something is leaking.
• Server crashed with java.lang.OutOfMemoryError: memory, definitively.

2. Work out the heap your machine can give

Take the RAM available to the server process and subtract 1000 to 1500 MB for the JVM and the operating system. That remainder is your -Xmx. Paper documents this margin because a heap set to the full amount of RAM gets the process killed rather than allowed to fail gracefully.

Set -Xms equal to -Xmx. The JVM will otherwise start small and grow, and resizing costs pauses during a session.

4 GB total   -> -Xms2G -Xmx2G
8 GB total   -> -Xms6G -Xmx6G
12 GB total  -> -Xms10G -Xmx10G
16 GB total  -> -Xms13G -Xmx13G

3. Set it where the server reads it

The heap is a startup argument, so it lives wherever your start command lives. A self-hosted server has it on the command line; a systemd unit has it in ExecStart; a hosting panel has a memory field that writes the same thing for you.

On a panel, use the memory control rather than editing anything by hand: the platform accounts for its own overhead, and a manual heap that exceeds it gets the process killed. On PufferHost the free tier is 3 GB and the platform sets the heap for it.

java -Xms6G -Xmx6G -XX:+UseG1GC -jar server.jar --nogui

ExecStart=/usr/bin/java -Xms6G -Xmx6G -XX:+UseG1GC -jar server.jar nogui

4. If memory still runs out, find what is holding it

A correctly sized heap removes the crash caused by too little memory. It does not remove a leak: something that grows until it fills whatever ceiling you set. Turn on GC logging, restart, and let the server run through its usual week.

Then read it. A heap that returns to a low level after each collection is healthy. A heap that climbs towards -Xmx and stays there is a leak, and the class names in the log usually point at the plugin or the world responsible. The memory guide has the full procedure.

-Xlog:gc*:logs/gc.log:time,uptime:filecount=5,filesize=1M

/spark heap

5. Trim what you can before adding more

Memory tracks work. Chunks held in play, entities accumulating on a farm, and plugins holding caches all cost heap for as long as they exist. Lowering view and simulation distance, capping entity spawning and removing an unused plugin all reduce the ceiling you need.

That is why the sizing question comes before the shopping question: a server at 3 GB that holds a steady 2 GB is fine, and the same server at 6 GB that climbs to 5.9 GB every week has a problem more memory will only postpone.

view-distance=6
simulation-distance=6

Good to know

• Memory pressure and tick load are different problems with different fixes. A server that stutters in pulses is usually garbage collection; a server that stutters constantly is usually tick work.
• Restarting with a bigger heap feels like a fix because the memory graph starts from zero. If the graph climbs back to the ceiling on the same schedule, the leak is unchanged.
• Two servers on one machine share nothing but the operating system, so divide the memory between them rather than giving each the full amount.
• Best JVM flags covers the flags that go alongside -Xmx, and the memory guide covers leaks in full.

Common questions

Sources

Official documentation this guide was checked against.

• PaperMC docs: recommended JVM flags and the memory margin
• PaperMC docs: world configuration, the settings that reduce loaded chunks
• PufferHost knowledge base: RAM