Comprendre le TPS d'un serveur Minecraft et corriger les ralentissements

Le TPS serveur Minecraft est l'indicateur le plus fiable pour savoir si ton monde tourne correctement ou s'effondre sous la charge des joueurs, des entités et des redstones. Ce chiffre, censé rester proche de 20, chute dès que la RAM, le mono-cœur ou la distance de simulation deviennent le facteur limitant. Voici comment comprendre et diagnostiquer le problème.

Comprendre le TPS serveur Minecraft et les facteurs qui le dégradent

Le TPS (ticks par seconde) mesure le nombre de fois où le monde est mis à jour chaque seconde. Un serveur Minecraft en bonne santé tourne à 20 TPS constant : chaque tick dure 50 millisecondes, ni plus ni moins. Dès qu'un tick prend plus de temps à s'exécuter, le moteur ralentit tout le reste pour rester synchronisé, et c'est là que les joueurs ressentent des saccades, des téléportations en escalier ou des animaux qui se figent en plein mouvement.

Trois facteurs expliquent l'écrasante majorité des chutes de TPS observées en production :

• La RAM allouée et sa gestion par le garbage collector : trop peu de mémoire provoque des pauses de nettoyage fréquentes et longues (GC pause), qui gèlent le monde entier pendant quelques centaines de millisecondes.
• Le mono-cœur du moteur de jeu vanilla : la boucle principale de simulation (main thread) tourne sur un seul cœur, même si la machine dispose de plusieurs cœurs physiques. Un CPU avec une fréquence élevée par cœur pèse donc plus qu'un CPU avec beaucoup de cœurs mais une fréquence faible.
• La distance de simulation et la distance de vue : plus ces valeurs sont hautes, plus le serveur doit calculer d'entités, de blocs actifs et de chunks chargés à chaque tick, ce qui alourdit directement la charge du thread principal.

Ces trois éléments interagissent : une distance de simulation élevée sur une machine avec peu de RAM et un CPU à fréquence modeste cumule tous les symptômes en même temps, rendant le diagnostic plus confus si on ne les sépare pas.

Si ta communauté grossit et que tu veux repartir sur une base matérielle taillée pour absorber ces pics (Ryzen à fréquence élevée, stockage NVMe, anti-DDoS inclus), un hébergeur Minecraft comme Fly-Serv permet de repartir sur une configuration dimensionnée dès l'installation plutôt que de rustiner un serveur sous-dimensionné.

Diagnostiquer une chute de TPS étape par étape

Avant de changer quoi que ce soit dans la configuration, il faut isoler la cause réelle. Un diagnostic bâclé mène à des optimisations inutiles, voire contre-productives.

Lire le TPS et le MSPT en direct

La commande native donne une première lecture, mais elle est peu précise sur les serveurs modernes basés sur Paper ou Purpur :

/tps

Sur une distribution Paper, préfère la commande qui affiche le temps moyen par tick (MSPT) sur les dernières minutes :

/tick
/mspt

Un MSPT stable sous 50 ms signifie que le serveur tient ses 20 TPS. Au-delà, chaque milliseconde supplémentaire se traduit directement par une perte de TPS proportionnelle.

Profiler avec spark

Le plugin spark, largement utilisé par la communauté technique Minecraft, permet d'identifier précisément quelle méthode, quel plugin ou quelle entité consomme le plus de temps CPU sur le thread principal :

/spark profiler start
/spark profiler stop
/spark tps
/spark healthreport

Le rapport généré affiche un arbre d'appels : si une entrée liée à un plugin de redstone, d'économie ou d'IA de mobs domine le rapport, tu as trouvé ton coupable sans avoir à deviner. Pour la référence complète des commandes, consulte la Source officielle du projet spark intégrée à la documentation PaperMC.

Surveiller la mémoire et le GC

Active les logs du garbage collector au lancement pour repérer les pauses longues. Dans le script de démarrage ou la configuration Java du panel :

java -Xms4G -Xmx8G -XX:+UseG1GC -Xlog:gc*:file=gc.log:time -jar paper.jar nogui

Si le fichier gc.log affiche des pauses régulières supérieures à 500 ms, la RAM allouée est probablement insuffisante par rapport à la charge réelle du monde, ou le tas mémoire (heap) est mal dimensionné.

Vérifier la charge par chunk

La commande suivante, disponible sur Paper, isole les chunks les plus lourds à traiter :

/tps
/chunks

Un pilier de ferme à monstres ou une zone de duplication d'items surchargée en entités apparaît immédiatement dans ce type de rapport.

Optimiser la RAM, le mono-cœur et la distance de simulation

Une fois la cause identifiée, chaque facteur se traite avec des leviers différents, et il ne sert à rien d'agir sur les trois en même temps sans mesurer l'effet de chacun.

Dimensionner la RAM sans excès

