Comprendre et optimiser le TPS de votre serveur Minecraft

Un TPS serveur Minecraft qui décroche se repère immédiatement en jeu : mobs qui glissent par saccades, coups d'épée qui ne passent pas, fours et fermes qui ralentissent, redstone désynchronisée. Derrière ce symptôme se cachent presque toujours trois variables : le moteur logiciel utilisé, la gestion de la mémoire Java et la distance de simulation. Voici comment les comprendre et diagnostiquer proprement une chute.

Comprendre le TPS serveur Minecraft : tick, MSPT et lag ressenti

Le jeu fonctionne sur une boucle fixe : 20 ticks par seconde, soit un tick toutes les 50 ms. À chaque tick, la machine traite la physique des blocs, les entités, la redstone, la croissance des cultures, les déplacements des joueurs et les sauvegardes de chunks. Si tout ce travail tient dans les 50 ms, le TPS reste à 20. S'il déborde, le tick suivant prend du retard et le TPS chute mécaniquement.

MSPT : la métrique qui parle vraiment

Le TPS est plafonné à 20, il ne monte jamais plus haut. Résultat : un monde qui consomme 12 ms par tick et un monde qui en consomme 48 ms affichent tous les deux « 20 TPS ». C'est pourquoi il faut regarder le MSPT (millisecondes par tick). C'est l'indicateur d'avance : à 48 ms de moyenne, vous êtes déjà en zone rouge, la moindre explosion de creeper ou l'arrivée de trois joueurs fera basculer le TPS sous les 20.

MSPT moyen	État	Action
< 20 ms	Confortable	Marge pour plus de joueurs ou de mods
20 à 35 ms	Correct	Surveiller les pics
35 à 50 ms	Tendu	Réduire la charge d'entités / distance de simulation
> 50 ms	TPS < 20	Diagnostic profileur immédiat

Ne pas confondre TPS, ping et FPS

Trois problèmes différents, souvent mélangés dans les tickets de modération :

• FPS bas : problème côté client (GPU, shaders, distance de rendu du joueur). Le monde reste fluide pour les autres.
• Ping élevé : problème de réseau entre le joueur et la machine. Le TPS peut être parfait à 20.
• TPS bas : problème côté machine. Tout le monde subit le ralentissement en même temps, y compris les mécanismes automatisés.

Le test le plus simple : demandez à deux joueurs éloignés sur la carte s'ils constatent le même comportement. Si oui, c'est le tick. Sur une infrastructure en Ryzen haute fréquence et NVMe comme celle de Fly-Serv, la latence réseau et les I/O disque sont rarement le facteur limitant : dans la grande majorité des cas, la cause est logicielle et se corrige en configuration. Si vous cherchez la fiche technique de la machine correspondante, elle est détaillée sur la page hébergeur Minecraft.

Moteur, RAM et distance de simulation : les trois variables qui pèsent

Le moteur : là où se gagnent les premiers millisecondes

La logique du monde est essentiellement monothread. Ajouter des cœurs n'accélère pas le tick principal : c'est la fréquence par cœur qui compte, complétée par les optimisations du moteur. Les implémentations dérivées apportent des correctifs importants sur le pathfinding des mobs, le traitement des hoppers, le chargement des chunks et les activations d'entités.

• Vanilla : référence de comportement, aucune optimisation supplémentaire, aucun support de plugins.
• Spigot / Paper : plugins Bukkit, très nombreux réglages de performance dans les fichiers de configuration.
• Fabric / Forge / NeoForge : mods côté client et serveur, charge très variable selon les mods. Un seul mod mal optimisé peut à lui seul doubler le MSPT.

Sur un monde modé, la logique reste la même : le tick est un budget de 50 ms, et chaque mod y prélève sa part. La documentation de référence sur les réglages est disponible côté Source.

La RAM : trop peu tue, trop peut aussi nuire

La mémoire n'accélère rien en soi. Elle sert à contenir les chunks chargés, les entités et les données des plugins. Deux échecs classiques :

1. Sous-dimensionnement : la JVM passe son temps à collecter les objets pour libérer de la place. Les garbage collections s'enchaînent, chacune fige le tick quelques millisecondes, et le TPS oscille en dents de scie.
2. Sur-dimensionnement brutal : allouer une quantité énorme sans réglage du collecteur produit de longues pauses GC. Une pause de 400 ms, c'est 8 ticks perdus d'un coup, très visible en PvP.

