Comprendre et optimiser le TPS d'un serveur Minecraft
Par Benjamin D. · PDG
· Mis à jour le 5 septembre 2026 · Lecture 11 min
Sommaire
Le TPS serveur Minecraft est le premier chiffre à regarder quand ton monde devient élastique : mobs qui glissent, blocs qui reviennent après avoir été cassés, redstone qui rate. Ce compteur traduit la capacité de la machine à traiter le monde 20 fois par seconde. Voici comment le lire, comprendre ses chutes et les corriger méthodiquement.
TPS serveur Minecraft : que mesure réellement ce compteur ?
Minecraft fonctionne sur une boucle de simulation appelée tick. Le jeu vise 20 ticks par seconde, ce qui laisse exactement 50 millisecondes pour traiter l'intégralité du monde : déplacement des entités, IA des mobs, croissance des cultures, redstone, propagation des fluides, sauvegarde des chunks, exécution des plugins ou des mods.
Si tout ce travail tient dans 50 ms, le TPS reste à 20. S'il dépasse ce budget, le tick s'allonge et le serveur ne peut plus en produire 20 par seconde : le TPS descend. C'est un plafond, jamais un plancher. Un TPS de 22 n'existe pas.
TPS et MSPT : deux faces du même diagnostic
Le MSPT (millisecondes par tick) est en réalité l'indicateur le plus précis. Le TPS ne bouge pas tant que le MSPT reste sous 50 ms, alors que le MSPT, lui, monte progressivement et révèle une dérive bien avant qu'elle ne soit visible en jeu.
| MSPT moyen | TPS | Ressenti en jeu |
|---|---|---|
| < 20 ms | 20 | Marge confortable, aucune gêne |
| 20 à 40 ms | 20 | Sain, mais peu de marge sur les pics |
| 45 à 50 ms | 19,5 à 20 | Zone critique, micro-freezes sur les pics |
| 50 à 70 ms | 15 à 19 | Mobs saccadés, redstone imprécise |
| > 100 ms | < 10 | Blocs fantômes, dégâts en retard, rubber-banding |
Ne pas confondre TPS et latence réseau
Un joueur qui voit son ping monter à 200 ms n'a pas forcément affaire à un TPS dégradé. La latence dépend du chemin réseau entre le client et la machine ; le TPS dépend du temps CPU consommé par la simulation. Les symptômes se ressemblent (téléportation arrière, coups qui ne passent pas) mais les corrections n'ont rien à voir. Vérifie toujours les deux séparément : /tps ou /mspt côté serveur, et le ping affiché dans la liste des joueurs côté client.
Si tu compares des configurations chez un hébergeur Minecraft, garde en tête que le TPS dépend avant tout de la fréquence par cœur du processeur : la boucle de tick principale reste largement monothread, même sur les versions récentes du jeu. C'est aussi pour cette raison que Fly-Serv s'appuie sur des Ryzen haute fréquence et du NVMe, la sauvegarde des régions étant l'autre point de friction classique.
Pourquoi le TPS chute : les causes fréquentes
Les entités, coupable numéro un
Chaque entité chargée consomme du temps CPU à chaque tick : pathfinding, collisions, vérification du sol, IA. Les fermes à mobs mal conçues, les élevages d'animaux à 300 têtes, les items au sol jamais ramassés et les minecarts en boucle sont responsables de la majorité des chutes durables de TPS.
- Items au sol : chaque stack non fusionné est une entité. Une ferme à cactus non filtrée peut en générer des milliers.
- Villageois : leur IA (métier, lit, poste de travail, gossip) est l'une des plus lourdes du jeu.
- Entités persistantes : mobs nommés ou en laisse ne se dépawnent jamais et s'accumulent sur des mois.
Les chunks chargés en permanence
Plus le nombre de chunks tickés est élevé, plus le travail par tick augmente. Les portails du Nether, les chunks force-loadés, les fermes en périphérie du spawn et une simulation-distance trop généreuse multiplient la surface simulée. Sur un monde fréquenté par 40 joueurs dispersés, la différence entre une distance de simulation de 6 et de 10 est très nette.
La génération de terrain
L'exploration de zones vierges force le serveur à générer le terrain à la volée : bruit, structures, biomes, lumière. C'est l'une des opérations les plus lourdes du jeu, et elle se voit immédiatement dans le MSPT lorsqu'un joueur file en elytra ou en bateau.
Plugins, mods et modpacks
Un plugin qui exécute une requête SQL synchrone dans la boucle principale, un système de protection qui scanne chaque placement de bloc, un mod de machines qui tick des centaines de blocs actifs : tous ajoutent leur temps au budget de 50 ms. Sur les gros modpacks, il est normal de voir le MSPT de base grimper à 25-30 ms avant même l'arrivée du premier joueur.
La mémoire et le garbage collector
Une allocation mémoire mal dimensionnée provoque des pauses du garbage collector Java. Le symptôme est caractéristique : un TPS globalement bon, coupé par des freezes réguliers de plusieurs centaines de millisecondes. À l'inverse, allouer toute la RAM disponible n'est pas une bonne idée : les pauses de collecte s'allongent avec la taille du tas.
Les entrées/sorties disque
La sauvegarde automatique du monde et les sauvegardes planifiées écrivent des fichiers de région volumineux. Sur un stockage lent, cette écriture bloque la boucle principale et fait plonger le TPS toutes les quelques minutes, de façon très régulière. Le NVMe réduit fortement ce phénomène, mais la planification reste importante.
Diagnostiquer une chute de TPS avec méthode
Étape 1 : mesurer avant de toucher quoi que ce soit
Ouvre la console du panel Pterodactyl et relève les valeurs brutes. Sur Paper et ses dérivés :
/tps
/mspt
/spark healthreport/tps renvoie trois moyennes (1 min, 5 min, 15 min). Une valeur à 20 / 19,8 / 14 indique que la situation vient de se rétablir après un incident. L'inverse (14 / 19 / 20) signale une dégradation en cours.
Surveille aussi les lignes de log de ce type :
[Server thread/WARN]: Can't keep up! Is the server overloaded? Running 4213ms or 84 ticks behindUn message isolé au démarrage est normal. Répété toutes les deux minutes, il indique une saturation réelle.
Étape 2 : profiler avec spark
spark est l'outil de référence pour identifier ce qui consomme le temps de tick. Dépose le jar dans le dossier plugins/ (ou mods/), redémarre l'instance, puis lance un profil pendant une période de charge réelle :
/spark profiler start --timeout 300 --thread "Server thread"
/spark profiler stopLe rapport généré donne un arbre d'appels trié par temps consommé. Tu y repères en quelques secondes si le poids vient de EntityLiving.tick, d'un plugin nommément identifié, de la génération de chunks ou du garbage collector. La documentation officielle de spark détaille l'interprétation des rapports.
Complète avec les commandes de comptage d'entités :
/spark tickmonitor --threshold 100
/minecraft:kill @e[type=item,distance=..0]Étape 3 : localiser les points chauds du monde
Sur Paper, la commande native permet de cartographier les entités par chunk :
/paper entity list
/paper dumpitem
/paper mobcapsTu obtiens la liste des chunks les plus chargés avec leurs coordonnées. Rends-toi sur place : dans neuf cas sur dix, tu tombes sur une ferme laissée active, un troupeau oublié ou une accumulation d'items dans un système de tri saturé.
Étape 4 : isoler les plugins et les mods
Si le profil pointe un plugin, désactive-le temporairement plutôt que de le supprimer. Depuis le gestionnaire de fichiers du panel, renomme monplugin.jar en monplugin.jar.disabled, redémarre, puis remesure sur la même durée et avec un nombre de joueurs comparable. Procède un élément à la fois : deux changements simultanés rendent la mesure inexploitable.
Étape 5 : vérifier la mémoire
Un rapport /spark healthreport affiche l'usage du tas et l'activité du GC. Si tu constates des collectes complètes fréquentes accompagnées de pauses longues, le problème est mémoire, pas CPU. Depuis la console du panel, tu peux également surveiller l'évolution en direct pendant un pic de fréquentation.
Optimiser et stabiliser le TPS sur la durée
Régler les distances
Dans server.properties, sépare bien les deux paramètres :
view-distance=8
simulation-distance=6
max-tick-time=60000view-distance influence surtout la bande passante et le client ; simulation-distance détermine la surface réellement simulée, donc le TPS. Descendre la simulation à 5 ou 6 sur un monde fréquenté produit un gain immédiat, avec un impact de gameplay limité si tu conserves une distance de vue confortable.
Ajuster les fichiers de configuration Paper
Les valeurs par défaut sont volontairement prudentes. Quelques ajustements dans config/paper-world-defaults.yml et spigot.yml font une différence mesurable :
# spigot.yml
entity-activation-range:
animals: 16
monsters: 24
misc: 4
merge-radius:
item: 3.5
exp: 4.0
# paper-world-defaults.yml
entities:
spawning:
despawn-ranges:
monster:
hard: 96
soft: 32
behavior:
disable-chest-cat-detection: true
chunks:
max-auto-save-chunks-per-tick: 8Ne copie jamais une configuration entière trouvée en ligne : modifie deux ou trois paramètres, mesure, puis continue. La référence de configuration Paper décrit précisément l'effet de chaque clé.
Prégénérer le monde
La génération à la volée est l'une des sources les plus violentes de pics de MSPT. Prégénère un rayon raisonnable en dehors des heures de pointe avec Chunky :
/chunky world world
/chunky radius 3000
/chunky startAjoute ensuite une bordure de monde pour éviter que l'exploration ne reparte de zéro :
/worldborder set 6000
/worldborder warning distance 50Dimensionner la mémoire et le garbage collector
Sur le panel, la ligne de démarrage Java se règle dans les variables de l'instance. Les flags G1GC couramment utilisés donnent des pauses courtes et régulières :
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:G1RSetUpdatingPauseTimePercent=5 \
-XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem \
-XX:MaxTenuringThreshold=1 \
-jar paper.jar noguiFixe -Xms et -Xmx à la même valeur, et laisse toujours une marge par rapport à la mémoire totale de l'instance : le processus Java consomme plus que son tas (métaspace, threads, buffers réseau).
Discipliner le contenu du monde
- Impose une limite d'animaux par ferme via un plugin de gestion d'entités, ou par règlement modéré activement.
- Traque les hoppers en cascade : préfère les systèmes à eau et les chest minecarts, moins lourds à ticker.
- Nettoie les items au sol périodiquement, en annonçant le nettoyage à l'avance pour éviter les pertes.
- Désactive les fermes suspectes plutôt que de les casser : tu pourras confirmer le diagnostic avant d'agir définitivement.
Planifier les sauvegardes intelligemment
Les sauvegardes automatiques sont indispensables, mais elles ne doivent pas tomber pendant le pic de fréquentation du soir. Programme-les en heures creuses depuis le planificateur du panel, et conserve plusieurs points de restauration : une chute de TPS accompagnée d'une corruption de chunk se règle beaucoup plus vite avec une archive propre datant de quelques heures.
Vérifier ce qui vient de l'extérieur
Une saturation réseau se traduit par une latence élevée et non par un MSPT dégradé. Sur l'infrastructure de Tous nos serveurs de jeu, le filtrage anti-DDoS est actif par défaut, ce qui écarte d'emblée l'hypothèse volumétrique. Côté administration, garde les fondamentaux : mot de passe RCON long et unique, whitelist activée sur les phases sensibles, plugins tenus à jour. Un serveur ouvert à tous accumule les bots de spam de connexion, qui pèsent eux aussi sur la boucle principale.
Récapitulatif du protocole
- Mesurer TPS et MSPT sur 15 minutes de charge réelle.
- Profiler avec spark pendant le pic, pas après.
- Identifier le coupable principal : entités, chunks, plugin, GC ou disque.
- Appliquer une seule correction.
- Remesurer dans les mêmes conditions.
- Documenter le changement pour ne pas repartir de zéro au prochain incident.
D'autres guides d'administration et d'optimisation sont disponibles sur le Blog Fly-Serv.
Un TPS stable ne s'obtient pas avec une configuration magique copiée-collée, mais avec une boucle mesure-correction-mesure appliquée sur la durée. Les mondes qui tiennent 20 TPS avec 60 joueurs sont ceux dont l'administrateur relit son profil spark tous les mois.
Conclusion
Le TPS est un thermomètre, pas une maladie. Il descend toujours pour une raison identifiable : entités accumulées, chunks simulés trop nombreux, plugin bavard, pauses mémoire ou écritures disque mal planifiées. Mesure d'abord, profile ensuite, corrige un paramètre à la fois. Cette discipline vaut mieux que toutes les configurations toutes faites trouvées sur les forums.
FAQ
Mon TPS affiche 20 mais les joueurs se plaignent de lag, pourquoi ?Deux explications possibles. Soit le MSPT frôle les 50 ms avec des pics ponctuels au-dessus : le TPS moyen reste bon mais les micro-freezes se ressentent. Tape /mspt pour voir les valeurs maximales. Soit le problème est réseau : compare les pings des joueurs concernés, un ping élevé chez un seul joueur pointe sa connexion, pas la machine.
La RAM ne fait pas monter le TPS, elle évite seulement les pauses du garbage collector. Compte environ 4 Go pour un monde vanilla à 20 joueurs, 6 à 8 Go avec un ensemble de plugins conséquent, davantage sur un gros modpack. Fixe -Xms et -Xmx à la même valeur et garde une marge : sur-allouer allonge les pauses de collecte.
Lance /paper entity list pour obtenir le classement des chunks par nombre d'entités, avec leurs coordonnées. Croise ce résultat avec un profil /spark profiler start pris pendant le pic : si EntityLiving.tick ou HopperBlockEntity.tick domine le rapport, rends-toi sur les coordonnées listées et désactive temporairement le mécanisme pour confirmer.