Chutes de TPS sur un serveur Minecraft : diagnostiquer et corriger le lag

Par Benjamin D. · PDG

7 septembre 2026 · Mis à jour le 7 septembre 2026 · Lecture 11 min

Sommaire

Le TPS serveur Minecraft est l'indicateur le plus direct de la santé de ta simulation : 20 ticks par seconde, jamais plus. Dès qu'il descend, les mobs se téléportent, les coffres répondent en retard et la redstone décroche. Voyons comment lire cette valeur, quelles causes techniques la font chuter, et quels réglages appliquer pour retrouver une boucle de jeu stable.

TPS serveur Minecraft : ce que mesure vraiment cette valeur

Le moteur de Minecraft fonctionne par ticks. À chaque tick, la machine recalcule les mobs, la redstone, la croissance des cultures, les fluides, les entités, les chargements de chunks et les événements des plugins ou mods. Le rythme cible est de 20 ticks par seconde, soit 50 ms par tick. Si le calcul d'un tick dépasse 50 ms, le tick suivant part en retard et le TPS descend mécaniquement sous 20.

Point crucial souvent mal compris : le TPS ne peut jamais dépasser 20. Une machine puissante ne « gagne » pas de TPS, elle garde simplement une marge. C'est pourquoi le vrai indicateur de performance est le MSPT (millisecondes par tick), pas le TPS. Un serveur à 20 TPS avec 47 ms de MSPT est au bord du décrochage ; un serveur à 20 TPS avec 8 ms de MSPT a de la réserve.

Valeur	Interprétation
20 TPS / MSPT < 20 ms	Simulation saine, marge confortable
20 TPS / MSPT 35–50 ms	Limite atteinte, le moindre pic fera tomber le TPS
18–19 TPS	Ralentissement discret : mobs lents, croissance décalée
12–17 TPS	Ralentissement visible, hitreg dégradée en PvP
< 10 TPS	Le jeu tourne au ralenti, timeout possible des joueurs

TPS et ping sont deux problèmes différents

Un joueur qui « lag » ne subit pas forcément une chute de TPS. Deux phénomènes distincts se confondent dans le langage courant :

Chute de TPS : la simulation elle-même est en retard. Tout le monde est affecté en même temps, quelle que soit sa connexion.
Latence réseau : le paquet met du temps à faire l'aller-retour. Un seul joueur peut être touché, le TPS reste à 20. Cela dépend de la connexion du joueur, du routage et de la localisation de la machine.

Le test est simple : si le TPS affiché est à 20 mais que les blocs cassés « reviennent » chez un joueur unique, c'est du réseau. Si la croissance du blé ralentit pour tout le monde, c'est le tick. Chez Fly-Serv, l'anti-DDoS et les nœuds Ryzen en NVMe traitent la partie infrastructure, mais aucune machine ne compense une configuration de monde qui demande 80 ms de calcul par tick — c'est ce travail de diagnostic qu'on va détailler. Si tu prépares une nouvelle instance et que tu veux partir sur une base propre, la fiche hébergeur Minecraft détaille les configurations disponibles.

Mesurer avant de toucher à quoi que ce soit

Modifier une configuration sans mesure, c'est du bricolage. La première étape est toujours de collecter des données depuis la console du panel.

Les commandes de base

# Paper / Spigot / Purpur : TPS sur 1, 5 et 15 minutes
/tps

# Paper : TPS + MSPT + utilisation memoire
/mspt

# Vanilla et Fabric/Forge : profil natif du serveur
/debug start
# ... laisser tourner 60 secondes en conditions reelles ...
/debug stop
# Le rapport est ecrit dans /debug/ a la racine du serveur

Lis toujours les trois moyennes de /tps. Un TPS 1 min à 12 et un TPS 15 min à 19,8 signalent un pic ponctuel (une sauvegarde, un joueur qui explore, un chunk généré). Trois valeurs basses signalent une surcharge structurelle.

Spark : le profileur à installer en priorité

Spark existe pour Paper, Fabric, Forge et NeoForge. C'est l'outil qui transforme « ça lag » en « la ligne 214 de tel plugin consomme 31 % du tick ».

# Etat de sante general (TPS, MSPT, CPU, RAM, GC, disque)
/spark health --upload

# Profilage cible pendant 5 minutes puis lien de rapport
/spark profiler start --timeout 300 --thread server

# Compter les entites qui coutent le plus de temps de tick
/spark tickmonitor --threshold 100

# Occupation memoire par type d'objet
/spark heapsummary

Dans le rapport, remonte l'arbre d'appels jusqu'à identifier le coupable : net.minecraft.world.entity pointe vers les entités, ServerChunkCache vers du chargement de chunks, un package com.monplugin vers un plugin. Les docs officielles de Spark expliquent comment lire un profil ligne par ligne.

