Your server lags at 21:00: how to find the actual cause

"The server is lagging" describes a symptom that has at least six unrelated causes, three of which are not on the server at all. Guessing between them is how people end up paying for an upgrade that changes nothing.

This is a diagnosis order. It starts with the question almost everyone skips.

First: is it the server, or is it you?

Before touching anything, check three things in the game.

Press F3. Top left shows your client FPS, and the right side shows your ping to the server.

• Low FPS, fine ping. Your computer is struggling to draw the world. Nothing on the server will fix this. Lower your render distance, turn off fancy graphics, or install Sodium.
• Fine FPS, high or erratic ping. A network problem between you and the server. If you are on wifi, plug in and test again before doing anything else. Wifi introduces more jitter than the entire rest of the route, and this is the single most common misdiagnosis in game hosting.
• Fine FPS, fine ping, world still stuttering. Now it is the server, and the rest of this applies.

There is a fourth case worth naming: everything is fine for you and terrible for one other player. That is their connection, and no server-side change will help.

The number that matters is MSPT, not TPS

Everybody quotes TPS. MSPT is more useful.

A Minecraft server does a fixed amount of work twenty times a second. Each of those ticks has a budget of 50 milliseconds. MSPT is how long a tick actually took.

• MSPT comfortably under 50: the server finishes its work and idles until the next tick. TPS reads 20.
• MSPT above 50: ticks run late, and TPS falls.

The reason MSPT is the better number is that TPS hides how close you are to the edge. A server at 45 MSPT and a server at 15 MSPT both report a perfect 20 TPS. The first one falls over when three more players log in; the second has room. If you only watch TPS, you get no warning at all, right up until the evening it breaks.

Install spark and run:

/spark tps
/spark health

/spark health gives TPS, MSPT, CPU and memory in one view. Look at the MSPT percentiles rather than the average: a median of 20 ms with a 95th percentile of 120 ms means most ticks are fine and some are catastrophic, which players experience as stuttering rather than as consistent slowness.

Then: profile, do not guess

Guessing which plugin is responsible is a waste of an evening. Profile it during the problem:

/spark profiler start

Let it run while the server is actually struggling. Ten minutes at 21:00 is worth far more than an hour at 04:00, because you want to capture the condition you are trying to fix. Then:

/spark profiler stop

You get a link to a flame graph. Read it top down: the widest blocks are where time is going. You are looking for a name you recognise, and it is usually one of the following.

The usual culprits, in order of likelihood

Entities

Mobs, dropped items, item frames, minecarts, armour stands. Every one is tracked every tick, and the cost is linear in count.

This is the most common cause by a wide margin, and it is usually something a player built. A mob farm holding four thousand entities in a chunk will destroy tick time on its own. So will a few hundred dropped items nobody picked up, or an item sorter with two hundred hoppers.

The giveaway in a profile is time in entity ticking or ServerLevel.tickNonPassenger. Find the location, then talk to whoever built it. Most players will happily redesign a farm if you explain why; most will rebuild it next week if you just delete it without saying anything.

View distance and chunk loading

Loaded chunks cost memory and tick time, and the relationship with view distance is roughly quadratic. Going from 10 to 6 does not cut the loaded area by 40%, it cuts it by about two thirds.

Reducing view-distance in server.properties is the single most effective change available to most servers, and players rarely notice it going from 10 to 8. Set simulation-distance lower still: it controls how far mobs and redstone actually run, and it can usually sit at 4 or 5 without anyone perceiving a difference.

Chunk generation is a separate cost. If a profile shows heavy chunk work, someone is exploring new terrain, and pre-generating the world with a plugin like Chunky during quiet hours turns an ongoing tax into a one-off.

Hoppers

Hoppers poll. Every hopper checks for items it could move, repeatedly, whether or not anything is there. A large sorting system is a permanent background load that scales with the number of hoppers rather than with how much they actually move.

Paper's config can reduce this, and replacing long hopper chains with water streams or minecart hoppers helps more. This is a very common hidden cost on established survival servers, precisely because it grows quietly as players build.

Redstone

Clocks left running, flying machines, large computational contraptions. Redstone is cheap per component and expensive in aggregate, and an abandoned clock somewhere in a loaded chunk costs you every tick forever.

A specific plugin

Sometimes it really is a plugin, and the profile names it directly. The usual pattern is a plugin doing synchronous file or database I/O on the main thread: a logging plugin on SQLite instead of MySQL, a web map rendering while players are online, an economy plugin saving on every transaction.

Fixes vary, but three cover most cases: move it to a proper database backend, schedule its heavy work for off-peak hours, or replace it with an async alternative.

Memory pressure

If the profile shows a lot of time in garbage collection, and the server freezes for a second or two rather than running consistently slowly, you are short of memory rather than short of CPU.

That is the one case where a larger plan genuinely fixes the problem. It is also, in my experience, the least common of these six, which is unfortunate given it is the one most people try first.

Why 21:00 specifically

Two reasons, and they call for opposite responses.

More players. Each player loads chunks around themselves, and players who spread out cost far more than players who cluster. If MSPT rises smoothly with player count and everything else looks clean, you are simply at the capacity of your configuration and the fixes above buy you headroom.

Somebody else's server. If your server slows at peak hours and a profile shows nothing unusual inside it, the CPU may be contended by other customers on the same node. On an oversold host this is invisible to you and unfixable by you, which is exactly why the reservation figure on this site is published and why the node stops selling when it is full. It is also, bluntly, the failure mode that a profiler cannot diagnose from inside your server: if the numbers inside look fine and it is still slow, ask your host what the host machine is doing.

The order to work through it

1. F3 in game. Client FPS and ping, wired not wifi.
2. /spark health. Is MSPT actually over 50, and how bad is the 95th percentile?
3. /spark profiler start during the problem, not after it.
4. Read the flame graph top down. Entities first, chunks second, hoppers third.
5. Lower view-distance and simulation-distance before spending money. It is free and it is usually the biggest single win.
6. Only then consider more RAM, and only if the profile shows garbage collection pressure. There is a longer piece on sizing that goes into when memory is and is not the answer.

Most lag turns out to be a farm somebody built three weeks ago. It is very rarely the thing you would have guessed, which is the entire argument for profiling rather than upgrading.