Comprendre et corriger les chutes de TPS sur un serveur Minecraft

Minecraft server TPS is the single metric that separates a smooth survival world from one where every redstone clock stutters and mobs teleport instead of walking. When ticks per second fall below the 20 target, players feel it immediately: delayed hits, rubber-banding, and chunks that pop in a beat too late. This guide explains what actually drives TPS — clock speed, chunk loading, entity count, and view distance — then shows how to read a timings or Spark report and tune server.properties to fix the drops.

What Really Drives Minecraft Server TPS

Minecraft's main game loop runs on a single thread. Regardless of how many CPU cores sit in the machine, world logic, redstone, mob AI, and block updates all queue up on that one thread and must finish inside a 50ms window to hit the 20 TPS target. This is why Minecraft server TPS depends far more on single-core clock speed than on core count — a fast four-core Ryzen chip will usually outperform a slower sixteen-core one for this exact reason.

Four factors account for almost every TPS drop you'll ever chase down:

• Single-core clock speed — every tick is a race against the 50ms budget on one thread.
• Chunk loading and generation — new terrain generation and disk reads are heavy, bursty operations.
• Entity count — mobs, dropped items, minecarts, and projectiles all tick individually.
• View distance and simulation distance — these two server.properties values multiply the number of chunks and entities being processed every tick.

If you're weighing infrastructure choices for a survival world or a modded pack, the underlying clock speed and storage matter just as much as any configuration change. Our Minecraft server hosting setups run on Ryzen chips with NVMe storage, both aimed directly at the single-core bottleneck and chunk I/O described above.

Diagnosing TPS Drops: /tps, Spark, and Timings Reports

Before touching a single line of configuration, find out where the tick time is actually going. Guessing wastes hours; a five-minute profiling session usually points straight at the culprit.

Reading the /tps output

On Paper, Purpur, or Spigot builds, the console command below gives a rolling average:

/tps
# Example output:
# TPS from last 1m, 5m, 15m: 19.8, 18.2, 17.9

A value near 20 across all three windows means the world is healthy. A steep drop only in the 1-minute figure points to a recent, localized spike — a player entering a new area, a farm activating, or a plugin task firing.

Profiling tick time with Spark

Spark has largely replaced the older Timings paster and gives a much more granular breakdown, including per-plugin and per-world costs:

/spark profiler --timeout 60
/spark tps
/spark healthreport

After the profiler window closes, it prints a link to an interactive flame graph. Sort by self-time and look for anything that isn't vanilla tick logic — a plugin task, an oversized entity AI loop, or excessive hopper/minecart processing.

What to look for in the report

Symptom in report	Likely cause
High "chunk loading" self-time	Players exploring new terrain, no chunk pre-generation
High "entity tick" self-time	Uncapped mob farms, item duping, dropped item pileups
High "block update" self-time	Large redstone clocks, hopper chains, sorting systems
Plugin task dominating self-time	A specific plugin scheduling heavy work every tick

Once you know which category is eating tick time, the fix is almost always a configuration change rather than a hardware upgrade.

Fixing Minecraft Server TPS: server.properties and World Tuning

Most Minecraft server TPS problems trace back to two overlooked values in server.properties. Lowering them has an outsized effect because they scale the number of chunks and entities processed every single tick.

# server.properties
view-distance=8
simulation-distance=6
max-tick-time=60000
entity-broadcast-range-percentage=80

Setting	Effect on TPS
view-distance	Controls how many chunks are sent to clients; high values load more terrain per tick
simulation-distance	Controls how many chunks are actively simulated (mob AI, redstone); the heaviest lever
max-tick-time	Watchdog timeout before the process force-kills itself on a frozen tick
entity-broadcast-range-percentage	Reduces network packets tied to entity tracking at range

Pre-generating chunks to remove load-time TPS spikes

A large share of "random" lag spikes happen the instant a player crosses into unloaded terrain. Generating the world border ahead of time with a plugin like Chunky moves that cost out of live gameplay entirely:

/chunky world world
/chunky radius 5000
/chunky start

Controlling entity count without ruining gameplay

Mob and item caps rarely need to be brutal — they need to be smart. A scheduled, gentle cleanup keeps counts sane:

# Example ClearLagg-style scheduled task
clear-lagg:
  items:
    interval: 300
    warning: 30
  mobs:
    interval: 600
    limit-per-chunk: 15

Combine this with reasonable spawn caps in spigot.yml (mob-spawn-range, ticks-per-*-spawns) rather than disabling spawns outright.

Java flags to reduce garbage collection pauses

Long GC pauses look identical to a TPS drop in-game but come from the JVM, not the game loop. Aikar's flags remain a solid baseline for a Paper-based world:

java -Xms4G -Xmx4G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
-XX:+DisableExplicitGC -XX:+AlwaysPreTouch -jar paper.jar nogui

Keeping TPS Stable Over Time

Diagnosing lag once isn't enough — a growing world accumulates entities, chests, and redstone contraptions that gradually push tick time back up. A short weekly routine keeps Minecraft server TPS from drifting downward again:

• Run /spark profiler after any content update or plugin change, not just when lag is reported.
• Schedule a nightly restart through the panel console during off-peak hours to clear accumulated entities and free memory.
• Keep automatic snapshots enabled before testing new plugins or farm designs, so a bad config change is a quick rollback, not a rebuild.
• Audit installed plugins periodically; an outdated one is a common source of per-tick overhead that never shows up until the player count grows.
• Use RCON or the panel console for remote checks instead of leaving debug commands running permanently, since some profilers add their own small overhead.

For a full list of supported titles and configurations beyond Minecraft, All our game servers covers the range, and ongoing tuning guides like this one are collected on the Fly-Serv blog.

Minecraft server TPS problems almost always trace back to one of four things: clock speed, chunk loading, entity count, or view/simulation distance. Profile first with /tps or Spark, then tune server.properties and Java flags based on what the report actually shows, rather than guessing at a fix.

FAQ

What Minecraft server TPS is considered normal for survival worlds?

20 TPS is the target and means the world is running at full speed. Anything from 18 to 20 is generally unnoticeable to players; drops below 15 start causing visible rubber-banding and delayed redstone.

Does adding more RAM increase TPS?

Only indirectly. RAM prevents out-of-memory crashes and reduces garbage collection frequency, but TPS is bound by single-core tick processing speed, not memory size. Over-allocating RAM can even hurt performance by triggering longer garbage collection pauses.

Why does TPS drop only when players explore new areas?

That's chunk generation, not simulation load. Newly generated terrain is far more CPU-intensive than already-loaded chunks. Pre-generating the world border with a tool like Chunky removes this spike from live gameplay entirely.