Timings et logs de tick lent

Paper journalise automatiquement les ticks anormalement longs. Cherche dans logs/latest.log :

grep -i "Can't keep up" logs/latest.log
grep -i "Saving oversized chunk" logs/latest.log
grep -i "took .* ms" logs/latest.log

Le message « Can't keep up! Is the server overloaded? » avec un skipping ticks élevé et régulier trahit une saturation continue. Le même message isolé une fois par heure correspond souvent à la sauvegarde automatique du monde.

Les causes techniques qui font chuter le TPS

1. Les entités hors de contrôle

C'est la cause numéro un sur les serveurs survie ouverts depuis plusieurs mois. Chaque entité coûte du temps de tick : pathfinding des mobs, collision, IA des villageois, item frames, armor stands, chariots, bateaux abandonnés.

Fermes à mobs mal conçues : des centaines de créatures accumulées dans un espace réduit, chacune recalculant sa trajectoire.
Villageois en surnombre : leur IA (trade, restock, gossip) est l'une des plus lourdes du jeu.
Items au sol : une ferme de canne à sucre sans collecte génère des milliers de drops.
Chariots et cadres : ils ticent en permanence, même sans joueur proche selon la version.

# Compter les entites par monde (Paper)
/paper entity list

# Vue detaillee par chunk
/spark tickmonitor
# ou avec un plugin de management : /lagg chunk

2. La redstone et les hoppers

Une horloge redstone oubliée dans un coin de la map peut consommer 15 ms par tick à elle seule. Les hoppers sont particulièrement coûteux : chaque hopper vérifie l'inventaire au-dessus de lui à chaque tick de transfert. Une usine de tri avec 400 hoppers actifs est une source de MSPT garantie.

3. La génération et le chargement de chunks

Générer un chunk neuf est l'opération la plus lourde du serveur : bruit de terrain, structures, biomes, écriture disque. Un joueur en elytra à travers un monde non prégénéré fait tomber le TPS à lui seul. Même problème avec les chunk loaders permanents (portails Nether, plugins de chunk chargé, mods de type quarry).

4. Le Garbage Collector Java

Un serveur qui affiche des micro-freezes réguliers de 200 à 800 ms, TPS globalement bon mais saccadé, souffre presque toujours du GC. Deux erreurs classiques :

RAM trop faible : le GC tourne en continu pour libérer de la place.
RAM trop élevée : allouer 24 Go à un serveur de 15 joueurs allonge chaque cycle de collecte. Au-delà de 12 Go, le comportement du GC change.

5. Les plugins et mods mal optimisés

Un plugin qui exécute une requête SQL synchrone dans le thread principal bloque le tick le temps de la réponse. Idem pour les plugins de protection qui scannent des régions entières à chaque pose de bloc, ou les mods de génération de structures massives. Spark identifie ces cas en quelques minutes.

6. Les entrées/sorties disque

La sauvegarde du monde écrit des fichiers .mca. Sur un stockage lent, cette écriture bloque le tick. C'est là que le NVMe change concrètement le comportement du serveur : les pics de sauvegarde deviennent quasi invisibles. Vérifie aussi qu'aucune sauvegarde de fichiers volumineux ne tourne pendant les heures de pointe de ta communauté.

7. Le CPU et la fréquence par cœur

Le thread principal de Minecraft est mono-thread. Les 16 cœurs ne servent à rien pour le tick lui-même : ce qui compte, c'est la fréquence et l'IPC d'un seul cœur. Un processeur Ryzen haute fréquence traite plus d'entités par tick qu'une puce à beaucoup de cœurs mais faible fréquence. Si tu partages du CPU avec des voisins bruyants, tu constateras des MSPT irréguliers sans cause interne identifiable.

Réglages concrets pour remonter le TPS

server.properties : les deux leviers immédiats

view-distance=8
simulation-distance=5
max-tick-time=60000
sync-chunk-writes=false
network-compression-threshold=256

view-distance contrôle ce que le joueur voit, simulation-distance ce que le serveur calcule. Baisser la simulation de 10 à 5 réduit énormément le volume d'entités et de blocs traités, avec un impact visuel nul. C'est le réglage au rapport gain/effort le plus favorable.

paper-world-defaults.yml : le cœur du réglage

entities:
  spawning:
    per-player-mob-spawns: true
    spawn-limits:
      monster: 45
      animal: 8
      water-animal: 3
      ambient: 1
  behavior:
    disable-chest-cat-detection: true
    mobs-can-always-pick-up-loot:
      zombies: false
      skeletons: false
collisions:
  max-entity-collisions: 2
entity-activation-range:
  animals: 16
  monsters: 24
  raiders: 48
  misc: 8
  water: 8
  villagers: 16
  tick-inactive-villagers: false
