Comprendre le TPS d'un serveur Minecraft et corriger les chutes de performance

Le TPS serveur Minecraft est l'indicateur numéro un pour juger de la fluidité d'une partie multijoueur : quand il chute sous 20, les joueurs ressentent des saccades, des téléportations de mobs, des interactions retardées avec les blocs. Comprendre d'où vient cette baisse est la première étape avant d'agir.

Le TPS serveur Minecraft : de quoi parle-t-on exactement

Le TPS (Ticks Per Second) mesure le nombre de cycles de calcul que le moteur du jeu exécute chaque seconde. Minecraft vise 20 ticks par seconde en conditions normales, soit un tick toutes les 50 millisecondes. Chaque tick doit traiter la physique des blocs, l'IA des mobs, la redstone, les chargements de chunks et la synchronisation réseau avec les joueurs connectés. Si le traitement d'un tick dépasse 50 ms, le moteur accumule un retard : c'est ce retard cumulé qui se traduit par une chute de TPS visible en jeu.

Le point clé à retenir : Minecraft (Vanilla, Paper, Spigot, Forge ou Fabric) reste un moteur majoritairement mono-thread pour la boucle principale de tick. Peu importe le nombre de cœurs disponibles, c'est la fréquence et l'efficacité d'un seul cœur qui déterminent la vitesse à laquelle chaque tick est traité. C'est pourquoi deux configurations avec un nombre de cœurs identique mais une fréquence différente peuvent afficher un TPS très différent avec la même charge de joueurs et de mods.

Si tu gères une communauté et que tu cherches un environnement pensé pour ce type de charge mono-cœur, la page hébergeur Minecraft de Fly-Serv détaille les configurations Ryzen disponibles pour ce jeu.

Les trois facteurs qui font varier le TPS serveur Minecraft

Trois éléments techniques expliquent la quasi-totalité des chutes de TPS observées en production : la performance mono-cœur du processeur, la quantité de RAM allouée selon le moteur utilisé, et la distance de simulation configurée.

1. La performance mono-cœur du processeur

La boucle de tick principale ne se parallélise pas efficacement, contrairement à d'autres tâches comme le rendu réseau ou la compression des chunks. Un processeur avec une fréquence par cœur élevée traite donc chaque tick plus vite qu'un processeur avec beaucoup de cœurs mais une fréquence modeste. C'est un point souvent négligé quand on choisit une configuration technique : le nombre de vCPU affiché compte moins que la fréquence réelle disponible sur le cœur qui exécute le tick.

2. La RAM selon le moteur utilisé

La quantité de mémoire nécessaire dépend directement du moteur :

• Vanilla / Paper / Spigot : une instance légère (peu de plugins, peu de joueurs) fonctionne correctement avec 3 à 4 Go, mais chaque plugin qui garde des entités ou des caches en mémoire fait grimper ce besoin.
• Forge / NeoForge (modpacks) : les mods ajoutent des entités, des dimensions et des structures de données supplémentaires ; un modpack chargé peut nécessiter 6 à 12 Go selon le nombre de mods actifs.
• Fabric : généralement plus léger que Forge à contenu équivalent, mais la consommation reste corrélée au nombre de mods installés et à leur qualité d'optimisation.

Une RAM insuffisante ne provoque pas directement une chute de TPS, mais elle déclenche des cycles de ramasse-miettes (garbage collection) plus fréquents et plus longs côté JVM, qui eux bloquent la boucle de tick pendant leur exécution. C'est souvent la vraie cause derrière des chutes de TPS ponctuelles et brutales.

3. La distance de simulation et la distance de vue

Deux paramètres du fichier server.properties pèsent directement sur la charge de chaque tick :

view-distance=10
simulation-distance=8

La view-distance détermine combien de chunks sont envoyés aux clients, ce qui pèse surtout sur la bande passante et le CPU réseau. La simulation-distance détermine combien de chunks sont réellement simulés (mobs, redstone, cultures, physique) : c'est ce paramètre qui a l'impact le plus direct sur le TPS, car chaque chunk simulé ajoute des calculs à chaque tick. Réduire la simulation-distance de 10 à 6 sur un monde très peuplé en entités peut suffire à stabiliser le TPS sans changer de matériel.

Diagnostiquer une chute de TPS étape par étape

Avant de changer de configuration matérielle, il faut identifier précisément la source du ralentissement. Voici la méthode à suivre dans l'ordre.

Étape 1 : lire le TPS en jeu

Sur Paper ou Spigot, la commande de base donne une première photographie :

/tps

Elle renvoie une moyenne sur 1, 5 et 15 minutes. Un TPS proche de 20 sur les trois fenêtres indique une charge saine. Un TPS bas uniquement sur la moyenne 1 minute signale un pic ponctuel (explosion, chargement massif de chunks, script lourd) plutôt qu'un problème structurel.

Étape 2 : profiler avec spark

Le profiler spark reste l'outil de référence pour identifier quel plugin, mod ou entité consomme le plus de temps de tick :