La bonne pratique consiste à fixer -Xms et -Xmx à la même valeur et à utiliser un jeu de flags G1GC adapté :

java -Xms6G -Xmx6G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC \
  -XX:G1NewSizePercent=30 \
  -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M \
  -XX:G1ReservePercent=20 \
  -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:SurvivorRatio=32 \
  -Dusing.aikars.flags=https://mcflags.emc.gs \
  -jar server.jar nogui

Dans le panel Pterodactyl, ces paramètres se placent dans les variables de démarrage de l'instance. Gardez toujours une marge : la JVM consomme de la mémoire hors tas (métadonnées, threads, buffers réseau), il ne faut donc jamais allouer 100 % de la mémoire disponible au tas.

La distance de simulation : le réglage le plus sous-estimé

Depuis la 1.18, deux paramètres distincts existent dans server.properties :

view-distance=8
simulation-distance=6
max-tick-time=60000
entity-broadcast-range-percentage=100

• view-distance : nombre de chunks envoyés au client. Impact surtout sur la bande passante et le rendu.
• simulation-distance : nombre de chunks réellement tickés (mobs, redstone, cultures, eau, feu). C'est ce paramètre qui pilote directement le MSPT.

Passer de simulation-distance=10 à 6 réduit la surface simulée de façon très significative, sans que les joueurs perdent en visibilité si view-distance reste plus élevé. Ordres de grandeur utiles :

Contexte	view-distance	simulation-distance
Petit groupe privé (2 à 8 joueurs)	10 à 12	8 à 10
Communauté survie (20 à 40 joueurs)	8 à 10	5 à 6
Grosse fréquentation / gros modpack	6 à 8	4 à 5

Diagnostiquer une chute de TPS : méthode pas à pas

1. Mesurer avant de toucher quoi que ce soit

Ouvrez la console du panel et relevez les valeurs sur plusieurs fenêtres temporelles :

/tps
/mspt
/spark tps
/spark health --memory

Le format 20.0, 19.4, 18.7 correspond aux moyennes 1 / 5 / 15 minutes. Une valeur instantanée basse mais des moyennes hautes indique un pic ponctuel (explosion, chargement de chunks, sauvegarde). Des moyennes basses et stables indiquent une charge de fond permanente : entités, plugins, redstone.

2. Lire les logs, ils disent souvent tout

Le message classique :

[Server thread/WARN]: Can't keep up! Is the server overloaded?
Running 4235ms or 84 ticks behind

S'il apparaît toujours à la même heure, cherchez un déclencheur planifié : sauvegarde automatique, rendu de carte web, tâche de nettoyage, redémarrage d'une autre tâche. S'il apparaît de manière aléatoire, orientez-vous vers le profileur.

3. Profiler avec spark

Le profileur reste l'outil décisif. Il échantillonne le thread principal et produit un rapport hiérarchique lisible en ligne :

/spark profiler start --timeout 300 --interval 4
/spark profiler stop
/spark heapsummary
/spark gc

Lancez-le pendant un pic réel, pas sur un monde vide. Dans le rapport, remontez la pile depuis le nœud le plus lourd : vous verrez apparaître un nom de plugin, un mod, une classe d'entité ou une routine de chunk. C'est votre coupable dans 90 % des cas. La documentation complète des options se trouve sur Source.

4. Compter les entités

Les entités sont la première cause de MSPT élevé sur les mondes survie anciens. Villageois entassés, fermes à fer multiples, items au sol jamais ramassés, animaux reproduits sans limite, minecarts en boucle :

/spark tickmonitor
/minecraft:kill @e[type=item,distance=..64]
/forceload query

Sur Paper, l'onglet des entités du rapport spark indique le nombre par type et par monde. Un enclos de 300 villageois dans une base chargée en permanence coûte plus cher que 30 joueurs actifs.

5. Isoler les plugins et mods par dichotomie

Si le profileur ne désigne pas clairement un responsable, procédez par bissection : désactivez la moitié des plugins, mesurez, recommencez. Créez une sauvegarde avant chaque manipulation via le panel, puis restaurez si nécessaire. Cette méthode prend une soirée mais donne une réponse certaine.

