Comment corriger le lag d’un serveur Minecraft

Lag serveur, lag réseau ou lag client ?

Le test le plus rapide consiste à demander si tout le monde lag au même moment. Un serveur qui prend du retard fige tous les joueurs ensemble ; une mauvaise connexion ou un PC lent ne touche que son propriétaire. La suite de ce guide porte sur le lag serveur.

D’abord mesurer : TPS, MSPT et spark

Un serveur Minecraft tourne à 20 ticks par seconde, chaque tick dispose donc de 50 ms pour se terminer. Deux chiffres indiquent comment il s’en sort :

• TPS (ticks par seconde) : 20 signifie que le serveur suit ; en dessous de 20, le monde ralentit.
• MSPT (millisecondes par tick) : la durée de chaque tick. Sous 50 ms, il reste de la marge ; au-delà de 50 ms, le serveur prend du retard.

Paper propose /tps et /mspt, mais sa propre documentation renvoie vers spark, intégré à Paper depuis la 1.21 et disponible en mod pour Fabric, Forge et NeoForge :

/spark tps
/spark health
/spark ping

/spark tps affiche le TPS des dernières secondes et minutes et — plus utile — les durées de tick en minimum, médiane, 95e centile et maximum. /spark ping affiche le ping des joueurs, ce qui tranche la question « serveur ou réseau ». /spark health ajoute le CPU, la mémoire et le disque.

Trouver la cause avec un profil spark

Les chiffres disent que le serveur lag ; un profil dit pourquoi. Lancez-en un pendant que le lag se produit et laissez-le tourner quelques minutes :

/spark profiler start --timeout 300

Une fois terminé, spark publie un lien vers sa visionneuse web. Dans celle-ci :

1. Ouvrez le Server thread — le thread principal qui fait tourner le monde. C’est là que vit le lag.
2. Dépliez les entrées aux pourcentages les plus élevés : c’est là que part le temps de tick.
3. Passez à la vue Sources pour voir le temps réparti par plugin ou mod. Un plugin ou un mod qui occupe une grande part du thread principal est généralement votre réponse.

Deux autres outils aident face à un lag intermittent : /spark tickmonitor signale chaque tick trop long, et /spark profiler start --only-ticks-over 100 n’enregistre que les ticks lents, pour qu’un pic rare ne soit pas noyé dans la moyenne.

Les correctifs qui comptent, dans l’ordre

1. Distance de rendu et de simulation

Dans server.properties, simulation-distance définit jusqu’où, autour des joueurs, le monde est réellement simulé — mobs, cultures, redstone — et view-distance jusqu’où les chunks sont envoyés aux joueurs. Les deux valent 10 par défaut. Baisser simulation-distance est souvent le gain le plus important : essayez 6 à 8, et gardez view-distance un peu plus haut pour que le monde paraisse toujours ouvert. Ce sont des points de départ, pas des valeurs officielles ; mesurez avant et après.

2. Prégénérer le monde

Générer de nouveaux chunks est l’une des opérations les plus coûteuses pour un serveur, et des joueurs qui explorent dans des directions différentes l’y obligent en permanence. Le plugin (ou mod) Chunky génère la carte à l’avance :

chunky radius 5000
chunky start
chunky pause
chunky continue

Lancez-le quand personne ne joue — une prégénération en cours fait afficher « Can't keep up » au serveur, c’est normal — et mettez-le en pause quand des joueurs se connectent.

3. Entités et fermes

Les fermes à mobs, les halls de villageois et les tas d’objets sont la charge permanente la plus courante. Sur Paper et Spigot, entity-activation-range dans spigot.yml détermine à quelle distance un joueur doit se trouver pour qu’une entité soit entièrement tickée, et merge-radius fusionne les objets lâchés et les orbes d’expérience. Limitez les fermes à mobs avec un plugin ou une règle, et nettoyez les tas d’objets oubliés.

