Why Your Minecraft Server Lags, in Order of Likelihood

A Minecraft server that "lags" is almost never short of hardware. It is usually running one thing badly, and there are about eight candidates.

The word itself is the first problem: players say lag for two different failures, and they need opposite fixes. Getting the diagnosis right takes about five minutes and saves buying a machine that will not help.

Two different problems with one name

Server-side lag is the world falling behind. Blocks break and come back. Mobs stutter. Items take a moment to appear. Everyone experiences it at once, and it does not matter where they are.

The measurement is milliseconds per tick, and the server reports it. /tps on most plugin platforms, or the built-in tick report. The budget is 50 ms, twenty ticks a second. Under 50 and the server is keeping up; over it and it is not, and 20 TPS drops to 15 or 10.

Client-side or network lag is your connection or your machine. Rubber-banding for one player while others are fine, or a stable server with a bad route. Ping and latency covers that side, and it is not what this article is about.

If /tps says 20.0 and players say lag, the server is fine and the problem is somewhere between it and them.

The eight causes, in the order they occur

1. Entities

The most common by a distance. Dropped items, mobs, minecarts, armour stands, boats. Each one is simulated every tick.

The specific killers are item drops from a farm nobody harvests, mob farms running while their owner is offline, and thousands of dropped items in one chunk after somebody died.

Find them before guessing at anything else. Most platforms have a command to count entities per chunk, and the answer is frequently one chunk with several thousand in it.

2. Redstone and hoppers

Hoppers check for items constantly, whether or not anything is there. A storage system with four hundred hoppers is four hundred checks per tick, forever.

Clocks are the other half. A redstone clock left running is a permanent load, and long-abandoned bases are full of them.

3. Chunk loading

Every chunk kept loaded costs simulation. Chunk loaders, players spread across the map, and portals holding chunks open all add up.

A server with twenty players in twenty different places is doing considerably more work than one with twenty players in one town, and this is why population alone is a poor predictor of load.

4. A single plugin

Frequently one plugin doing something expensive on an event that fires constantly: every block place, every move, every tick.

The way to find it is a profiler rather than a guess. Spark is the standard tool on plugin platforms and it will name the plugin and the method. Ten minutes with it beats a week of disabling things.

5. World size on disk

A world that has grown to tens of gigabytes because everyone explored in a straight line costs disk reads on every chunk load. Pre-generating the world within a border is the fix, and a world border is the prevention.

6. View distance

The single most effective setting, and the one most owners never touch. View distance of 10 means each player loads a 21×21 chunk area. Dropping to 6 or 7 cuts the work substantially and most players do not notice on a survival server.

Simulation distance is the more important half on modern versions: it controls how far entities tick, and it can safely be lower than view distance.

7. Garbage collection

Java pauses to reclaim memory, and a badly configured heap turns that into a visible freeze. This is where the RAM myth comes from: more memory does not make the server faster, and too much memory makes pauses longer.

RAM, heap and Java flags covers this properly. The short version is that 6 to 8 GB is right for most servers and 32 GB is usually worse than 8.

8. Hardware, last

Only after the above. And when it is hardware, it is nearly always single-core speed rather than core count, because the main tick is one thread. More cores will not fix your server is the longer argument, and what the hardware actually needs is the other half that people skip.

A diagnostic sequence that works

1. Check /tps. If it is 20, the server is not the problem.
2. Run a profiler under load. Spark, for a minute, while it is bad. This alone identifies the cause on most servers.
3. Count entities per chunk. Look for the outlier.
4. Check whether it correlates with player count. If it does not, something is running regardless of who is online, which points at farms, clocks or a scheduled task.
5. Check disk and memory. df -h, free -h. A full disk produces failures that look like anything else, reading server logs covers the rest.
6. Only then consider the machine.

The step people skip is two, and it is the one that answers the question.

The settings worth changing on day one

Most of these ship at defaults chosen for a single-player world.

View distance to 7, simulation distance to 5 or 6. Reversible in a minute if anyone objects.

Entity limits per chunk, most platforms let you cap mobs and item stacks per chunk. Set them.

Item merge radius slightly higher, so dropped stacks combine rather than sitting as hundreds of separate entities.

A world border. Even a generous one. An unbounded world is an unbounded disk and an unbounded chunk count. Pre-generate inside it.

Mob spawn limits downward. Default spawn caps are generous and mobs are the largest entity category on most servers.

Autosave interval lengthened slightly, so the save stutter happens less often. Not too far; backups and saves are what stand between you and losing a day.

Server software matters

Vanilla is the slowest option and has no configuration to speak of. Paper and its derivatives exist substantially to make the above tunable, and the performance difference on a populated server is not subtle.

Paper, Purpur or Fabric covers the choice. For a plugin server the answer is nearly always Paper or something built on it, and moving from Spigot to Paper is one of the cheapest performance improvements available.

Modded servers are a different situation: Fabric and Forge performance depends heavily on which mods are installed, and the profiling step matters more rather than less.

What players notice

Worth knowing, because it decides what to fix first.

Players notice block lag immediately, breaking a block and watching it reappear is the most reported symptom and usually means the server is missing tick budget.

They notice mob stutter next.

They rarely notice a TPS of 19.6, and they always notice 15.

They do not notice memory usage, disk size or your core count, which is why those make poor targets and good excuses.

If your server is at 20 TPS and someone reports lag, the honest answer is that the problem is not on the server, and what a server list measures explains why response time on a listing does not answer it either: that figure is measured from a datacentre, not from the player complaining.

The pattern underneath all of it

Minecraft servers do not degrade because they are undersized. They degrade because things accumulate: entities that nobody clears, hoppers nobody removed, chunks nobody unloaded, plugins nobody audited after an update.

That makes performance a maintenance habit rather than a purchase. Twenty minutes with a profiler once a quarter catches almost everything on this page, and it is considerably cheaper than the machine you were about to rent.

What to do this week

If your server is struggling and you want an order of operations rather than a list of causes:

Today. Run a profiler under load for sixty seconds. Read what it names. This single step identifies the cause on most servers and takes less time than reading about it.

Today. Drop view distance to 7 and simulation distance to 5. Reversible in a minute, noticeable immediately, and free.

This week. Count entities per chunk and deal with the outlier. Set entity limits so it cannot recur.

This week. Set a world border and pre-generate inside it, if you have not.

This month. Audit the plugin list and remove what nobody uses. Every plugin is both a performance cost and a future breakage, updating without breaking things covers the second half.

Only then. Consider hardware, and when you do, buy clock speed rather than cores. More cores will not fix your server is the argument.

Most servers stop at step one because the profiler names something specific and obvious, which is the entire reason to start there rather than with the machine.

Everything on this page assumes the server is behind. If /tps reads 20.0 and a player still reports lag, nothing here applies — the problem is between the server and them, and ping and latency is the article that covers it.