Chutes de TPS sur un serveur Minecraft : causes et solutions

Par Benjamin D. · PDG

12 septembre 2026 · Mis à jour le 12 septembre 2026 · Lecture 10 min

Sommaire

Le TPS serveur Minecraft est l'indicateur numéro un quand ton monde se met à saccader : mobs qui glissent, blocs qui reviennent après avoir été cassés, redstone qui déraille. Un TPS sain tourne à 20 ticks par seconde. Dès qu'il tombe sous 18, la partie devient désagréable. Voici une méthode de diagnostic concrète, puis les correctifs qui fonctionnent réellement.

Comprendre le TPS serveur Minecraft avant de toucher à quoi que ce soit

Un tick, c'est une itération complète de la boucle logique du jeu : déplacement des entités, calculs de redstone, croissance des cultures, IA des mobs, sauvegarde progressive des chunks. Le moteur vise 20 ticks par seconde, soit 50 ms de budget par tick. Si le travail à effectuer dépasse ces 50 ms, le tick déborde et le compteur descend sous 20.

Deux métriques comptent vraiment :

TPS : le nombre de ticks réellement exécutés par seconde, moyenné sur 1, 5 et 15 minutes. Utile pour la tendance de fond.
MSPT (milliseconds per tick) : le temps réel consommé par tick. Bien plus précis, car un TPS affiché à 20,0 avec un MSPT à 48 ms signifie que tu es à deux doigts de la rupture.

MSPT moyen	TPS observé	Interprétation
< 25 ms	20,0	Marge confortable, rien à faire
25 – 40 ms	20,0	Charge sensible, surveille les pics
40 – 50 ms	19,x	Zone rouge, une seule ferme suffit à faire basculer
> 50 ms	< 19	Lag ressenti par les joueurs

Erreur classique : confondre TPS bas et ping élevé. Le ping mesure le trajet réseau entre le client et la machine, le TPS mesure la charge CPU du monde. Si ton ping est bon mais que tout le monde saccade en même temps, le problème est côté logique de jeu. Si un seul joueur rame, c'est son réseau ou son client.

Pour l'aspect matériel, ce sont la fréquence CPU mono-cœur et la vitesse du stockage qui pèsent le plus : Minecraft fait encore tourner l'essentiel de sa boucle sur un seul thread, et le chargement de chunks tape lourdement le disque. Une machine Ryzen haute fréquence avec du NVMe chez hébergeur Minecraft change nettement la donne sur un monde chargé en entités.

Diagnostiquer proprement avec spark et les métriques du panel

Lire le TPS en direct

Sur Paper, Purpur ou Spigot, la console te donne l'état instantané :

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

Un TPS à 20 / 20 / 20 sur les trois moyennes, mais des joueurs qui se plaignent : cherche les pics ponctuels avec /spark tps, qui affiche aussi le percentile 95 du MSPT. Ce sont ces micro-freezes de 200 ms qui gâchent le PvP.

Profiler pour savoir QUI consomme

Spark est l'outil de référence. Il échantillonne les stacks Java et te sort un rapport web exploitable, plugin par plugin, monde par monde :

/spark profiler start --timeout 300
# laisse tourner pendant que le lag se produit
/spark profiler stop

Dans le rapport, remonte l'arbre d'appels depuis ServerLevel.tick. Tu vas typiquement identifier l'un de ces coupables :

EntityTick / villager AI : trop de villageois ou de mobs dans un rayon restreint (fermes à fer, élevages).
HopperBlockEntity.tick : chaînes d'entonnoirs surdimensionnées dans un système de tri.
ChunkMap / poi : génération de terrain en continu, souvent des joueurs qui explorent en elytra ou nether portal chunk loading.
Un plugin nommément identifié : le rapport donne directement le package, aucune ambiguïté.

Complète avec l'état des entités par monde :

/spark heapsummary
/minecraft:debug start
# 30 secondes plus tard
/minecraft:debug stop

Croiser avec les graphiques du panel

Le panel Pterodactyl affiche la consommation CPU, RAM et I/O disque en temps réel. Trois combinaisons parlantes :

CPU proche de 100 % sur un cœur + TPS bas → surcharge logique (entités, redstone, plugins).
RAM saturée + pics CPU réguliers toutes les 30 s → garbage collector qui s'affole, mémoire insuffisante ou fuite.
I/O disque élevé + freezes périodiques → sauvegarde du monde ou plugin qui écrit en synchrone.