4. Entonnoirs et redstone

Les grandes chaînes d’entonnoirs coûtent cher. Dans spigot.yml, ticks-per.hopper-transfer règle la fréquence à laquelle ils déplacent les objets, et l’option hopper.disable-move-event de Paper les accélère nettement — mais elle casse les plugins de protection qui s’appuient sur cet événement. Pour la redstone, misc.redstone-implementation: ALTERNATE_CURRENT de Paper peut fortement réduire le lag dû à la poudre de redstone, mais il modifie son comportement : testez d’abord vos mécanismes.

5. Le plugin ou mod de votre profil

Si le profil spark pointe vers un plugin ou un mod, la solution est là : mettez-le à jour, allégez sa configuration ou remplacez-le. Aucune quantité de RAM ne rend plus rapide un plugin mal écrit.

« Le TPS est à 20 mais ça lag quand même »

C’est le cas le plus déroutant, et il s’agit presque toujours d’un blocage de tick : la plupart des ticks sont rapides, mais de temps en temps l’un d’eux prend des centaines de millisecondes. La moyenne reste à 20, et pourtant tout le monde ressent un gel.

• Vérifiez la durée de tick maximale dans /spark tps, ou lancez /spark tickmonitor. Des pics de plusieurs centaines de millisecondes le confirment.
• La cause habituelle est un plugin qui attend sur le thread principal — il récupère des skins ou des têtes de joueurs sur internet, envoie des données à un webhook, vérifie des mises à jour ou une licence, ou enregistre un fichier ou une base de données de façon synchrone. Le serveur ne fait rien pendant qu’il attend.
• Profilez l’attente, pas seulement le calcul. Un profil normal montre le travail CPU ; un thread qui attend semble inactif. Utilisez /spark profiler start --thread * pour voir où passe le temps, attentes comprises, et cherchez des appels réseau ou fichier sur le Server thread.

La correction se trouve dans le plugin — des appels asynchrones, ou un autre plugin. Plus de RAM, un CPU plus rapide ou une meilleure connexion n’y changeront rien, car le serveur ne manque de rien : il attend.

Quand la réponse est vraiment la RAM ou le CPU

Minecraft simule le monde sur un seul thread principal. Cela a deux conséquences :

• La vitesse du CPU par cœur compte le plus. Si spark montre le Server thread occupé par le travail normal du monde — entités, chunks, ticks de blocs — et que le MSPT est élevé, un CPU plus rapide aide là où davantage de cœurs n’aideraient pas.
• La RAM n’aide que si elle manque. Signes : le serveur redémarre en atteignant sa limite de mémoire, ou les pauses du garbage collector dominent le profil. Au-delà de ce dont le monde et les mods ont besoin, plus de RAM ne fait rien pour la vitesse des ticks — et un heap surdimensionné et non optimisé peut allonger les pauses du garbage collector.

La quantité de RAM nécessaire et les flags de démarrage qui gardent le garbage collection court sont expliqués dans combien de RAM pour un serveur Minecraft. Le choix entre Paper, Purpur et les autres se trouve dans le meilleur logiciel de serveur Minecraft.

Le lag et votre serveur HytHost

Chaque offre Minecraft HytHost tourne sur le même matériel : CPU Ryzen 7 et Intel i9 avec un boost jusqu’à 5.0 GHz, mémoire DDR4 et stockage NVMe — la vitesse mono-thread dont dépend Minecraft. spark fait déjà partie de Paper, vous pouvez donc profiler depuis la console tout de suite.

Si votre profil montre que le serveur manque réellement de mémoire pour son monde et ses mods, passez à l’offre supérieure depuis le panel ; le monde reste en place. S’il pointe vers un plugin ou une ferme, corrigez cela d’abord — c’est gratuit et ça fonctionne sur toutes les offres. Voir l’hébergement Minecraft, ou les offres plus grandes de l’hébergement Minecraft premium dès €11.65/mois.