How to Fix Minecraft Server Lag and Low TPS
Lag is a symptom, not a cause. Here is the order that actually finds the culprit — TPS and MSPT first, then chunks, entities, plugins and finally JVM settings.
"The server is lagging" can mean two completely different problems: the world is ticking slowly (server lag), or your connection to it is bad (network lag). They have different fixes, and guessing wastes an evening. Start by measuring, because every good fix starts with one number: TPS.
Read the two numbers that matter
- TPS (ticks per second) — Minecraft aims for 20. At 19.8–20 everything is normal. Below 18 you will feel it: mobs stutter, blocks reappear after you break them, food takes forever to eat. Below 10 the server is effectively frozen even though players may still be able to walk around.
- MSPT (milliseconds per tick) — how long the server takes to compute one tick, and the much sharper diagnostic. 20 TPS = 50 ms per tick. If MSPT sits above 50 ms, you are behind. If a single tick takes 200 ms, you have found a spike.
On Paper, run /tps and /mspt in game, or read them in the panel console. For anything
deeper, Paper bundles spark, the modern replacement for the old timings report:
/spark tps for a live view and /spark profiler start … /spark profiler stop
to catch what the server is actually doing during a lag spell. It produces a shareable link that points at the
exact method costing you milliseconds.
Also check whether it is you. Look at your in-game ping (F3 or the player list). If TPS is flat at 20 and only your screen stutters, the server is fine — it is your connection, your FPS, or a client-side mod.
The quick wins, in order of impact
| Change | Where | Why it works |
|---|---|---|
| Lower simulation distance to 4–6 | server.properties / config/paper-world-defaults.yml |
Simulation distance decides how far mobs, redstone and block ticks run. It is the single biggest cost on any server. |
| View distance 6–8 | same files | View distance is mostly memory and bandwidth; simulation is CPU. Lowering both keeps a 5 GB node comfortable. |
| Pre-generate the world | Chunky: /chunky radius 1500, /chunky start |
Chunk generation is hugely expensive and happens exactly when players explore. Generate it once, offline, and exploring becomes a read operation. |
| Cut heavy plugins | Plugins tab | Map renderers (Dynmap, BlueMap), big shop suites and anything that scans chunks on a timer are the usual suspects on small plans. |
| Tame entity load | In game / configs | Thousands of dropped items, mob-farm overflow and item frames are entity-load problems, not RAM problems. |
| Trim the world's hotspots | In game | One oversized redstone contraption or a hopper array spanning chunks can cost more than ten players. |
RAM is usually not the problem (and adding it is not the fix)
On a 5 GB plan the JVM is already configured to use most of that memory, with an efficient garbage collector. If MSPT is high while the panel's memory graph is comfortably below the limit, more RAM would change nothing — the bottleneck is CPU work per tick, which is exactly what the settings above address.
The opposite is also true: a 5 GB server running twenty heavy plugins will spend real time in garbage collection,
which shows up as periodic MSPT spikes every few minutes rather than constant lag. If your profile looks like
sawteeth, remove plugins and shrink the world before you touch anything else. Do not add -Xmx flags by
hand in the startup command — the panel sizes the heap from your plan automatically, and overriding it usually
makes things worse.
Chunk generation and entity overload
Two patterns explain most "it was fine yesterday" lag:
- Exploration. New chunks are the most expensive thing a Minecraft server does. If lag appears
only when someone travels to new territory, pre-generate the area with Chunky
(
/chunky radius 1500then/chunky start) — it is far cheaper to generate a chunk once while the server is empty than while five people are playing. - Entities. Dropped items, mob-farm overflow, boats, armour stands and item frames all tick. Check the entity count in spark, then reduce the source: unload farm chunks, add a simple item-despawn schedule, cap mob-farm output, and clear leftovers after a big build session.
Find the guilty plugin by halving
If the settings are sane and lag started after you added something, bisect: disable half of your plugins, restart and observe. If the lag is gone, the culprit is in the half you disabled — re-enable half of that, and repeat three or four times. In ten minutes you will have one plugin name, which beats arguing about "the host being slow" for two days. Read the console during the test as well: a plugin spamming stack traces is a plugin costing you ticks.
When the world itself is the problem
Some lag is baked into the save file: a corrupted chunk, a mob stuck in a ticking block, or a redstone loop that
never settles. The console gives it away with lines such as Ticking entity or
Failed to load chunk including coordinates. Note the coordinates, keep players away from that area, and
either restore a backup of the world from before it started, or remove the offending build. This is also the moment
to remind yourself that a downloaded world ZIP on your own computer is the only backup that survives everything —
see uploading a world for how to move
one back in.
The 10-minute prevention checklist
- Simulation distance 4–6, view distance 6–8.
- Spawn area and travel routes pre-generated.
- No map renderer and no chunk-scanning plugin on a 5 GB plan.
- Redstone and hopper farms kept inside a small number of chunks.
- Entity count watched after big builds; leftovers cleaned up.
/spark profilerbookmarked for the next time it happens — evidence beats guessing.
If you get through all of that and MSPT still will not sit under 50 ms, open a ticket from
the contact page with your /spark link and the server's node name,
and we will look at the node side with you.
Updated 22 September 2026. Spotted something out of date? Tell us on Discord or email support@sadhost.com and we will fix it.