Garde ces relevés avant/après chaque modification. Sans mesure comparative, tu changes des paramètres à l'aveugle. Tu trouveras d'autres méthodes d'administration côté Blog Fly-Serv.

RAM, JVM et garbage collector : régler la mémoire correctement

Plus de RAM n'égale pas plus de TPS

C'est le réflexe le plus répandu et le plus souvent inutile. La RAM sert à stocker les chunks et entités en mémoire ; elle n'accélère pas les calculs. Passer de 8 à 32 Go sur un monde vanilla à 15 joueurs ne fera pas remonter le TPS d'un seul point. Pire : un heap surdimensionné allonge les pauses du garbage collector, ce qui produit exactement les micro-freezes que tu cherches à éliminer.

Ordres de grandeur raisonnables :

Configuration	RAM cohérente
Vanilla / Paper, 5–10 joueurs	4 Go
Paper + 20 plugins, 20–40 joueurs	6 à 8 Go
Modpack Forge/Fabric moyen (100–150 mods)	8 à 10 Go
Gros modpack type All the Mods	12 à 16 Go

Les flags JVM qui comptent

Le réglage du G1GC change réellement le comportement des pauses. Dans le panel, la ligne de démarrage se modifie via les variables de l'œuf Pterodactyl :

java -Xms8G -Xmx8G \
 -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 --nogui

Points à retenir : -Xms et -Xmx doivent être identiques pour éviter les redimensionnements de heap, et il faut toujours laisser 1 à 2 Go à l'OS et aux threads hors heap. Vérifie aussi ta version de Java : les builds récents de Minecraft exigent Java 21, et les gains de performance entre Java 17 et 21 sont réels sur les pauses GC.

Repérer une fuite mémoire

Si le heap remonte immédiatement à 90 % après chaque cycle GC et que le TPS se dégrade progressivement sur plusieurs heures, tu as probablement un plugin qui accumule des objets. /spark heapsummary liste les classes les plus volumineuses en mémoire. Un redémarrage planifié toutes les 12 ou 24 heures est un pansement acceptable en attendant la mise à jour du plugin fautif.

Chunks chargés, entités et plugins : les vrais gros postes de charge

Réduire le nombre de chunks actifs

Chaque chunk chargé est un chunk que le moteur doit ticker. La distance de vue et la distance de simulation sont les deux leviers les plus rentables, et ils se règlent dans server.properties :

view-distance=8
simulation-distance=5
max-tick-time=60000
sync-chunk-writes=false
network-compression-threshold=256

Passer de view-distance=10 à 8 réduit d'environ 35 % le nombre de chunks par joueur. La distance de simulation, elle, détermine où les mobs bougent et où les cultures poussent : 4 ou 5 suffit largement en survie multijoueur. Les joueurs continuent de voir loin, mais le CPU travaille sur un rayon restreint.

Sur Paper, complète dans config/paper-world-defaults.yml :

chunks:
  auto-save-interval: 6000
  max-auto-save-chunks-per-tick: 8
  prevent-moving-into-unloaded-chunks: true
entities:
  spawning:
    per-player-mob-spawns: true
    despawn-ranges:
      monster:
        hard: 96
        soft: 32
tick-rates:
  mob-spawner: 2
  behavior:
    villager:
      validatenearbypoi: 60

Pré-générer le monde

La génération de terrain à la volée est l'une des opérations les plus lourdes qui existent. Un joueur en elytra dans le Nether peut à lui seul faire chuter le TPS de plusieurs points. La parade : pré-générer une zone et poser une bordure de monde.

# avec le plugin Chunky
/chunky world world
/chunky radius 5000
/chunky start
# puis fixer la limite
/worldborder set 10000

Lance la pré-génération pendant les heures creuses, en surveillant l'I/O disque depuis le panel. Sur du NVMe, l'opération est nettement plus rapide qu'avec un stockage mécanique, mais elle reste intensive.

Maîtriser les entités

Les fermes à mobs, les élevages de 400 poules et les objets au sol non ramassés sont responsables d'une grande partie des chutes de TPS sur les serveurs communautaires. Réglages utiles dans bukkit.yml et les fichiers Paper :

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

