Lag serveur Minecraft : comment corriger les chutes de TPS

Votre serveur Minecraft saccade. Les joueurs se plaignent de blocs qui reviennent en place, de mobs figés et de circuits redstone qui partent en vrille. La cause est presque toujours la même : votre TPS descend sous les 20.

TPS veut dire Ticks Per Second, les ticks par seconde. Un serveur Minecraft tourne sur une boucle de jeu qui doit exécuter exactement 20 ticks chaque seconde. Chaque tick traite l'IA des mobs, les mises à jour de blocs, le chargement des chunks, les interactions des joueurs et tout ce qui fait vivre le monde. Quand le serveur n'arrive plus à suivre, le TPS chute et tout se met à lagger.

Ce n'est pas la même chose que le lag de FPS ou la latence réseau. Le lag de TPS vient du serveur et touche tous les joueurs connectés en même temps. Un joueur avec une connexion à 1000 Mbps subit exactement le même lag de TPS : sa vitesse de connexion n'y change rien.

Comment vérifier votre TPS

Avant de corriger quoi que ce soit, il faut savoir où vous en êtes. Sur la plupart des serveurs sous Spigot, Paper ou Purpur, tapez /tps dans la console ou dans le chat en jeu. Vous obtenez trois nombres : le TPS moyen sur les 1, 5 et 15 dernières minutes.

• 20 TPS : parfait. Le serveur tourne à pleine vitesse.
• 18-19 TPS : légères baisses. Les joueurs ne remarqueront sans doute rien.
• 15-17 TPS : lag visible. Les mobs saccadent, poser un bloc semble en retard.
• Sous 15 TPS : gros problème. Le serveur n'arrive plus à suivre.

Pour une analyse plus poussée, installez Spark, un plugin de profilage qui montre exactement quelles tâches dévorent votre temps de tick. Il détaille l'usage CPU par tick et permet d'isoler les pires coupables. Lancez /spark profiler start, laissez tourner 2 à 3 minutes pendant une période de lag, puis /spark profiler stop pour récupérer le rapport complet.

Les causes les plus fréquentes de chutes de TPS

1. Trop d'entités

Les entités sont de loin le premier tueur de TPS sur la majorité des serveurs. Chaque mob, objet au sol, wagonnet, porte-armure et boule d'expérience compte comme une entité. Chacune doit être traitée à chaque tick.

Un serveur survie classique avec 20 joueurs accumule facilement des milliers d'entités sur l'ensemble des chunks chargés. Les fermes à animaux avec des centaines de vaches ou de poules sont le coupable typique. Un admin a publié sur Reddit le cas d'un serveur avec 18 000 entités réparties sur 400 chunks chargés : il tournait à 8 TPS.

Comment corriger :

• Fixez des limites d'entités dans bukkit.yml, section spawn-limits. Passer monsters de 70 à 40-50 et animals de 10 à 6-8 fait une différence nette.
• Activez per-player-mob-spawn dans la config de Paper pour répartir le spawn des mobs par joueur plutôt que globalement. Cela évite que la zone d'un seul joueur consomme tout le mob cap.
• Utilisez merge-radius dans spigot.yml pour fusionner les objets au sol et les boules d'expérience proches. Réglez item sur 3.5 et exp sur 4.0.
• Ajoutez un plugin comme ClearLagg pour nettoyer périodiquement les objets au sol et plafonner le nombre d'entités par chunk.
• Encouragez les joueurs à garder des fermes à animaux modestes ou à prévoir un système d'abattage.

2. Chargement des chunks et génération du monde

Chaque fois qu'un joueur explore un terrain neuf, le serveur doit générer les chunks de zéro : calculs de bruit, placement des structures, fusion des biomes, décoration. Sur Paper et ses forks, le chargement des chunks se fait de façon asynchrone, ce qui réduit fortement l'impact sur le thread principal. Sur vanilla, Spigot ou Fabric, en revanche, il tape encore lourdement dans le thread principal.

Si vous n'êtes pas sur Paper, ouvrez server.properties et réglez sync-chunk-writes=false. À lui seul, ce changement améliore sensiblement le TPS sur les serveurs non-Paper en sortant l'écriture des chunks du thread principal.

Comment corriger :

• Pré-générez votre monde avec Chunky. Le travail de génération est fait en amont. Posez d'abord une bordure de monde pour connaître votre rayon cible.
• Posez une bordure de monde pour éviter que les joueurs explorent à l'infini. Un rayon de 10 000 blocs laisse largement de quoi jouer (plus de 300 km² explorables) sans laisser le monde grossir sans fin.
• Dans spigot.yml, baissez view-distance de 10 (valeur par défaut) à 6-8. Cela réduit le nombre de chunks que chaque joueur maintient chargés.
• Dans la config de Paper, réglez simulation-distance sur 3 ou 4. Les joueurs voient loin grâce à view-distance, mais seuls les chunks proches sont simulés. C'est l'un des réglages les plus rentables pour les performances.

3. Redstone et hoppers

Les mécanismes redstone et les systèmes de hoppers sont l'autre grande source de perte de TPS. Chaque circuit redstone actif déclenche des mises à jour de blocs qui se propagent aux blocs voisins. Les hoppers sont particulièrement gourmands : par défaut, ils vérifient à chaque tick s'il y a un objet au-dessus d'eux.