Corriger durablement : chunks, entités et configuration

Pré-générer le monde

La génération de terrain à la volée est l'une des opérations les plus lourdes. Un joueur en elytra qui explore une zone vierge génère des centaines de chunks et fait plonger le TPS pour tout le monde. Pré-générer règle le problème une bonne fois :

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

Faites-le en heures creuses, le processus sature volontairement la machine. Combinez ensuite avec une bordure de monde (/worldborder set 10000) pour éviter que l'exploration ne reparte au-delà de la zone générée.

Régler les fichiers de configuration Paper

Quelques réglages à fort impact dans config/paper-world-defaults.yml :

entity-activation-range:
  animals: 16
  monsters: 24
  raiders: 48
  misc: 8
  water: 8
  villagers: 16
ticks-per:
  hopper-transfer: 8
  hopper-check: 8
merge-radius:
  item: 3.5
  exp: 4.0
max-auto-save-chunks-per-tick: 8

Et dans bukkit.yml, la limite de mobs par joueur :

spawn-limits:
  monsters: 40
  animals: 8
  water-animals: 3
  ambient: 1
ticks-per:
  monster-spawns: 4
  autosave: 6000

Réduire les spawn-limits a un effet immédiat sur les mondes très fréquentés, sans casser le gameplay : les mobs continuent d'apparaître, simplement en quantité maîtrisée autour de chaque joueur.

Discipliner les fermes de la communauté

Sur un monde public, la charge vient souvent de trois ou quatre bases. Actions concrètes de modération :

• Limiter les horloges redstone permanentes par un règlement affiché et vérifiable.
• Poser un plafond de mobs par parcelle sur les serveurs à claims.
• Nettoyer automatiquement les items au sol toutes les 5 à 10 minutes avec annonce préalable.
• Interdire les fermes à mobs empilées en nombre déraisonnable dans une même zone chargée.

Surveiller dans la durée

Un TPS sain se maintient. Prenez l'habitude de relever le MSPT chaque semaine, après chaque mise à jour de plugin et après chaque ajout de mod. Le panel Pterodactyl affiche en continu la consommation CPU et mémoire de l'instance : une courbe CPU qui plafonne en permanence pendant que la mémoire reste basse pointe vers un problème de logique de tick, pas vers un manque de RAM. La même méthode de diagnostic s'applique d'ailleurs à d'autres univers gourmands en simulation, comme Serveur Valheim ou l'ensemble des titres listés sur Tous nos serveurs de jeu. D'autres guides techniques sont regroupés sur le Blog Fly-Serv.

Ce qu'il faut retenir sur le TPS serveur Minecraft

Un tick dispose de 50 ms, pas une de plus. Mesurez le MSPT avant d'agir, profilez pendant un pic réel, réduisez la distance de simulation avant la distance d'affichage, fixez proprement la mémoire Java et surveillez les entités. Avec cette méthode, la plupart des chutes se résolvent en configuration, sans rien changer d'autre. Gardez une sauvegarde avant chaque modification.

FAQ

Pourquoi mon TPS affiche 20 alors que le jeu semble saccadé ?

Le TPS plafonne à 20 : il ne montre pas la marge restante. Regardez le MSPT avec /mspt ou /spark tps. Au-delà de 40 ms de moyenne, le moindre pic dépasse le budget de 50 ms et produit des micro-saccades invisibles sur la moyenne TPS. Réduisez la distance de simulation et les entités actives.

Ajouter de la RAM va-t-il augmenter mon TPS ?

Pas directement. La mémoire évite les collectes trop fréquentes, mais le tick reste limité par la fréquence du processeur et par la quantité de travail à traiter. Si le profileur pointe des pauses GC longues, ajustez les flags G1GC et égalisez -Xms et -Xmx. Si le profileur pointe des entités ou un plugin, la RAM n'y changera rien.

Quelle valeur de simulation-distance choisir pour une communauté de 30 joueurs ?

Commencez à 5 ou 6, avec view-distance à 8 ou 10 pour conserver la sensation de profondeur visuelle. Mesurez le MSPT sur 15 minutes en pleine fréquentation, puis ajustez d'un cran à la fois. Chaque unité retirée réduit fortement le nombre de chunks tickés, donc la charge par tick.