Comprendre et corriger les chutes de TPS sur un serveur Minecraft

Minecraft server TPS is the single clearest signal of whether your world runs smoothly or drags players into rubber-banding, delayed hits, and mob AI that freezes mid-attack. Ticks-per-second measures how many times the game loop completes each second, with 20 as the target — anything trending below 18 means something is quietly stealing processing time from your world.

What Actually Drives Minecraft Server TPS

Minecraft server TPS is not a mystery stat. It's the direct output of how fast your CPU can finish one full tick — physics, redstone, entity AI, chunk logic — before the next 50ms window starts. Four factors dominate that workload, and understanding each one is the first step before touching any config file.

Single-core CPU speed

Minecraft's main tick loop is almost entirely single-threaded. Vanilla and most Paper/Spigot forks process world logic on one core no matter how many cores the machine has. A high core count barely helps if per-core clock speed is weak — this is why raw single-thread frequency matters more than total core count when picking underlying hardware. Fly-Serv runs Ryzen CPUs with high per-core frequency and NVMe storage specifically because chunk reads and world saves are latency-sensitive, and a slow disk stalls the tick loop just as much as a slow core.

Chunk loading and world generation

Every time a player walks into unexplored territory, the server has to generate or load chunks from disk. On worlds with heavy exploration, farms with chunk loaders, or plugins that force-load regions, this becomes a constant background cost that competes with the main tick for CPU time.

View distance and simulation distance

These are two separate settings with very different costs. View distance controls how many chunks are sent to the client for rendering. Simulation distance controls how many chunks are actively ticked — mobs moving, crops growing, redstone firing. Raising simulation distance is far more expensive than raising view distance, because it multiplies the amount of logic processed every single tick.

Entity count

Mob farms, item duplication glitches, uncollected drops, and villager breeding rooms are the most common silent killers of TPS. Each entity needs pathfinding, collision checks, and AI updates every tick. A single overgrown farm with a few hundred extra mobs can shave several ticks per second off an otherwise healthy world.

If you're setting up a new world and want the hardware side handled correctly from the start, dedicated Minecraft server hosting built on modern CPUs removes one whole category of lag before it ever becomes a diagnostic problem — but the software-side causes above still need active monitoring regardless of the underlying machine.

Diagnosing Low TPS With Timings and Spark Reports

Guessing at the cause of a Minecraft server TPS drop wastes hours. Paper and Spigot ship with built-in profiling tools that show exactly which plugin, entity type, or world region is eating tick time.

Reading the built-in timings report

Timings breaks down tick time by plugin and by internal Minecraft process, giving you a percentage share of the tick budget for each. Run it from the console during normal player activity, not right after a restart when chunks are still cold-loading.

timings on
# let it run for 5-10 minutes under normal load
timings paste

The command returns a link to a hosted report. Look at the "Tick" tab first — anything consuming more than a few percent of tick time consistently is worth investigating, especially entries under "Minecraft" (vanilla mechanics like entity ticking or chunk generation) versus specific plugin names.

Using spark for live profiling

Spark goes deeper than timings by sampling the actual call stack, which makes it far better at catching lag spikes caused by specific method calls rather than whole plugins. It works on Paper, Spigot, Forge, and Fabric.

spark profiler start --timeout 300
spark profiler stop
spark tps
spark health

spark tps gives a rolling average across 5s, 1m, 5m, and 15m windows, which is the fastest way to tell if a drop is a temporary spike (a big explosion, a chunk save) or a sustained problem (an entity farm slowly growing out of control). spark health adds CPU load, memory pressure, and disk IO in one view, which is useful when you suspect the underlying machine rather than a specific plugin.

Cross-checking with entity and chunk counts

Once timings or spark points at "entity ticking" or "chunk loading" as the heavy consumer, confirm it with a raw count:

forge entity list
# or, on Paper/Spigot
spark tickmonitor --threshold 100

A world with thousands of item entities scattered across a mob farm's overflow room is a very common find here, and it's invisible until you actually count it.

