Start with the right mental model
When admins say “the server lags”, they often mix several problems together:
- low TPS
- high MSPT
- chunk generation spikes
- plugin slowdowns
- network problems that only feel like lag
The useful part is this:
- the server tries to run 20 ticks per second
- that means it has 50 ms per tick on average
If your average tick time exceeds that budget, TPS begins to fall and the server may log messages such as Can't keep up!.
What TPS and MSPT actually tell you
TPS
TPS means ticks per second. At the target rate, the server reaches 20 TPS.
MSPT
MSPT means milliseconds per tick. This is often the more actionable number because it shows how much time the server needs to process game logic.
As a practical rule:
- around or below 50 ms average tick time is where the server can still sustain 20 TPS
- above that, the server begins to fall behind
First checks before you change any settings
Do these in order:
- confirm that the issue is active right now
- measure instead of guessing
- change one thing at a time
On Paper 1.21 and newer, start with Spark because it is bundled and is the preferred profiler:
/spark tps
/spark profiler start --timeout 600
If you are not on Paper yet, read Paper vs Vanilla vs Fabric vs Forge before assuming your current server software is the best base for performance work.
The usual causes of lag
1. CPU-bound ticks
Minecraft server work is still very sensitive to single-thread performance. If one heavy tick phase takes too long, more RAM will not save you.
2. Chunk generation and exploration
Fast exploration creates chunk generation work. This often appears as spikes instead of constant low TPS.
3. Too much simulation
Paper documents simulation-distance separately from view-distance.
That matters because entity ticking and active game logic are not the same as what the client can see.
4. Plugin or mod behavior
A laggy server is often not “Minecraft being Minecraft”. It is often one plugin, one task, or one badly scaled feature.
5. Entity-heavy farms and villages
Large mob farms, dense villager trading halls, and constant hopper activity can dominate tick time.
Safe fix order
Do not start with random config packs. The safer order is:
- measure with Spark
- identify whether the issue is persistent or spiky
- reduce the most expensive source first
- only then tune Paper distances
That is how you avoid cargo-cult fixes.
Fast decisions that are usually safe
- reduce
simulation-distancebefore slashing everything else blindly - keep
view-distancereasonable for your player count and hardware - test changes during the actual lag scenario, not only on an empty server
For concrete values, continue with View Distance vs Simulation Distance: Safe Starting Values for Paper.
Common mistakes
| Mistake | Why it fails | Better move |
|---|---|---|
| Raising RAM first | CPU or tick problems stay untouched | Measure MSPT and profile first |
| Tuning configs without active lag | You optimize the wrong moment | Capture data while the problem is happening |
| Changing five settings at once | You lose the causal signal | Make one meaningful change at a time |
| Ignoring server software choice | Vanilla gives you fewer diagnostics and fewer performance options | Consider Paper for operational clarity |
FAQ
Is “Can’t keep up” always a disaster?
No. A single spike can happen during world generation or startup. The pattern matters more than one isolated message.
Should I lower both distances immediately?
Not automatically. First determine whether chunk visibility, active simulation, entities, or a plugin is actually driving the tick cost.
Next steps
- Capture the real bottleneck with Spark Profiler Step by Step for Paper and Docker.
- Tune safe chunk-related settings in the view-distance vs simulation-distance guide.
- If you are still on the wrong server software for your goals, read Paper vs Vanilla vs Fabric vs Forge.