Giving a Minecraft server more memory usually makes it worse. That sentence contradicts every hosting page in the industry, and it is the single most useful thing to know about running one.
Memory is not speed. Java does not run faster with more of it. What more memory buys is a longer interval between garbage collections and a longer pause when one happens, and on a game with a fifty-millisecond tick budget, the pause is what players feel.
What the heap is
A Java program gets a region of memory called the heap. Objects live there, and periodically the runtime stops to work out which are no longer referenced and reclaim them. That stop is a garbage collection.
Two numbers control it:
-Xms is the starting heap size. -Xmx is the maximum.
Set -Xmx8G and the server may use up to 8 GB regardless of how much the machine has. Set it larger than physical memory and the operating system kills the process when it tries to use what it was promised, which appears as a crash with nothing in the server's own log. Diagnosing a crash covers finding that in the kernel log.
The numbers that work
For a plugin server on a modern version, roughly:
| players | heap |
|---|---|
| up to 10 | 4 GB |
| 10–40 | 6 GB |
| 40–100 | 8–10 GB |
| modded, any size | 8–12 GB |
Above about 12 GB you are usually solving the wrong problem. A server that needs 16 GB is nearly always a server with an entity or chunk problem that memory is hiding rather than fixing, and why your Minecraft server lags is the article to read before buying more.
Set -Xms equal to -Xmx. This is the one flag recommendation nearly everyone agrees on. Letting the heap grow means the JVM spends effort resizing it, and the resize happens under load because that is when memory is needed. Fixing both at the same value removes the whole behaviour.
Leave the machine something. The operating system, the JVM's own overhead outside the heap, and anything else on the box. On a 8 GB machine, an 8 GB heap is a machine that will be killed. Six is the sensible ceiling there.
Garbage collectors
Java offers several and the choice matters more than the size does.
G1GC is the default on modern Java and the right answer for nearly every Minecraft server. It is designed to keep pause times bounded, which is exactly the property a tick loop needs.
ZGC and Shenandoah achieve much shorter pauses at the cost of throughput. On very large heaps they are worth testing; below 12 GB they usually are not, and the throughput loss shows up as lower TPS under load.
Parallel and Serial collectors are wrong here. They optimise for total throughput and accept long pauses, which is the opposite trade.
The widely-circulated Minecraft flag sets: Aikar's being the best known, are G1GC tuned for this specific workload: smaller heap regions, earlier collection, and a target pause under the tick budget. They are worth using and they are not magic. On a server with a real performance problem they will not help, because the problem is not collection.
What people get wrong
Buying 32 GB. Common, expensive, and frequently slower than 8. Larger heaps take longer to collect, and the extra memory sits unused while the pauses get worse.
Setting -Xmx to the machine's full memory. Guarantees the process is killed eventually.
Copying flags without the version. Flag sets written for Java 8 are not right for Java 17 or 21, and some flags were removed outright — a server that will not start after a flag change is usually this.
Assuming memory pressure explains bad TPS. It sometimes does. It usually does not. The way to tell is to watch whether the TPS drops correlate with collection pauses or with something else, and a profiler answers that in a minute.
Treating the hosting plan's RAM figure as the spec. Hosts sell memory because it is easy to sell and easy to compare. The number that determines how the server feels is single-core clock speed; more cores will not fix your server makes the argument, and it applies to memory just as directly.
Java version
Modern Minecraft requires a recent Java, and the version matters beyond compatibility. Each release has improved G1GC meaningfully, so running the newest version your server supports is a free improvement rather than a preference.
Check what the server software recommends rather than what is installed. A machine running an old default JVM is a common and invisible handicap.
How to tell whether any of this is your problem
Three checks, in order.
Look at TPS, not memory. If TPS is 20, nothing on this page is your issue. If TPS drops in brief spikes, collection is a candidate.
Turn on GC logging for an hour. The JVM will report every pause and its duration. Pauses under about 30 ms are invisible. Pauses over 100 ms are what players call lag spikes. If there are none, memory is not your problem.
Check whether memory is full. A server sitting at 40% heap usage does not need more, whatever else is wrong.
Most servers that go through this discover the answer is entities or a plugin rather than memory, which is the point of doing the checks before spending anything. Reading game server logs covers where the evidence lives.
A configuration that works for most servers
For a plugin server of thirty players on current Java:
-Xms6G -Xmx6G, matched- G1GC with a Minecraft-tuned flag set for your Java version
- The newest Java the server software supports
- Nothing else on the machine competing for it
Then leave it alone and go and look at view distance, entity limits and the plugin list, which is where the actual gains are.
Modded servers are different
Everything above applies to plugin servers. Modded ones, Forge, Fabric, and the large modpacks: shift the numbers.
Heaps are larger. A big modpack legitimately wants 8 to 12 GB where a plugin server is comfortable at 6. The mods hold more in memory and there is more of everything.
The ceiling is still real. Above about 12 GB the collection pauses start costing more than the extra headroom buys, and a modpack that needs 20 GB usually has a specific mod misbehaving rather than a genuine requirement.
Startup is slow and that is normal. Several minutes for a large pack. It is not a hang.
Mod-specific memory leaks exist and are the usual cause when a modded server degrades over hours rather than days. The pattern is a heap that never returns to its baseline after a collection, and the fix is finding the mod rather than adding memory.
If you run a modpack, the pack's own documentation frequently recommends a heap size. That figure is usually a reasonable starting point and usually generous.
The one-line summary
Match -Xms and -Xmx, set them to 6 to 8 GB for a normal plugin server, use G1GC with a current flag set, run recent Java, and leave the machine some memory.
Then stop thinking about memory and go and look at entities, view distance and your plugin list, which is where the performance actually is. Why your Minecraft server lags covers those in the order they usually matter.
Why the myth persists
Two reasons, and both are structural rather than anybody's fault.
Memory is the easiest thing to sell. It is one number, it compares cleanly between providers, and it sounds like capacity. Clock speed requires looking up a CPU model and understanding what boost means, so hosting pages lead with the thing that fits in a headline.
More memory does fix one specific problem, which keeps the belief alive. A server running out of heap crashes with an OutOfMemoryError, and adding memory fixes it. That case is real and it is much rarer than the number of times the advice is given.
The result is that "add more RAM" is the first suggestion in almost every discussion of server performance, it works occasionally, and the occasions are remembered while the times it changed nothing are not.
Checking your own configuration
Three things, in about two minutes.
Find the startup command. On a panel it is the startup parameters; on a machine it is the systemd unit or the start script. Read what -Xms and -Xmx are set to, because a surprising number of servers are running defaults nobody chose.
Compare -Xmx to the machine's memory. If they are equal, the process will be killed eventually.
Check the Java version with java -version. An old default JVM is a free performance loss and a one-line fix.
If all three are sensible, memory is not your problem and the entity, chunk and plugin checks are where to look next.
Common questions
- Why does a Minecraft server crash without any errors in the server log?
- The operating system likely killed the process for exceeding physical memory. When -Xmx is set larger than the machine's actual RAM, or when the heap leaves no memory for the operating system and JVM overhead, the kernel kills the process with nothing recorded in the server log.
- How can I tell if garbage collection is causing lag spikes?
- Turn on GC logging for an hour to track pause times. Pauses under thirty milliseconds are invisible to players, but pauses over one hundred milliseconds cause noticeable lag spikes. If your TPS drops do not align with these long collection pauses, memory is not your issue.
- Why did my server stop starting after updating its startup flags?
- You likely copied flags designed for an incompatible Java version. Flag sets written for Java 8 do not work properly on Java 17 or 21, and certain flags have been removed entirely from newer versions.
Published · 7 min read