Understanding Minecraft Server TPS: Why Your World Lags and How to Fix It
By Benjamin D. · PDG
· 8 min read

Contents
Minecraft server TPS counts how many game ticks the world completes each second, and 20 is the hard ceiling. Below that figure the world runs in slow motion: mobs stutter, crops grow late, hoppers crawl, and clocks drift. Tick lag almost always traces back to entities, chunk loading, redstone or an oversized view distance, and each leaves a clear signature in a profiler report.
How ticks work and why 20 is the ceiling
The Minecraft world advances in discrete steps called ticks. Every tick the server moves entities, applies physics, grows crops, processes redstone, spawns mobs, saves chunks and answers packets from clients. When all of that finishes in under 50 milliseconds, the loop waits and you get a steady 20 ticks per second.
The 50 millisecond budget
Fifty milliseconds is the whole budget for one tick. Go over it and the next tick starts late, so the effective rate drops to 18, 15 or 8. The server never speeds up to catch up: lost time is lost gameplay. That is why a value above 20 is impossible and why 19.9 already means something is eating the loop.
TPS and MSPT do not say the same thing
TPS is an average, MSPT is the actual time a tick took. A world sitting at 20 TPS with 47 MSPT is one mob farm away from collapsing, while a world at 20 TPS with 12 MSPT has real headroom. Track MSPT first: it warns you days before players notice anything.
Tick time depends mostly on single-thread performance, so CPU frequency and cache matter far more than raw core count. That is the first specification worth checking with Minecraft server hosting built on a Ryzen 9 7950X3D with DDR5 ECC memory and NVMe storage, where chunk writes never block the main thread.
Spotting tick lag before players complain
Players report symptoms, not causes. Learning to map the symptom to the subsystem saves hours of blind configuration edits.
- Mobs sliding or teleporting: tick rate is low, movement packets arrive late.
- Blocks reappearing after you break them: the main thread is saturated, block updates are queued.
- Furnaces and hoppers slowing while chat stays instant: classic tick lag, network is fine.
- Rubber-banding with normal MSPT: that is latency or packet loss, not a tick problem.
On any Spigot, Paper, Purpur or Fabric build with a management mod, three commands give an immediate reading.
/tps
/mspt
/spark tps --memory
Read the three averages that /tps returns (1 minute, 5 minutes, 15 minutes). A single dip after a restart is normal because chunks are being generated. A slow slide across the 15 minute window points to something accumulating in the world, usually entities or an unbounded farm.
What drags Minecraft server TPS down
Entities and item stacks
Entities are the number one drain on most survival worlds. Each mob runs pathfinding, collision and AI goals every tick, and dropped items are checked for merging constantly. A single unlit cave system or an untuned iron farm can hold several thousand entities in loaded chunks.
/minecraft:kill @e[type=item,distance=..200]
/spark profiler start --timeout 300
/paper entity list
Chunk loading and world generation
Generating a brand new chunk is one of the heaviest operations the server performs. Players riding elytras or boats across unexplored terrain force continuous generation, and each new chunk drags in structure placement and light calculations. Pre-generating the map removes that spike almost entirely.
Redstone, hoppers and pistons
Redstone dust updates propagate recursively, and old implementations recalculate the same wire many times per tick. Hopper chains poll their target inventory on a fixed schedule whether or not anything moved. Large item sorters built with dozens of hopper lines are a frequent source of a flat 10 millisecond penalty on every single tick.
View distance and simulation distance
View distance controls how far chunks are sent to clients, simulation distance controls how far the world actually ticks. Raising view distance multiplies the number of loaded chunks quadratically, which raises memory pressure, entity counts and network output at the same time. Simulation distance is the one that really drives tick time.
| Symptom | Likely source | Where to look |
|---|---|---|
| Steady high MSPT, no spikes | Entity load or hopper chains | Entity counters, spark profiler |
| Spikes when players explore | Chunk generation | Chunk tasks in the report |
| Spike every few minutes | Auto-save or a scheduled plugin task | Save intervals, plugin schedulers |
| Drop tied to one area | Redstone contraption or farm | Tick per chunk listing |
| Slow degradation over hours | Memory pressure and garbage collection | Heap usage, GC pauses |
Reading a profiler report step by step
Guesswork is expensive. A timings report or a spark profile tells you which method, plugin or chunk is consuming the tick, with percentages you can act on.
Generating the report
/timings on
/timings paste
/spark profiler start --timeout 300
/spark profiler stop
/spark heapsummary
Timings ships with older Paper builds and was retired in favour of spark on recent ones. Run the sampler for at least five minutes, during peak activity, not on an empty world. A profile taken with two players online proves nothing about a Friday night.
What to read first
- Total MSPT and its 95th percentile, not just the average.
- The top three entries under the tick loop, expanded one level down.
- Entity ticking split by type, to spot the farm that dominates.
- Chunk tasks, which reveal generation or saving pressure.
- Plugin schedulers running synchronous tasks every tick.
A plugin that appears at 30 percent of tick time is not automatically at fault: it may simply be iterating over entities that should not exist. Fix the world first, then the software. The official Paper configuration reference documents every value mentioned below.
Configuration tuning that brings ticks back to 20
server.properties
view-distance=8
simulation-distance=6
entity-broadcast-range-percentage=75
sync-chunk-writes=false
max-tick-time=60000
network-compression-threshold=256
Dropping simulation distance from 10 to 6 often reclaims several milliseconds per tick on a populated survival world, with almost no visible impact for players. Keep view distance a couple of notches higher than simulation distance so the horizon still looks right.
spigot.yml and bukkit.yml
# spigot.yml
entity-activation-range:
animals: 16
monsters: 24
misc: 8
merge-radius:
item: 3.5
exp: 4.0
mob-spawn-range: 6
nerf-spawner-mobs: true
# bukkit.yml
spawn-limits:
monsters: 50
animals: 8
ticks-per:
monster-spawns: 4
Paper world defaults
redstone-implementation: ALTERNATE_CURRENT
hopper:
disable-move-event: true
max-auto-save-chunks-per-tick: 8
alt-item-despawn-rate:
enabled: true
items:
COBBLESTONE: 300
NETHERRACK: 300
The alternate redstone engine removes most of the recursive updates that make large circuits expensive, without changing observable behaviour for normal builds. Disabling the hopper move event is safe unless a plugin explicitly listens to it, so check your event listeners before flipping it.
Memory and garbage collection
java -Xms6G -Xmx6G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
-XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 \
-XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 \
-jar paper.jar nogui
Set the minimum and maximum heap to the same value so the JVM never resizes mid-session. Oversizing the heap is a real mistake: a 16 GB heap on a vanilla-plus world produces longer collection pauses than an 8 GB one, and those pauses show up as tick spikes. A modded pack is different and genuinely needs more.
Keeping the world fast over the long run
Tuning is not a one-shot task. Worlds grow, farms multiply and plugin lists drift, so schedule a short audit every few weeks and keep a reference profile to line up against.
- Pre-generate the map with Chunky up to your border, then set a real world border so exploration stops creating chunks.
- Cap farms socially or technically: a rule on maximum mobs per farm prevents most emergencies.
- Automate snapshots before every configuration change, and test restores at least once.
- Trim plugins: two overlapping protection plugins tick the same regions twice.
- Restart on a schedule if you run heavy mods, to reset fragmented heap and leaked references.
Storage matters more than most admins expect. Chunk saving on spinning disks stalls the save thread and eventually the main thread, whereas NVMe absorbs the same write bursts without a visible spike. The same logic applies to every sandbox title listed on All our game servers, where world size drives disk activity.
If tick rate collapses only during raids or events, the bottleneck is usually simultaneous chunk loading rather than entity count. Lower simulation distance temporarily, ask players to gather in pre-loaded areas, and check the ticket counts in your profiler. More configuration walkthroughs are published on the Nexus Games blog, and the panel side of the work is documented across Nexus Games guides.
Conclusion
Measure before you edit. Pull an MSPT reading and a five minute profile at peak activity, then act on the top entry only: entity counts, simulation distance, then redstone and hoppers, in that sequence. The most common mistake is throwing memory at a world that is drowning in dropped items. Pre-generate your map, cap farms, keep the heap modest, and a stable 20 ticks per second stays reachable even with fifty players online.
FAQ
Why does my server show 20 TPS while players still feel lag?
Because tick rate and network latency are separate problems. At a clean 20 TPS with low MSPT, stuttering movement, rubber-banding and delayed chat come from packet loss, high ping or client-side rendering. Check the player ping table, ask two people on different connections to compare, and look at client frame rate with F3 before touching any world configuration value.
Does adding more RAM increase tick rate?
Rarely. Extra memory only helps when the heap is genuinely saturated and garbage collection pauses are visible in the profiler. Beyond that point, a larger heap lengthens collection cycles and makes spikes worse. Tick time is bound by single-thread CPU speed, so a higher clock frequency and a larger cache deliver far more improvement than doubling allocated memory.
How many chunks does a single player keep loaded?
With a simulation distance of 6, a player keeps roughly 169 chunks ticking around them, and view distance loads even more for rendering. Ten players spread across a large map therefore tick far more chunks than ten players grouped in one town. Encouraging shared bases, or lowering simulation distance during events, cuts that total quickly.