/plugins
/spark profiler start
# laisser tourner 2 à 5 minutes en charge réelle
/spark profiler stop

Le rapport généré classe les méthodes par temps CPU consommé. C'est généralement là qu'on retrouve un plugin mal codé, une boucle de redstone excessive ou une génération de terrain qui n'arrive pas à suivre le rythme des joueurs.

Étape 3 : vérifier les logs et le garbage collector

Un GC trop fréquent se repère dans les journaux de la JVM. Si la RAM allouée est trop proche de la consommation réelle, augmenter les paramètres -Xms et -Xmx de la ligne de lancement peut réduire la pression :

java -Xms4G -Xmx8G -jar paper.jar nogui

Attention : donner trop de RAM sans ajuster les flags du garbage collector peut aggraver les pauses au lieu de les résoudre. Les flags Aikar (largement documentés dans la communauté Paper) sont un point de départ standard pour un moteur de type serveur communautaire.

Étape 4 : isoler la cause en désactivant par lot

Si le profiling ne montre rien d'évident, désactive temporairement la moitié des plugins ou mods, observe le TPS, puis réactive progressivement jusqu'à identifier l'élément fautif. C'est plus long, mais souvent nécessaire face à des interactions entre plugins qui ne remontent pas clairement dans un rapport spark.

Tableau récapitulatif des symptômes

Symptôme observé	Cause probable	Action recommandée
TPS bas en continu, peu de joueurs	Simulation-distance trop élevée ou mob farm massive	Réduire simulation-distance, limiter le nombre d'entités
Chutes ponctuelles brèves	Garbage collection JVM	Ajuster -Xms/-Xmx et les flags GC
TPS bas seulement avec certains joueurs connectés	Chargement de chunks / view-distance élevée	Réduire view-distance, activer le pré-chargement
Chute après installation d'un plugin ou mod	Code non optimisé côté plugin/mod	Profiler avec spark, isoler le plugin

Stabiliser durablement le TPS serveur Minecraft

Une fois la cause identifiée, quelques réglages permanents évitent que le problème ne revienne à chaque montée en charge.

• Adapter la simulation-distance à la taille réelle de la communauté plutôt qu'à une valeur maximale par défaut.
• Limiter les entités par chunk via les options de spigot.yml (entity-activation-range, mob-spawn-range) pour éviter les fermes à mobs incontrôlées.
• Planifier des redémarrages réguliers pour purger la mémoire accumulée, plutôt que de laisser tourner une instance plusieurs semaines sans interruption.
• Surveiller le TPS dans le temps, pas seulement au moment d'un lag ponctuel, pour repérer une dégradation progressive liée à la croissance du monde ou du nombre de joueurs.
• Garder des sauvegardes récentes avant tout changement de configuration ou de version, pour pouvoir revenir en arrière si un réglage aggrave la situation au lieu de l'améliorer.

Pour les administrateurs qui pilotent leur installation via un accès technique en ligne de commande, un accès SSH à un VPS permet d'automatiser la surveillance avec un script cron qui interroge la console à intervalles réguliers :

ssh utilisateur@ip_du_vps
crontab -e
*/15 * * * * /usr/local/bin/check-tps.sh

Ce type d'automatisation aide à repérer une dérive du TPS avant qu'elle ne soit signalée par les joueurs. Le panel Pterodactyl, utilisé pour la gestion courante, expose aussi la console live et les fichiers de configuration sans passer par une connexion directe, ce qui simplifie les ajustements rapides de server.properties ou spigot.yml. Pour comparer les options d'infrastructure disponibles pour différents jeux, la page Tous nos serveurs de jeu et la page VPS Pterodactyl donnent une vue d'ensemble des configurations proposées.

Conclusion

Le TPS d'une instance Minecraft dépend rarement d'un seul facteur : fréquence mono-cœur, RAM adaptée au moteur et distance de simulation forment un ensemble à ajuster ensemble. Le diagnostic par étapes, du simple /tps au profilage avec spark, reste la méthode la plus fiable pour identifier la cause réelle avant d'agir.

FAQ

Pourquoi mon TPS chute alors que peu de joueurs sont connectés ?

C'est souvent lié à une distance de simulation trop élevée ou à une accumulation d'entités (fermes à mobs, animaux non gérés). Réduis simulation-distance dans server.properties et vérifie les rapports spark pour confirmer la source.

Ajouter de la RAM suffit-il à corriger un TPS bas ?

Pas toujours. La RAM aide surtout à réduire les pauses de garbage collection, mais si la cause est la performance mono-cœur ou une simulation-distance excessive, augmenter la RAM seule ne résout pas le problème de fond.

Quelle commande utiliser pour vérifier le TPS en temps réel ?

Sur Paper ou Spigot, la commande /tps affiche la moyenne sur 1, 5 et 15 minutes. Pour aller plus loin, le profiler spark identifie précisément quel plugin ou mod consomme le plus de temps de tick.