Practical Fixes Once You've Found the Cause

Diagnosis is only half the work. Each root cause identified above has a specific, low-risk fix that doesn't require rebuilding the world.

Tuning view-distance and simulation-distance

These live in server.properties and can be adjusted without a full world restart on most Paper builds using /paper reload (though a restart is still recommended after major changes):

view-distance=8
simulation-distance=6
max-tick-time=60000

Dropping simulation-distance from 10 to 6 on a survival world with 10-15 concurrent players is often the single biggest TPS recovery available, since it directly reduces the number of chunks actively ticking redstone, crops, and mobs.

Controlling entity count

Paper exposes per-world entity caps that prevent farms from silently scaling past what the tick loop can handle:

entity-per-chunk-save-limit:
  minecraft:item: 32
  minecraft:experience_orb: 16

Combine this with a scheduled cleanup command to sweep stray drops from unattended farms:

/kill @e[type=item,limit=200,sort=nearest]

Reducing chunk loading pressure

Disable or remove unauthorized chunk loaders, and cap how far redstone clocks and farms can run unattended. If players legitimately need always-on farms, isolate them to a spawn-adjacent region with a lower simulation-distance override rather than raising the global setting.

Table: quick TPS troubleshooting checklist

Symptom	Likely cause	First check
TPS drops only near a specific coordinate	Entity farm or redstone clock	spark tickmonitor
TPS drops server-wide, no pattern	Underlying CPU or disk IO limit	spark health
TPS drops after players explore	Chunk generation load	Check world save size growth
TPS fine solo, drops with 10+ players	Simulation-distance too high	Lower simulation-distance, retest

Beyond manual tuning, most modpacks and plugin stacks benefit from a panel that lets you swap Java flags, restart cleanly, and roll back to a saved backup if a change makes things worse instead of better — worth keeping in mind when comparing how different setups handle plugin installs and version updates. For a broader look at what's available across other survival and sandbox titles, see All our game servers.

Long-Term Monitoring to Keep TPS Stable

A single profiling session fixes today's problem but not next month's. Farms grow, plugins accumulate, and world size increases every session. Building a light monitoring habit prevents the same investigation from repeating every few weeks.

Weekly checks worth automating

• Run spark tps at the same time each week and log the numbers to spot slow drift.
• Check world folder size growth — a sudden jump usually means unbounded exploration or a chunk loader left active.
• Review installed plugins after any update, since a single misbehaving plugin can double tick time overnight.
• Confirm automated backups are still completing without errors, since a corrupted or stalled backup process itself can eat IO during ticks.

Keeping regressions from stacking

Version updates, new plugins, and datapacks all change tick behavior. Testing changes on a clone of the world before pushing them to the live one, and keeping a recent snapshot ready to restore, turns a bad update into a five-minute rollback instead of a lost weekend chasing a phantom bug. For general reading on server administration workflows across different titles, the Fly-Serv blog covers related setup and troubleshooting topics.

Official documentation on the profiling tool itself is worth bookmarking directly: Source.

Tracking Minecraft server TPS is less about one magic setting and more about ruling out causes methodically: CPU speed, chunk load, view and simulation distance, and entity count. With timings and spark reports pointing at the actual bottleneck, most drops get fixed in minutes instead of guesswork.

FAQ

What TPS value is considered healthy for a Minecraft server?

20 is the maximum and target value. Anything consistently above 18-19 is healthy; drops below 15 are noticeable to players as delayed hits and laggy redstone, and below 10 the world becomes difficult to play on.

How do I read a spark profiler report?

Focus on the flame graph's widest branches first — they represent methods consuming the most tick time. Cross-reference plugin names or vanilla classes shown there against your installed plugin list to isolate the source quickly.

Does increasing view-distance always cause lag?

Not directly. View-distance mainly affects network and rendering load on the client, not tick time. Simulation-distance is the setting that actually raises server-side tick cost, so lower that first before touching view-distance.