Une seule chaîne de 100 hoppers qui tourne en permanence consomme une part mesurable de votre budget de tick. Sur les serveurs avec de grosses fermes automatisées, le lag lié aux hoppers devient souvent le problème numéro un une fois les entités réglées.

Comment corriger :

• Dans la config de Paper, réglez hopper.disable-move-event sur true. Cela saute l'InventoryMoveItemEvent pour les hoppers et améliore énormément les performances sur les serveurs qui en utilisent beaucoup.
• Augmentez ticks-per.hopper-transfer et ticks-per.hopper-check dans spigot.yml. Passer de 8 à 16 rend les hoppers un peu plus lents mais divise par deux la charge de traitement.
• Envisagez des alternatives aux gros systèmes de hoppers. Des courants d'eau qui convergent vers un seul hopper de collecte sont bien plus efficaces qu'une chaîne de 50 hoppers.

4. Plugins et datapacks

Chaque plugin installé exécute du code sur le thread principal du serveur. Des plugins mal écrits, des plugins qui lancent des requêtes de base de données lourdes en synchrone, ou simplement trop de plugins : tout cela fait chuter le TPS.

Comment corriger :

• Utilisez le profileur de Spark pour identifier les plugins qui consomment le plus de temps de tick. Lancez le profilage pendant un épisode de lag, pas pendant une période creuse.
• Supprimez les plugins que vous n'utilisez pas. Chaque plugin ajoute de la charge même au repos, surtout ceux qui enregistrent des event listeners.
• Vérifiez si vos plugins proposent des options asynchrones pour les opérations lourdes. Un plugin qui interroge une base MySQL sur le thread principal fige tout le serveur pendant la requête.
• Gardez vos plugins à jour. Les développeurs corrigent souvent des problèmes de performance dans les versions récentes.
• Méfiez-vous des plugins anti-cheat sur les petits serveurs : certains sont réputés très lourds et ne valent pas la charge sur un serveur communautaire privé.

5. Matériel insuffisant et configuration JVM

Parfois, le serveur n'a tout simplement pas assez de puissance. La boucle de jeu principale de Minecraft est mono-thread, ce qui veut dire que la fréquence par cœur compte bien plus que le nombre de cœurs. Un processeur 4 cœurs à 5.0 GHz battra un serveur 16 cœurs à 2.5 GHz sur Minecraft.

La RAM compte aussi, mais pas comme la plupart des gens l'imaginent. Trop en allouer allonge les pauses de garbage collection, qui se traduisent par des pics de lag. Pour un serveur à 20 joueurs, 4-6 Go suffisent généralement. Au-delà de 50 joueurs, comptez 8-10 Go.

Les flags JVM d'Aikar réduisent nettement le lag lié au garbage collector. Utilisez ces flags au démarrage de votre serveur :

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 server.jar nogui

Ces flags règlent le garbage collector G1 de Java sur le profil mémoire de Minecraft. La plupart des pics de lag sur un serveur par ailleurs bien configuré viennent du GC, et ces flags règlent le problème.

Autres correctifs matériels :

• Utilisez du stockage SSD. Charger des chunks depuis un disque mécanique est douloureusement lent et se voit directement en chutes de TPS pendant l'exploration.
• Choisissez un hébergeur qui utilise des CPU à haute fréquence. Sur Minecraft, la performance mono-thread fait tout.

Le logiciel serveur compte

Si vous tournez encore sur le serveur Minecraft vanilla, vous laissez beaucoup de performance sur la table. Paper (et son fork Purpur) embarquent des dizaines d'optimisations qui améliorent nettement le TPS sans toucher au gameplay.

L'écart est substantiel. Paper encaisse 2 à 3 fois plus de joueurs que vanilla à TPS égal. Il apporte le chargement asynchrone des chunks, un tick des entités optimisé, un traitement redstone plus rapide et beaucoup d'autres améliorations que vanilla n'a tout simplement pas.

Logiciels serveur recommandés :

1. Paper : le choix standard pour tout serveur sérieux. Remplaçant direct de Spigot avec des gains de performance majeurs.
2. Purpur : fork de Paper avec des options de configuration supplémentaires et des ajustements de confort pour les admins.
3. Folia : fork multithread soutenu par Mojang, pensé pour les très gros serveurs (plus de 100 joueurs). Encore jeune, mais prometteur pour les fortes populations.

Fuyez tout ce qui promet de l'« async partout » ou des performances miraculeuses : c'est en général de l'arnaque ou du code bâclé.

Checklist d'optimisation rapide

Voici le résumé des changements les plus rentables :

Gardez votre serveur fluide

Les chutes de TPS sont pénibles, mais elles se corrigent presque toujours. Commencez par profiler avec Spark pour trouver le vrai goulot d'étranglement. Déroulez ensuite les correctifs ci-dessus, en commençant par les entités et le chargement des chunks : ce sont les coupables les plus courants. Appliquez les flags JVM, à eux seuls ils règlent un nombre surprenant de plaintes sur les pics de lag.

Si vous cherchez un hébergement Minecraft qui vous donne la puissance CPU et le stockage SSD nécessaires pour tenir 20 TPS, jetez un œil à l'hébergement de serveurs Minecraft de DoomHosting. Nos processeurs à haute fréquence sont optimisés pour les charges mono-thread, exactement ce dont Minecraft a besoin pour rester à 20 TPS stables.