Tuning RAM and JVM Flags (Aikar's Flags) to Cut Minecraft Lag

A stuttering Minecraft server with dropping TPS is not always caused by too little RAM. Very often the culprit is a poorly configured Java Virtual Machine (JVM) that produces long Garbage Collection (GC) pauses players feel as freezes. This guide explains how to allocate RAM correctly, set -Xms and -Xmx properly, and apply the popular parameter set known as Aikar's Flags so your Paper/Spigot server runs as smoothly as possible.

Why More RAM Does Not Always Mean Smoother

The belief that "more RAM is always better" is the most common misconception. Giving the JVM an oversized heap forces the garbage collector to sweep a huge chunk of memory each cycle, producing longer pauses, not shorter ones. Moreover, Minecraft performance is mostly limited by single-thread CPU speed rather than RAM, because the world tick logic runs on a single main thread.

Understanding -Xms and -Xmx Completely

These two parameters are the heart of JVM memory allocation:

• -Xms = the initial heap size the JVM reserves immediately on startup
• -Xmx = the maximum heap size the JVM is allowed to grow to

Always Set Them Equal

For game servers you should always set -Xms equal to -Xmx. If they differ, the JVM grows the heap gradually whenever it needs more memory, and each heap resize causes a pause that players perceive as a stutter. Setting them equal from the start means the JVM reserves the full space immediately and never has to resize.

Do Not Give All System RAM to the JVM

A serious mistake is setting -Xmx equal to the machine's total RAM. Beyond the heap, Java uses off-heap memory (Metaspace, thread stacks, native buffers) and the operating system needs RAM too. Always leave roughly 1-2GB for the OS plus Minecraft's off-heap usage.

Aikar's Flags: The Standard Parameter Set

Aikar's Flags is a JVM parameter set developed by Aikar (a PaperMC developer) that tunes the G1 Garbage Collector specifically for Minecraft workloads, prioritizing short GC pauses over raw throughput. Here is the set for a heap of up to 12GB:

java -Xms4G -Xmx4G -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 -jar paper.jar --nogui

Meaning of the key flags:

• -XX:+UseG1GC uses the G1 Garbage Collector, designed for short pauses
• -XX:MaxGCPauseMillis=200 targets pauses of no more than 200ms
• -XX:+AlwaysPreTouch touches all memory at startup so RAM is truly committed and page faults are reduced at runtime
• -XX:+DisableExplicitGC prevents plugins from calling System.gc() and triggering needless full GCs

Adjusting Flags When RAM Exceeds 12GB

If you allocate more than 12GB of heap (for example, a large modded server), Aikar recommends adjusting several parameters so G1GC handles the larger heap more effectively:

-XX:G1NewSizePercent=40 -XX:G1MaxNewSizePercent=50 -XX:G1HeapRegionSize=16M -XX:G1ReservePercent=15 -XX:InitiatingHeapOccupancyPercent=20 -XX:G1MixedGCCountTarget=8

The reasoning: a larger heap needs a larger young generation (higher G1NewSizePercent/G1MaxNewSizePercent) and larger regions (G1HeapRegionSize=16M) to reduce the number of regions GC must manage. Meanwhile InitiatingHeapOccupancyPercent=20 lets the heap fill more before starting a concurrent cycle, which suits big heaps.

TPS and MSPT: The Real Metrics

Do not measure smoothness by feel; look at the real numbers:

• TPS (Ticks Per Second) the target is 20 ticks/second. Below that means the server cannot keep up and the game slows down.
• MSPT (Milliseconds Per Tick) the time to process each tick should stay under 50ms (because 1000ms / 20 ticks = 50ms). Above 50ms and TPS starts to drop.

Diagnose with /spark or /timings

Use the /spark plugin (recommended) or the /timings command to profile what consumes the most tick time, such as too many entities, heavy redstone, or a specific plugin. These reports tell you whether the problem is RAM/GC or is CPU-bound.

Recommended RAM by Player Count

The figures below are the heap size you should allocate to the JVM (the Xmx value), not the total VPS RAM. Remember to leave 1-2GB for the OS:

Player Count	Server Type	Recommended Heap (Xmx)
1-5 players	Vanilla/Paper	2-3GB
5-15 players	Paper + plugins	4GB
15-30 players	Paper + many plugins	6-8GB
Modded (Forge/Fabric)	large modpack	8-16GB+

Modded servers with large modpacks consume several times more RAM than vanilla because they load many mods and generate more complex worlds.

Choosing a VPS Suited to Minecraft

Because Minecraft relies mainly on per-core (single-thread) CPU performance, choose a VPS by CPU speed per core rather than by a high core count. AsiaGB offers Linux VPS plans starting at 500 THB/month, using SSD storage managed through DirectAdmin, with 99% uptime that is sufficient for small to mid-sized servers. Pick a plan that leaves RAM for the OS while still providing enough heap for the table above.

Tuning Workflow in Summary

1. Estimate your player count and server type, then pick a heap from the table
2. Always set -Xms equal to -Xmx and leave 1-2GB for the OS
3. Apply the full set of Aikar's Flags (adjusted for heap over 12GB)
4. Run and monitor TPS/MSPT with /spark
5. If lag persists despite sufficient RAM, look for a CPU-bound issue instead of adding RAM

Correct tuning is not about cramming in the most RAM; it is about allocating just enough and letting G1GC work efficiently, paired with a CPU that is strong per core.

Frequently Asked Questions

Should I set Xms and Xmx equal?

Yes, always set them equal so the JVM reserves the full heap at startup and never resizes mid-run, which would cause stutter-inducing pauses.

Will giving lots of RAM really make my server smoother?

Not always. An oversized heap lengthens GC pauses, and if the problem is CPU-bound, adding RAM will not raise TPS at all.

What is the difference between TPS and MSPT?

TPS is ticks per second with a target of 20, while MSPT is time per tick and should stay under 50ms; if MSPT exceeds 50ms, TPS is starting to drop.

How do I tell if lag is from RAM or from the CPU?

Use /spark or /timings; if RAM is free with no long GC pauses yet TPS still drops, it is CPU-bound and you must reduce main-thread load.