Why Is My Minecraft Server Lagging and How to Fix It

If you're wondering why your Minecraft server is lagging, 90% of the time it comes down to one of six things: not enough RAM and garbage collection, a weak CPU core, heavy plugins, mobs and farms, a slow disk, or too high a view-distance. The good news is that almost all of it can be diagnosed with a couple of commands and fixed without reinstalling the world. Let's go through it step by step: how to measure the lag, find the culprit, and get rid of it.

First figure out: is it server lag or client lag?

Before you fix anything, you need to know where the problem actually is. "Lag" is too broad a word, and players often confuse three different things.

• Server lag — TPS drops. The world slows down for everyone at once: mobs stutter, hits don't register, blocks break with a delay. This is what you, as the admin, can actually fix.
• Client stutter (low FPS) — the picture jerks for one player only. The blame is on their PC, GPU or shaders, not the server.
• Ping (network lag) — the delay between a player and the server. The player feels "rubber-banding," but TPS on the server is still 20.0. The cure is picking a closer location.

A simple test: join the server and type /tps. If it reads a steady 20.0 and someone is complaining about lag, the problem is on their end (PC or internet), not yours. If TPS has dropped — welcome aboard, the rest of this is about you.

TPS and MSPT: two numbers you need to understand

A Minecraft server runs on ticks — these are the "frames" of game logic. Exactly 20 ticks should pass per second, and the server has to process each tick in 50 milliseconds or less (1000 ms / 20 = 50). That gives you two key metrics.

MSPT is the more honest and sensitive metric. TPS can't exceed 20, so on a "healthy" server it always reads 20.0 and tells you nothing about your safety margin. MSPT shows the truth: if a tick takes 45 ms, your TPS is still 20, but there's almost no headroom left — one spike and the server starts choking. So watch MSPT in particular: the lower and steadier it is, the more room you have to grow your player count.

How to measure lag: spark, /tps and /mspt

Guessing the cause of lag is a dead end. You need to measure. On Paper-family cores (including Purpur) there are built-in commands and a profiler.

Quick check

/tps     # average TPS over 5s / 1m / 5m / 15m
/mspt    # average, minimum and maximum MSPT over recent ticks

/tps shows four numbers — the instantaneous value and averages over each interval. If the last one (15 min) is low, the lag is chronic. If only the instantaneous TPS dips, you have short spikes rather than a constant drop, and you should be looking for a one-off event (a creeper blowing up in a redstone build, a new player loading chunks).

The spark profiler — your main tool

Diagnostics used to rely on /timings, but in modern Paper, timings is disabled and replaced by spark — that's the recommendation of the Paper developers themselves. Spark takes a sampling profile of the main thread and shows you exactly which code is eating tick time.

/spark profiler start
# ... wait 3-5 minutes under normal load ...
/spark profiler stop      # gives you a link to the report

# for rare spikes — profile only the heavy ticks:
/spark profiler start --only-ticks-over 60

In the report you'll see a call tree: for example, that 40% of the time goes to EntityLiving.tick (mobs) or to a specific plugin. That's your culprit. On top of that, /spark health shows CPU usage and memory consumption. Not sure how to read a flame graph? Start with the "thickest" branches at the top — they're eating the most time.

Cause 1. Not enough RAM and garbage collection (GC)

The most common — and most insidious — cause of lag isn't a lack of memory in itself, but garbage-collector pauses. When the server is short on heap, the JVM constantly fires off Garbage Collection to free up space. Each of those collections is a micro-freeze: the main thread halts, the tick stretches out, and TPS drops. From the outside it looks like rhythmic lag spikes every few seconds.

The paradox is that too much RAM hurts too: the bigger the heap, the longer a single large garbage collection takes. So the goal is to allocate "just right" for your pack and player count. For vanilla and Paper with 5–10 players, 4–6 GB is usually enough; a mid-size modpack asks for 8–12 GB; heavy packs need more. We worked out the exact calculation by version, loader and player count in our guide on how much RAM a Minecraft server needs.

The key to taming GC is the right JVM flags. Aikar's flags tune the G1GC collector so pauses stay short and predictable (the target is MaxGCPauseMillis=200) and memory is freed ahead of time rather than at the moment of peak load. It's a free boost to stability — just add the flags to your startup line.

Cause 2. A weak CPU core

Remember the main thing about Minecraft: it's almost entirely single-threaded. All the core game logic — mobs, redstone, generation, block ticks — runs on a single thread. That means the server doesn't care about "many cores," it cares about the speed and strength of one core. An eight-core processor with weak cores will lose to a four-core one with a high clock speed.

