Comprendre et optimiser le TPS d'un serveur Minecraft

Le TPS serveur Minecraft (ticks per second) est la mesure de référence pour juger de la fluidité d'un monde partagé : plus il se rapproche de 20, plus la simulation tourne comme prévu. Dès qu'il chute, les joueurs ressentent des sauts de mob, des portes qui se bloquent, des redstone qui déraillent. Comprendre ce qui influence ce chiffre permet de diagnostiquer le problème avant qu'il ne devienne ingérable.

Comprendre le TPS et ses facteurs techniques

Le TPS correspond au nombre de "ticks" — les cycles de calcul du monde — exécutés chaque seconde. La cible officielle est 20 ticks/s, soit un tick toutes les 50 millisecondes. Quand le serveur n'arrive plus à boucler dans ce délai, il ralentit tout le monde en même temps : mobs, redstone, croissance des cultures, régénération de faim. Le TPS n'est jamais une question de bande passante réseau, c'est une question de calcul brut sur la machine qui fait tourner le monde.

Si tu gères une communauté et que tu veux confier l'infrastructure à une machine dimensionnée pour ce type de charge plutôt que de bricoler un PC personnel en continu, un hébergeur Minecraft dédié apporte du CPU haute fréquence et du stockage NVMe, deux éléments qui pèsent directement sur la stabilité du TPS.

Le poids du mono-cœur sur la simulation

Le moteur de Minecraft (Vanilla comme la plupart des forks Forge, Paper ou Spigot) exécute la boucle principale du monde sur un seul thread. Peu importe le nombre de cœurs disponibles sur la machine : c'est la fréquence d'un seul cœur qui détermine la vitesse à laquelle un tick peut se terminer. Un CPU avec beaucoup de cœurs mais une fréquence modeste par cœur ne compensera jamais un pic de charge sur le thread principal. C'est pourquoi les serveurs Minecraft profitent davantage d'un CPU à haute fréquence par cœur (type Ryzen récent) que d'un processeur multi-cœurs orienté calcul parallèle.

RAM allouée selon le moteur (Vanilla, Forge, Paper, Spigot)

La RAM n'accélère pas directement le TPS, mais son absence le fait chuter brutalement via le garbage collector (GC) de la JVM. Un serveur Vanilla léger tourne avec 2 à 4 Go, un serveur Forge avec des dizaines de mods peut nécessiter 6 à 10 Go, et un Paper/Spigot avec beaucoup de plugins se situe souvent entre 4 et 8 Go. Le problème classique : allouer trop de RAM sans régler le GC provoque de longues pauses ("GC freezes") qui font chuter le TPS pendant une fraction de seconde perceptible par tous les joueurs connectés.

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

Distance de simulation et chargement des chunks

Depuis la 1.18, Minecraft distingue view-distance (ce que le client affiche) et simulation-distance (ce que le serveur calcule réellement : mobs, redstone, croissance). Une simulation-distance trop élevée multiplie le nombre de chunks actifs à chaque tick, donc le nombre de calculs à boucler en 50 ms. C'est souvent le premier réglage à revoir quand un monde a grossi avec le temps sans jamais être ajusté.

Densité d'entités, redstone et fermes

Les fermes automatiques (mobs, cultures, hoppers en cascade) sont la cause numéro un des chutes de TPS sur les serveurs communautaires actifs depuis plusieurs mois. Chaque entité vivante est recalculée à chaque tick : pathfinding, collisions, IA. Un empilement de mobs mal géré (cramming) ou une ferme à hoppers surdimensionnée peut faire chuter le TPS de 20 à 10 en quelques secondes, même sur un matériel correctement dimensionné.

Diagnostiquer une chute de TPS serveur Minecraft

Avant de changer quoi que ce soit dans la configuration, il faut isoler la cause. Trois outils suffisent dans la grande majorité des cas : la commande native, le profiler spark, et le rapport timings.

Lire le TPS en direct

/tps
# Réponse type sur Paper/Spigot :
# TPS from last 1m, 5m, 15m: 20.0, 19.8, 18.4

