Comprendre et optimiser le TPS d'un serveur Minecraft

Le TPS serveur Minecraft est l'indicateur numéro un pour savoir si ta partie tourne correctement ou si elle rame. Quand cette valeur chute sous 20, les joueurs ressentent des téléportations, des mobs qui se figent et une redstone qui déraille. Comprendre ce qu'est le TPS, pourquoi il baisse et comment le stabiliser évite bien des migraines en administration.

Comprendre le TPS serveur Minecraft et son impact sur la fluidité

Le TPS (Ticks Per Second) mesure le nombre de cycles de calcul que le moteur du jeu exécute chaque seconde. En théorie, Minecraft vise 20 ticks par seconde, soit un tick toutes les 50 millisecondes. Chaque tick traite la physique, les entités, les mises à jour de blocs, la redstone, l'IA des mobs et les plugins actifs. Si le serveur met plus de 50 ms à boucler un tick, il accumule du retard : c'est ce qu'on appelle une chute de TPS.

Un TPS stable à 20 donne une sensation de jeu fluide, où les actions du joueur répondent instantanément. Dès que la valeur descend à 15 ou 10, les animations deviennent saccadées, les cultures poussent plus lentement, les fours cuisent au ralenti et les portes automatiques à redstone commencent à bugger. En dessous de 5 TPS, le serveur devient quasiment injouable, avec des déconnexions fréquentes liées au timeout réseau.

La différence entre TPS et MSPT

Le TPS seul ne raconte pas toute l'histoire. Le MSPT (Milliseconds Per Tick) indique le temps réel passé à calculer chaque tick. Un serveur peut afficher 20 TPS tout en ayant un MSPT élevé juste avant une chute : c'est un signal d'alerte à surveiller avant que le problème ne devienne visible pour les joueurs.

Pour aller plus loin sur la configuration technique d'une instance Minecraft, la page hébergeur Minecraft de Fly-Serv détaille les ressources matérielles disponibles pour limiter ce type de ralentissement dès le départ.

Les causes fréquentes des chutes de TPS

Avant de modifier quoi que ce soit, il faut identifier d'où vient la surcharge. Les causes se répartissent généralement en trois familles : la charge logicielle (mods, plugins, datapacks), la charge liée au monde (chunks, entités, redstone) et la charge matérielle (CPU, RAM, disque).

Mods et plugins mal optimisés

Un plugin qui exécute une boucle lourde à chaque tick, scanne l'inventaire de tous les joueurs en permanence ou génère des requêtes de base de données synchrones peut à lui seul faire chuter le TPS d'un serveur entier. Les modpacks volumineux côté Forge ou NeoForge cumulent souvent plusieurs mods gourmands qui se marchent dessus.

Génération de chunks et circuits de redstone

Chaque nouveau chunk généré consomme du calcul. Un serveur avec une distance de vue élevée et une communauté qui explore activement multiplie les générations de terrain en continu. De même, les fermes automatiques à redstone, les circuits de pistons en boucle ou les fermes à mobs mal plafonnées créent une charge d'entités que le moteur doit recalculer à chaque tick.

Ressources matérielles insuffisantes

Minecraft reste mono-thread pour l'essentiel de sa boucle de jeu principale. Un processeur à fréquence élevée par cœur fait donc une réelle différence par rapport à un CPU multi-cœurs mais peu véloce par cœur. Un stockage NVMe réduit aussi les temps de lecture/écriture lors des sauvegardes automatiques et du chargement des chunks, deux opérations qui peuvent geler temporairement le tick si le disque est lent.

Cause	Symptôme observé	Piste de correction
Plugin lourd	MSPT élevé constant	Profiler avec spark, désactiver ou remplacer
Fermes à mobs	Chute progressive la nuit	Plafonner mob-spawn-range et les entités par chunk
Exploration massive	Pics lors des déplacements	Réduire view-distance et pré-générer le monde
CPU sous-dimensionné	TPS bas en permanence	Migrer vers un CPU à fréquence par cœur plus élevée
Stockage lent	Freeze lors des sauvegardes	Passer sur du SSD NVMe

Diagnostiquer les baisses de TPS avec les bons outils

Avant de régler quoi que ce soit, il faut mesurer. La console du serveur et quelques outils gratuits suffisent à localiser précisément l'origine du souci.

La commande /tps

Sur Paper, Purpur ou Spigot, la commande native donne une moyenne glissante sur 1, 5 et 15 minutes :

/tps
TPS from last 1m, 5m, 15m: 19.98, 19.95, 19.90

Une valeur qui descend nettement sur la fenêtre 1 minute mais remonte sur 15 minutes indique un pic ponctuel (un redémarrage, une génération de chunk massive). Une dégradation constante sur les trois fenêtres signale un problème structurel.

Profiler avec spark