That's why a server can lag with tons of free RAM: it isn't memory-bound, it's hitting the ceiling of a single core. MSPT climbs because the core physically can't process a tick in 50 ms. This hits cheap VPS hosting especially hard, where old server-grade processors with low clock speeds are crammed in — and split among a dozen clients on top of that.

Cause 3. Heavy plugins and mods

Every plugin and every mod runs code on that same main thread. A single poorly written plugin (especially one with frequent region checks, inventory scans, or synchronous database queries) can tank TPS all by itself. Mods are more dangerous than plugins: a heavy tech modpack adds thousands of new entities, machines and world ticks.

Here spark comes to the rescue again: in the report, plugins and mods show up by name with their share of tick time. The process is simple:

1. Take a profile and find the name of the plugin/mod hog in the call tree.
2. Disable it, restart, and compare MSPT.
3. If things got noticeably better, look for a replacement, update to a fresh version, or tune the intervals of its tasks.

For modpacks, hardware and memory matter especially — we explained why in our roundup of hosting for modpacks. And it doesn't matter whether you're on Forge or Fabric: optimization mods exist for both loaders, and they deliver a huge win (more on that below).

Cause 4. Mobs, farms and redstone

Entities are the classic TPS killer. Every mob, every item on the ground, every item frame and minecart ticks every game tick. When hundreds of mobs, giant mob farms and dozens of active hoppers pile up on a server, the main thread simply can't process it all.

• Hopper lag. Hoppers are among the most expensive block ticks. Sorting systems on hundreds of hoppers burn through MSPT. Minimize the number of active hoppers, and use filters and water streams instead of long chains.
• Mob farms. Huge farms with thousands of loaded mobs are a frequent cause of spikes. Cap the height and use timer-based killing.
• Redstone circuits. Clock generators and large automatic builds tick non-stop. One forgotten clock in the corner of the map can quietly eat TPS for months.
• Item buildup. Dropped items that no one picks up accumulate in the thousands. Set up auto-cleanup (merge-radius, item caps).

On Paper/Purpur cores there are fine-grained limits in spigot.yml and paper-world-defaults.yml: mob-spawn-range, per-chunk mob limits, entity ticking. Lower them and the MSPT from mobs will drop noticeably.

Cause 5. Chunk generation and the disk

When a player heads off into unexplored land, the server generates new chunks on the fly — a heavy operation for both the CPU and the disk. And every world save writes data to storage. If the host uses slow HDDs, reading and writing chunks becomes a bottleneck: you get lag spikes when players move around and during auto-save.

On NVMe drives (especially Gen4 with read speeds around 7 GB/s) this problem practically disappears: chunks load instantly, and you don't even notice the world save. If the lag coincides specifically with exploring new territory or with auto-saving, take a closer look at the host's disk.

Cause 6. Too high a view-distance and simulation-distance

Two settings in server.properties directly multiply the load:

view-distance=10          # how many chunks a player can see
simulation-distance=10    # within how many chunks logic ticks

simulation-distance is especially expensive: the higher it is, the larger the radius in which mobs, redstone and farms tick around each player. Dropping it from 10 to 6–8 often gives a noticeable TPS boost on a busy server with almost no hit to gameplay. view-distance affects networking and generation — it's worth keeping that in a sensible 8–10 range too. We put together a full breakdown of every setting in our article on configuring server.properties.

How to fix it: a checklist of solutions

Let's pull it all together. We'll go from the simplest and cheapest to the more serious:

1. Apply Aikar's flags. The fastest free win against GC spikes — drop the ready-made flag string into your startup.
2. Switch to Paper or Purpur. If you're still on Vanilla or Spigot, switching gives you entity, redstone and hopper optimizations plus dozens of limit settings. There's a comparison in our guide Paper vs Purpur vs Vanilla.
3. Install optimization mods. On Fabric — Lithium (world logic); on modern Forge/NeoForge there are ports and equivalents. They rewrite the bottlenecks without changing gameplay.
4. Take a spark profile and remove the specific hog — a plugin, a mod or a farm.
5. Limit mobs and farms: config limits, item auto-cleanup, an audit of your redstone circuits.
6. Lower simulation-distance to 6–8 and pre-generate the world ahead of time.

When the host is to blame, not you

Sometimes you've done everything right — optimized plugins, applied the flags, trimmed the farms and view-distance — and MSPT is still high no matter what you do. Then it's the host's hardware. Three classic signs of bad hosting:

These are exactly the corners cheap hosting cuts, and you're the one left up half the night reading spark reports, not understanding why your Minecraft server is lagging with perfect configs.

And remember: lag is almost always a solvable problem. Start with /mspt and spark, find the culprit by the numbers rather than by feel — and your server will run at an honest 20 TPS again. If you're just getting started, take a look at the big guide on how to create a Minecraft server: it lays everything out from scratch, including a proper launch with no future lag.