Une moyenne stable autour de 20 est saine. Une chute sur la fenêtre "1m" indique un pic ponctuel (spawn de mobs, explosion, chargement massif de chunks). Une dégradation continue sur "15m" indique un problème structurel : configuration, plugin mal codé, ferme surchargée.

Profiler avec spark

/spark profiler start
# Laisse tourner 2 à 5 minutes en période de charge
/spark profiler stop

Le rapport généré classe les méthodes qui consomment le plus de temps de tick. C'est souvent là qu'on découvre qu'un plugin de scoreboard mal optimisé, ou une entité custom d'un mod, monopolise le thread principal.

Timings report (Paper/Spigot)

/timings on
# attendre quelques minutes en jeu
/timings paste

Plage TPS	État	Action recommandée
19.5 - 20	Normal	Aucune, surveillance périodique
15 - 19.5	Dégradé	Vérifier simulation-distance, plugins, fermes
10 - 15	Critique	Profiler immédiatement (spark/timings)
< 10	Bloquant	Redémarrage + audit config avant relance

Corriger et optimiser le TPS serveur Minecraft

Une fois la cause identifiée, les corrections se font généralement dans trois fichiers : server.properties, la configuration du moteur (paper-world-defaults.yml pour Paper), et la gestion des plugins ou mods installés.

Ajuster server.properties

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

Réduire la simulation-distance de 10 à 6 sur un monde très fréquenté suffit souvent à regagner plusieurs points de TPS, sans que les joueurs ne perçoivent de différence visuelle significative.

Régler les plages d'activation d'entités (Paper)

entity-activation-range:
  animals: 16
  monsters: 24
  raiders: 32
  misc: 8
  water: 16

Ces valeurs limitent la distance à laquelle une entité est "active" (donc calculée pleinement) plutôt que mise en veille. Baisser ces plages sur un serveur avec beaucoup de mobs d'élevage réduit mécaniquement la charge par tick.

Pré-générer les chunks plutôt que les laisser se charger à la volée

Le chargement de nouveaux chunks pendant l'exploration est une des causes de micro-freezes. Un outil comme Chunky (plugin Paper) permet de pré-générer une zone entière hors période de forte fréquentation, évitant les pics de génération en temps réel.

/chunky radius 3000
/chunky start

Nettoyer les entités et automatiser les redémarrages

Un redémarrage planifié purge la mémoire accumulée et repart sur une base saine. Sur un panel Pterodactyl, une tâche planifiée peut déclencher un redémarrage propre à heure fixe ; en ligne de commande, un script cron appelle simplement le processus du jeu :

0 5 * * * systemctl restart minecraft-server.service

Combiné à des sauvegardes automatiques avant chaque redémarrage, ce type de routine limite les pertes en cas de mauvaise surprise après un patch ou l'ajout d'un plugin instable. Pour comparer les configurations disponibles selon le jeu concerné, la page Tous nos serveurs de jeu détaille les architectures proposées, et le Blog Fly-Serv couvre d'autres angles d'optimisation par jeu.

FAQ

Pourquoi mon TPS chute uniquement quand plusieurs joueurs sont connectés en même temps ?

Chaque joueur charge des chunks supplémentaires et déclenche plus d'entités actives (mobs, particules, redstone à proximité). La charge par tick augmente avec la population simultanée, d'où l'intérêt de réduire la simulation-distance ou les plages d'activation d'entités sur les serveurs très fréquentés.

Ajouter de la RAM peut-il faire remonter un TPS bas ?

Seulement si la chute vient d'un garbage collector saturé par manque de mémoire disponible. Si la cause est le thread principal saturé par des calculs (fermes, mobs, plugins), ajouter de la RAM ne change rien : il faut réduire la charge de calcul, pas la mémoire allouée.

Comment savoir si un plugin ou un mod est responsable de la baisse de TPS ?

Lance un profiler comme spark pendant une session de charge normale, puis consulte le rapport généré : il classe les méthodes par temps de tick consommé, ce qui permet d'identifier directement le plugin ou mod fautif sans désinstaller à l'aveugle.