Comprendre et corriger les chutes de TPS sur un serveur Minecraft

Minecraft server TPS is the single number that tells you whether your world is running smoothly or grinding through lag. When ticks per second drop below 20, players feel it instantly: rubber-banding, delayed hopper transfers, chunk pop-in, mobs freezing mid-jump. This guide breaks down how tick timing actually works, how to read the numbers your console gives you, and which settings, entities, chunk loading behavior and plugins are usually responsible for tick drops.

Understanding Minecraft Server TPS and Tick Timings

Minecraft server TPS (ticks per second) measures how many game logic cycles the server processes in one second. Vanilla and modded servers target 20 TPS, meaning one tick every 50 milliseconds. Each tick handles entity movement, block updates, redstone, mob AI, chunk loading, and plugin or mod events. If everything that needs to happen in a tick finishes in under 50ms, the server sits comfortably at 20 TPS.

The moment a tick takes longer than 50ms, the server can't catch up in real time. Instead of speeding up later ticks, it simply runs fewer of them per second, which is what you see as a TPS drop. The relationship is straightforward: TPS = 1000 / MSPT, where MSPT is the average milliseconds per tick. A server averaging 100ms per tick is stuck at roughly 10 TPS, half the expected speed, and every redstone clock, hopper chain and mob spawner slows down proportionally.

Before touching any configuration file, it helps to run your world on infrastructure built for consistent tick performance. If you're evaluating Minecraft server hosting with a Ryzen CPU, NVMe storage and a Pterodactyl panel to isolate whether hardware or configuration is the bottleneck, that's usually the first variable worth eliminating before chasing plugin conflicts.

Reading Tick Timings and Diagnosing Drops

Guessing at causes wastes time. Every drop in Minecraft server TPS has a measurable source, and the tools below will point you to it directly instead of forcing you to disable plugins one by one.

Built-in TPS and tick commands

On Paper, Purpur or Spigot builds, run the following from console or as an operator in-game:

/tps
/mspt

This returns a rolling average over the last 1, 5 and 15 minutes. A healthy result looks like 20.0, 20.0, 20.0. Anything consistently under 19 during normal gameplay means something is eating tick budget, and the 1-minute figure will react first to a spike.

Profiling with spark

For a real breakdown of what's consuming tick time, install the spark profiler plugin or mod and run:

/spark profiler start
/spark profiler stop --title "tps-drop"

Spark generates a report ranking every plugin, mod, entity type and world generation task by the percentage of tick time it consumes. This is the fastest way to tell whether a Minecraft server TPS drop comes from a specific plugin, an overloaded chunk, or raw entity count rather than relying on trial and error.

Reading a timings report

Signal	Likely cause
High "Chunk Load" time	Players spreading out fast, low render pre-caching, no pregeneration
High "Entity Tick" time	Mob farms, entity cramming, uncontrolled item drops
High "Tile Entity Tick" time	Hopper chains, furnaces, redstone clocks running constantly
Spikes tied to a specific plugin	Inefficient event listener or scheduled task in that plugin
Gradual MSPT climb over days	Memory pressure, garbage collection pauses, world file bloat

World Settings, Chunk Loading and Entities Behind Tick Drops

Most persistent Minecraft server TPS problems come down to how many chunks are active and how many entities live inside them. These are the settings and behaviors worth auditing first.

View distance and simulation distance

These two values in server.properties directly control how much of the world is being ticked at once:

view-distance=8
simulation-distance=6

View distance controls what's rendered and sent to clients; simulation distance controls what's actually ticked (mobs moving, crops growing, redstone updating). Dropping simulation distance from 10 to 6 on a survival world with a spread-out playerbase often recovers several TPS instantly, because far fewer chunks are running full logic every tick.

Entity density and cramming

Large mob farms, breeding pens and item accumulation on hoppers are classic offenders. Watch for:

• Uncapped animal breeding pens producing dozens of entities
• AFK fish or XP farms generating item entities faster than they're collected
• Redstone clocks left running 24/7 in unloaded-but-active chunks
• Chunk loaders keeping farms ticking even when no player is nearby

Vanilla's maxEntityCramming and per-chunk mob caps help, but the real fix is limiting farm output or adding despawn timers via a plugin. Paper exposes granular per-world limits worth using instead of relying on defaults:

# paper-world-defaults.yml
entities:
  spawning:
    per-player-mob-spawns: true
  entity-per-chunk-save-limit:
    experience_orb: 20
    item: 30

Chunk generation and pregeneration

New chunk generation is one of the heaviest single-tick operations in the game. On a growing world, players exploring in different directions simultaneously can spike MSPT well past 100ms for several seconds. Pregenerating the map ahead of time with a chunk generation plugin during low-traffic hours prevents this cost from landing on live players later.

Plugins, Mods and Server-Side Optimisation for Stable TPS

Once world settings are tuned, remaining Minecraft server TPS instability is usually plugin, mod or JVM related.

Choosing a tick-optimised software base

Paper and its forks (Purpur, Pufferfish) rewrite significant parts of vanilla's tick loop for async chunk loading and smarter entity activation ranges, which vanilla and most Forge-only setups don't have. For modded environments, similar gains come from tick-optimisation mods that reduce redundant entity AI calculations without changing gameplay behavior.

Isolating a problem plugin

With spark data in hand, disable or update the top offender one at a time and re-measure:

/plugman unload SuspectPlugin
/tps

If TPS recovers immediately, you've confirmed the cause. Check the plugin's changelog before reinstalling; many tick-heavy bugs are fixed in patch releases rather than requiring removal.

JVM flags and garbage collection

Garbage collection pauses show up as sudden, brief TPS drops that don't correlate with player count. Aikar's flags remain the standard starting point for G1GC tuning on a Minecraft process:

java -Xms6G -Xmx6G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
-XX:+DisableExplicitGC -XX:G1NewSizePercent=30 \
-XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M \
-jar paper.jar nogui

Set -Xms and -Xmx to the same value to avoid heap resizing pauses, and allocate enough RAM for your plugin and entity load without over-provisioning, since an oversized heap can actually lengthen GC pause times. If you manage the process yourself over SSH on a Linux machine, checking memory pressure alongside TPS gives a fuller picture than TPS alone:

free -h
top -o %MEM

Regular backups matter here too: before changing generation settings, JVM flags or removing farms, take a snapshot so a bad configuration change is a rollback, not a rebuild. For a broader look at how different games handle tick and update loops under load, the Fly-Serv blog covers similar performance troubleshooting across other titles, and the full list of supported game servers shows what else runs on the same Ryzen and NVMe infrastructure.

Stable Minecraft server TPS comes from treating tick time as a budget: know what's consuming it, cut what doesn't need to run every tick, and verify each change with real numbers instead of assumptions. Diagnose first with spark or timings, adjust world and JVM settings deliberately, and TPS drops become predictable problems with clear fixes rather than mysteries.

FAQ

Why does TPS drop only when several players explore at once?

New chunk generation is expensive per tick. Multiple players moving into unloaded terrain simultaneously stacks several generation tasks into the same tick cycle. Pregenerating the map ahead of time removes this cost from live gameplay.

Is 19 TPS actually a problem?

Occasional dips to 19 during heavy activity are normal and rarely noticeable. A sustained average under 18-19 over several minutes indicates a real bottleneck worth profiling with spark rather than something to ignore.

Do more RAM allocations always fix TPS drops?

No. TPS is a CPU tick-time metric, not a memory metric. Extra RAM can even worsen pauses if garbage collection has more heap to scan. Diagnose with spark or a timings report before adjusting -Xmx.