hopper:
  cooldown-when-full: true
  disable-move-event: true
chunks:
  max-auto-save-chunks-per-tick: 8
  prevent-moving-into-unloaded-chunks: true
  entity-per-chunk-save-limit:
    experience_orb: 16
    arrow: 16
    snowball: 8

tick-inactive-villagers: false et les entity-activation-range abaissés sont souvent suffisants pour récupérer plusieurs TPS sur une map ancienne. Les valeurs et leur signification exacte sont documentées dans la documentation officielle PaperMC.

spigot.yml : fusion d'items et cadence des hoppers

world-settings:
  default:
    merge-radius:
      item: 3.5
      exp: 4.0
    item-despawn-rate: 4000
    ticks-per:
      hopper-transfer: 8
      hopper-check: 8
      monster-spawns: 4
    max-entity-collisions: 2

Flags de démarrage Java

Dans le panel Pterodactyl, la ligne de démarrage se modifie directement. Un jeu de flags G1 correctement paramétré supprime la majorité des micro-freezes :

java -Xms6G -Xmx6G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC \
  -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=30 \
  -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M \
  -XX:G1ReservePercent=20 \
  -XX:G1HeapWastePercent=5 \
  -XX:G1MixedGCCountTarget=4 \
  -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:SurvivorRatio=32 \
  -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -jar server.jar nogui

Règle simple : -Xms et -Xmx identiques, et jamais toute la mémoire de l'instance — le système et la JVM hors heap en ont besoin.

Prégénérer le monde

La génération de chunks se paye une seule fois. Autant la faire hors des heures de jeu, avec un plugin comme Chunky :

/chunky world world
/chunky center 0 0
/chunky radius 5000
/chunky start
# Suivre l avancement
/chunky progress

Combine ça avec une worldborder alignée sur le rayon prégénéré pour empêcher toute génération en direct :

/worldborder center 0 0
/worldborder set 10000

Nettoyage régulier

Supprime les entités orphelines après chaque grosse session d'exploration.
Traque les fermes abusives avec /spark tickmonitor et discute avec les joueurs concernés plutôt que de casser leurs constructions.
Vérifie l'état des sauvegardes automatiques avant chaque opération de maintenance, notamment avant une mise à jour de version ou de modpack.
Retire les plugins que tu n'utilises plus : chaque listener enregistré coûte du temps sur les événements fréquents.

Méthode de tri quand rien n'est clair

Relève TPS et MSPT en heure creuse. Si le MSPT est déjà haut sans joueur, le problème est dans le monde (entités, redstone, chunk loaders) ou dans un plugin à tâche planifiée.
Démarre le serveur sans plugins ni mods, sur une copie du monde. MSPT bas ? le problème vient d'un module. MSPT haut ? il vient du monde.
Réintègre les modules par groupes de trois jusqu'à voir le MSPT repartir.
Isole le monde fautif : teste chaque dimension séparément, le Nether est fréquemment coupable à cause des portails et des fermes.

Cette méthode fonctionne aussi pour d'autres titres où la boucle de simulation est le facteur limitant, comme les instances lourdes en entités sur Tous nos serveurs de jeu. D'autres guides techniques d'administration sont regroupés sur le Blog Fly-Serv.

Conclusion

Un tick à 50 ms est un budget, pas une garantie. Mesure d'abord avec /mspt et Spark, identifie la source réelle — entités, hoppers, chunks, GC ou module tiers — puis applique un réglage à la fois en vérifiant l'effet. Cette discipline de diagnostic vaut mieux que dix fichiers de configuration copiés au hasard, et elle garde ta simulation fluide sur le long terme.

FAQ

Pourquoi mon TPS est à 20 alors que les joueurs se plaignent de lag ?

Le TPS mesure la simulation, pas le réseau. Si la valeur reste à 20, regarde le MSPT : au-delà de 40 ms, chaque micro-pic devient perceptible. Vérifie aussi les pauses du Garbage Collector avec /spark health et le ping individuel des joueurs concernés, qui dépend de leur connexion et du routage.

Combien de RAM allouer pour éviter les chutes de TPS ?

Vise le juste nécessaire : 4 à 6 Go pour une survie vanilla d'une vingtaine de joueurs, 8 à 12 Go pour un modpack lourd. Fixe -Xms et -Xmx à la même valeur et garde une marge pour la JVM hors heap. Suralouer allonge les cycles de collecte et crée des freezes réguliers.

Faut-il baisser view-distance ou simulation-distance en premier ?

Commence par simulation-distance : passe-la à 5 ou 6. C'est elle qui détermine le volume d'entités, de redstone et de blocs calculés à chaque tick. Tu peux conserver view-distance à 8 ou 10 pour préserver le rendu visuel, le coût côté tick étant nettement plus faible.