Allouer trop de RAM à la JVM n'accélère pas le serveur : cela retarde simplement le moment où le garbage collector doit intervenir, mais quand il le fait, la pause est plus longue. Une règle pragmatique observée sur des mondes de taille moyenne (20 à 40 joueurs, quelques mods légers) :

Nombre de joueurs	RAM recommandée	Remarque
1 à 10	2 à 4 Go	Vanilla ou peu de plugins
10 à 30	4 à 8 Go	Plugins courants, économie, claims
30 à 80	8 à 12 Go	Modpack lourd ou grosse communauté

Le paramètre G1GC (-XX:+UseG1GC) reste la référence pour Minecraft depuis plusieurs années, car il limite mieux les pauses longues que le collecteur par défaut sur des tas volumineux.

Composer avec le mono-cœur

Comme le thread principal ne se répartit pas sur plusieurs cœurs, la fréquence par cœur du CPU compte davantage que le nombre total de cœurs. Un processeur Ryzen avec une fréquence turbo élevée sur un seul cœur actif traite un tick plus vite qu'un CPU avec beaucoup de cœurs à fréquence modeste. Certains plugins (comme les moteurs de génération de terrain multi-threadés ou les gestionnaires de chunk asynchrones) déportent une partie du travail sur des threads secondaires, mais la logique de jeu (redstone, IA, collisions) reste, elle, bloquée sur le thread principal.

Ajuster la distance de simulation

Depuis les versions récentes, Minecraft distingue la distance de vue (rendu visuel côté client) de la distance de simulation (calcul réel côté serveur). Dans le fichier server.properties :

view-distance=10
simulation-distance=6

Réduire la distance de simulation de 10 à 6 diminue fortement le nombre d'entités et de blocs actifs traités à chaque tick, sans dégrader autant le rendu visuel perçu par les joueurs. C'est souvent le levier le plus rentable en rapport gain de TPS / perte de confort de jeu.

Sur les distributions Paper, des réglages plus fins existent dans paper-world-defaults.yml, notamment pour limiter le tick des entités éloignées du joueur ou désactiver certains calculs de collision non essentiels :

entities:
  spawning:
    per-player-mob-spawns: true
chunks:
  entity-per-chunk-save-limit:
    default: -1

Bonnes pratiques pour stabiliser le TPS sur la durée

Un diagnostic ponctuel ne suffit pas : le TPS d'un monde en croissance se dégrade progressivement avec l'accumulation d'entités, de redstone actif et de chunks explorés.

• Limite le nombre d'entités par chunk via max-entity-collisions et surveille les fermes à mobs qui accumulent des dizaines d'entités sans purge.
• Planifie des redémarrages réguliers (toutes les 12 à 24h) pour vider la mémoire fragmentée et repartir sur une JVM propre.
• Garde tes plugins à jour : un plugin mal optimisé qui tourne en boucle sur le thread principal peut ruiner un serveur par ailleurs bien dimensionné.
• Programme des sauvegardes automatiques avant chaque modification de configuration lourde (distance de simulation, plugins, datapacks), pour revenir en arrière rapidement si le TPS se dégrade après un changement.
• Utilise un panel de gestion type Pterodactyl pour consulter la console en direct pendant un test de charge, sans devoir te connecter en SSH à chaque vérification.

Pour les administrateurs qui gèrent eux-mêmes l'infrastructure sur un VPS Pterodactyl ou un VPS Linux, ces réglages s'appliquent de la même manière : le TPS dépend du dimensionnement CPU/RAM de la machine et de la configuration du monde, pas de la marque du serveur. Retrouve d'autres configurations de jeux sur Tous nos serveurs de jeu.

En pratique, un monde stable à 20 TPS combine toujours les trois leviers : une RAM correctement dimensionnée pour éviter les pauses GC longues, une fréquence CPU suffisante pour absorber le mono-cœur du thread principal, et une distance de simulation ajustée au nombre réel de joueurs actifs.

FAQ

Pourquoi mon TPS chute-t-il uniquement quand plusieurs joueurs explorent en même temps ?

Chaque joueur charge de nouveaux chunks autour de lui, ce qui multiplie les calculs de génération de terrain et d'entités simultanément. Réduis la distance de simulation ou pré-génère les chunks explorables avant l'ouverture publique du monde.

Augmenter la RAM allouée suffit-il toujours à améliorer le TPS ?

Non. Si le problème vient d'un plugin lent ou d'une redstone en boucle sur le thread principal, plus de RAM ne change rien au temps de calcul par tick. Profile d'abord avec spark avant d'ajuster la mémoire.

Quelle est la différence entre view-distance et simulation-distance ?

La view-distance contrôle ce que le client affiche visuellement, tandis que la simulation-distance détermine quels chunks le serveur calcule réellement (entités, redstone, croissance). Réduire la simulation-distance allège le serveur sans changer le rendu visuel perçu.