Ajoute une limite d'entassement dans les gamerules :

/gamerule maxEntityCramming 12
/gamerule randomTickSpeed 3
/gamerule doFireTick false

Et surveille régulièrement la répartition des entités avec /spark ou un plugin de comptage. Une seule ferme mal conçue peut concentrer 3 000 entités dans quelques chunks.

Auditer les plugins gourmands

La méthode est simple et implacable : profile, identifie, désactive, remesure. Les catégories qui posent le plus souvent problème :

Plugins de protection de zones mal indexés : chaque pose de bloc déclenche une vérification linéaire sur des milliers de régions.
Anti-lag automatiques : ironiquement, certains consomment plus qu'ils n'économisent en scannant les entités chaque tick.
Économie / logs avec base SQLite en synchrone : chaque transaction bloque le thread principal. Bascule sur MySQL/MariaDB avec pool de connexions quand le plugin le permet.
Plugins de map dynamique : le rendu doit être asynchrone et limité en threads.
Scripts personnalisés avec des boucles sur tous les joueurs connectés chaque tick.

Procède par dichotomie : coupe la moitié des plugins, mesure, recoupe. Renomme simplement les .jar en .jar.disabled depuis le gestionnaire de fichiers du panel, puis redémarre. Prends une sauvegarde avant chaque campagne de tests : la fonctionnalité de sauvegarde automatique te permet de revenir en arrière si un plugin d'économie perd ses données.

Choisir le bon core

Passer de Spigot à Paper apporte un gain immédiat sans configuration particulière, grâce aux optimisations de chunks, d'entités et de collisions. Purpur et Pufferfish vont plus loin avec des réglages de tick dynamique. Côté moddé, Fabric avec Lithium, Starlight et FerriteCore réduit sensiblement la charge par rapport à Forge nu. Vérifie toujours la compatibilité de tes plugins avant migration, et consulte la documentation de configuration Paper pour le détail de chaque option.

Enfin, garde en tête que le TPS dépend aussi de la machine sous-jacente : un CPU partagé et saturé par d'autres instances plafonne quoi que tu fasses. Les mêmes principes s'appliquent d'ailleurs à d'autres jeux gérés depuis le même panel, comme sur Tous nos serveurs de jeu.

Checklist d'intervention rapide

Relever TPS et MSPT sur 15 minutes avec /spark tps.
Lancer un profiling de 5 minutes pendant un pic de fréquentation.
Vérifier l'occupation du heap et la fréquence des pauses GC.
Réduire view-distance et simulation-distance, redémarrer, remesurer.
Compter les entités par chunk et démanteler ou limiter les fermes abusives.
Désactiver par lots les plugins suspects identifiés dans le rapport spark.
Pré-générer le monde et poser une bordure.
Documenter chaque changement et sa mesure associée.

En résumé

Les chutes de ticks ne se corrigent pas en ajoutant de la mémoire au hasard. On mesure avec spark, on identifie la source exacte, on ajuste distance de vue, entités et plugins, puis on revérifie. Cette boucle mesure-correction-mesure prend une heure et transforme durablement le confort de jeu de ta communauté, sans toucher au gameplay.

FAQ

Pourquoi mon TPS reste à 20 alors que les joueurs signalent du lag ?

Deux causes possibles. Soit le MSPT frôle les 50 ms avec des pics ponctuels invisibles dans la moyenne du TPS : vérifie le percentile 95 avec /spark tps. Soit le problème est réseau et non logique : compare les pings via /spark ping. Un ping élevé chez tous les joueurs pointe vers la connexion, pas vers la charge CPU.

Augmenter la RAM allouée peut-il faire baisser le TPS ?

Oui. Un heap trop grand allonge les cycles du garbage collector : les pauses passent de 50 ms à plusieurs centaines de millisecondes, ce qui provoque des freezes visibles. Alloue le strict nécessaire, garde -Xms égal à -Xmx, et surveille la courbe mémoire dans le panel pour valider ton réglage.

Quelle distance de simulation choisir pour 30 joueurs ?

Une valeur de 4 ou 5 est un bon compromis. Les mobs et cultures restent actifs autour de chaque joueur, tandis que le nombre de chunks tickés chute fortement. Garde view-distance à 8 pour que le paysage reste visible au loin : c'est la simulation, pas l'affichage, qui coûte du temps de calcul.