L'outil spark s'installe comme plugin ou mod et génère un rapport détaillé du temps CPU consommé par chaque plugin, mod ou tâche interne :

/spark profiler start
# laisser tourner quelques minutes en jeu
/spark profiler stop --title "diag-tps"

Le rapport pointe exactement quelle méthode ou quel plugin consomme le plus de temps par tick, ce qui évite de deviner à l'aveugle.

Les rapports timings

Sur les forks Bukkit, la commande /timings report reste une alternative historique à spark pour obtenir un lien de rapport consultable dans un navigateur, listant la répartition du temps de tick entre le monde, les entités et les plugins.

Surveillance côté panel

Le panel Pterodactyl affiche en direct la consommation CPU et RAM de l'instance dans la console live, ce qui permet de croiser une chute de TPS observée en jeu avec un pic de charge visible côté infrastructure, sans avoir à te connecter séparément en SSH.

Réglages techniques pour stabiliser les ticks

Une fois la cause identifiée, plusieurs réglages dans les fichiers de configuration permettent de redonner de l'air au moteur de tick.

Ajuster server.properties

view-distance=8
simulation-distance=6
max-tick-time=60000
spawn-protection=0

Réduire la distance de vue et la distance de simulation allège directement le nombre de chunks actifs calculés à chaque tick, souvent le levier le plus efficace sur un serveur survie avec plusieurs joueurs dispersés.

Limiter les entités et le spawn de mobs

Sur Paper, le fichier config/paper-world-defaults.yml permet de plafonner précisément les entités par chunk et la portée de spawn des mobs :

entity-per-chunk-save-limit:
  all: -1
spawn-limits:
  monster: 50
  animal: 10
  water-animal: 5
  ambient: 5
tick-rates:
  mob-spawner: 2
  container-update: 1

Ces valeurs limitent les fermes à mobs excessives sans interdire le gameplay de base, tout en réduisant la charge de calcul par tick.

Pré-générer le monde

Plutôt que de laisser les chunks se générer en direct lorsqu'un joueur explore, un plugin de pré-génération comme Chunky permet de calculer le monde à l'avance, pendant une période de faible affluence :

/chunky radius 5000
/chunky center 0 0
/chunky start

Le pic de charge est ainsi absorbé en dehors des heures de jeu actives, au lieu de faire chuter le TPS pendant une session en cours.

Automatiser le redémarrage préventif

Un redémarrage planifié toutes les 12 ou 24 heures via une tâche cron ou directement depuis le planificateur du panel vide la mémoire accumulée par la JVM et repart sur une base propre, un correctif simple contre la dégradation progressive du TPS liée aux fuites mémoire de certains plugins.

# exemple de tâche cron côté VPS pour un redémarrage programmé
0 5 * * * systemctl restart minecraft-server

Allouer correctement la RAM à la JVM

Trop de RAM allouée à Java peut paradoxalement nuire au TPS à cause de pauses du garbage collector plus longues. Des flags adaptés, comme ceux recommandés par Aikar, équilibrent la fréquence et la durée de ces pauses :

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

Garder une marge de RAM libre côté système évite aussi le swap, destructeur pour la régularité des ticks. Pour les instances gérées via un VPS Pterodactyl, ces flags se configurent directement dans la variable de démarrage du serveur sans toucher au système hôte.

Ces réglages combinés à un anti-DDoS actif en permanence évitent aussi qu'une attaque réseau ne vienne artificiellement saturer les ressources CPU au moment où tu diagnostiques une baisse de TPS, un facteur parfois négligé lors des investigations.

Stabiliser le TPS serveur Minecraft demande une approche méthodique : mesurer avec /tps et spark, identifier si la charge vient des plugins, du monde ou du matériel, puis ajuster les fichiers de configuration en conséquence. Ces réglages, appliqués progressivement, redonnent une base de jeu fluide et prévisible pour toute la communauté.

FAQ

Pourquoi mon TPS chute uniquement quand plusieurs joueurs sont connectés ?

Chaque joueur charge des chunks supplémentaires et déclenche plus d'entités actives. Réduis view-distance et simulation-distance dans server.properties, et vérifie avec spark si un plugin lié aux interactions joueurs consomme anormalement du temps CPU.

Un TPS à 19.5 est-il un problème ?

Non, une légère variation autour de 20 est normale et imperceptible en jeu. Le seuil d'attention se situe plutôt en dessous de 18 de façon constante, ou lors de chutes brutales et répétées sous 15.

Faut-il désinstaller un plugin dès qu'il impacte le TPS ?

Pas forcément. Commence par vérifier sa configuration et sa version, beaucoup de plugins proposent des réglages pour limiter leur fréquence d'exécution. Si le rapport spark confirme une consommation excessive sans correctif disponible, le remplacement reste la solution la plus fiable.