Quels critères techniques déterminent vraiment la stabilité d'un serveur Minecraft ?

Les performances serveur Minecraft se jouent sur trois curseurs : la fréquence mono-cœur du processeur, la quantité de mémoire adaptée au moteur utilisé, et la vitesse du stockage. Le reste (plugins, distance de rendu, nombre de connectés) ne fait qu'amplifier ou masquer ces trois facteurs. Voici comment lire les bons indicateurs et diagnostiquer une chute de TPS sans deviner.

TPS et MSPT : les deux chiffres qui disent la vérité

Un monde Minecraft avance par ticks. Le serveur en exécute 20 par seconde, soit une fenêtre de 50 millisecondes pour traiter les entités, la redstone, les chunks, les joueurs et les plugins. Tant que le travail rentre dans cette fenêtre, le TPS reste à 20. Dès qu'il déborde, les ticks s'allongent et tout ralentit en jeu.

Le TPS seul est trompeur : il plafonne à 20 et ne montre rien tant que la machine tient. Le MSPT (millisecondes par tick) est bien plus parlant. Il indique la marge restante avant la saturation.

MSPT moyen	Lecture	Action
Moins de 20 ms	Marge confortable	Rien à faire
20 à 35 ms	Charge sérieuse mais stable	Surveiller aux heures de pointe
35 à 50 ms	Aucune réserve	Profiler avant d'ajouter du contenu
Au-delà de 50 ms	TPS en chute	Diagnostic immédiat

Sur Paper et ses dérivés, deux commandes en jeu suffisent pour relever ces valeurs.

/tps
/mspt

Une moyenne correcte peut cacher des pics violents. Un serveur à 18 ms de moyenne mais qui monte à 90 ms toutes les trente secondes donnera une sensation de saccade permanente. Ce sont ces pics qu'il faut traquer, pas la moyenne.

Fréquence mono-cœur : le vrai moteur des performances serveur Minecraft

Le tick principal de Minecraft est mono-thread. Les entités, la redstone, la physique des blocs et la logique des plugins s'exécutent sur un seul cœur, quelle que soit la puissance totale du processeur. Un CPU à seize cœurs modestes sera systématiquement battu par un CPU à haute fréquence sur une charge Minecraft.

Concrètement, ce qui compte est la fréquence en charge soutenue et la taille du cache. Un Ryzen 9 7950X3D, avec sa fréquence élevée et son cache 3D, avale beaucoup mieux les gros ticks qu'un processeur serveur généraliste cadencé bas. C'est le critère numéro un pour un hébergement Minecraft destiné à une communauté active ou à un modpack lourd.

Ce qui est réellement parallélisé

Les versions récentes de Paper déportent une partie du travail hors du thread principal : génération et sauvegarde des chunks, calculs de lumière, compression réseau. Ces tâches profitent des cœurs supplémentaires. Mais la boucle de jeu, elle, reste séquentielle.

• Mono-cœur rapide : entités, redstone, IA des mobs, plugins, tick des blocs.
• Multi-cœur utile : chargement de chunks, lumière, compression des paquets, sauvegardes.
• Cas particulier : Folia découpe le monde en régions traitées en parallèle, mais impose des plugins compatibles et vise les très grosses populations.

Retenir la règle simple : si le MSPT explose avec peu de joueurs mais beaucoup d'entités, le problème est mono-cœur. S'il explose quand plusieurs joueurs explorent des zones neuves, c'est le pipeline de chunks, donc le stockage et les cœurs secondaires.

Mémoire vive : combien selon Paper, Fabric ou un modpack

La RAM ne rend pas un serveur plus rapide, elle l'empêche de s'écrouler. En sous-allocation, le ramasse-miettes de la JVM tourne en boucle et provoque des micro-freezes visibles en jeu. En sur-allocation, les cycles de nettoyage deviennent plus longs et plus brutaux. La bonne valeur est celle qui correspond au moteur et au contenu chargé.

Configuration	RAM habituelle	Point de vigilance
Paper, moins de 10 joueurs, peu de plugins	2 à 4 Go	Distance de simulation
Paper, 20 à 40 joueurs, plugins de gestion	6 à 8 Go	Entités et fermes à mobs
Fabric avec mods d'optimisation	4 à 6 Go	Compatibilité des versions
Modpack Forge ou NeoForge moyen	8 à 10 Go	Machines et automatisation
Gros modpack, 250 mods et plus	12 à 16 Go	Temps de démarrage et GC

Régler la JVM proprement

Fixer -Xms et -Xmx à la même valeur évite que la JVM redimensionne son tas en pleine partie. Les flags G1GC dits Aikar restent la base éprouvée pour un serveur Minecraft moderne.

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 \
  -jar paper.jar nogui

La mémoire ECC en DDR5 apporte ici un bénéfice discret mais réel : la correction d'erreurs évite des corruptions silencieuses sur des mondes qui écrivent en permanence. Sur un monde de plusieurs dizaines de gigaoctets, c'est une assurance qui ne se voit qu'au moment où elle sert.

Stockage NVMe : l'impact direct sur le chargement des chunks

Un monde Minecraft est une base de fichiers région lue et écrite sans arrêt. Chaque joueur qui se déplace déclenche des lectures de chunks, chaque autosave déclenche une vague d'écritures. Sur un disque mécanique ou un SSD SATA saturé, ces opérations bloquent le thread principal et créent des freezes réguliers.

Le NVMe change surtout deux choses : la latence d'accès et le nombre d'opérations par seconde. C'est ce qui permet à plusieurs joueurs d'explorer simultanément sans que le serveur ne parte en accordéon. Sur un modpack où chaque chunk contient des tuiles techniques, l'écart devient flagrant.

Réduire la pression disque par la configuration

• Baisser view-distance à 6 ou 8 et simulation-distance à 4 ou 5 dans server.properties.
• Pré-générer le monde avec un outil de type Chunky, puis poser une bordure avec /worldborder set.
• Vérifier sync-chunk-writes et espacer les autosaves si les pics coïncident avec les sauvegardes.
• Surveiller la taille du dossier world/region : un monde qui gonfle sans limite finit par peser sur les sauvegardes.

view-distance=8
simulation-distance=5
network-compression-threshold=256
max-tick-time=60000

Les sauvegardes automatiques doivent être planifiées hors des heures de pointe. Une copie complète pendant un événement communautaire produit exactement le pic de latence que l'on cherche à éviter.

Réseau, latence et protection contre les attaques volumétriques

Un TPS parfait ne garantit pas une expérience fluide. Si la liaison réseau sature ou si la latence grimpe, les joueurs subissent du rubber-banding alors que le serveur tourne à 20 ticks. Distinguer les deux est la première étape de tout diagnostic réseau.

Un lien 1 Gbit/s couvre très largement le trafic d'un serveur Minecraft, y compris avec des dizaines de connectés et un resource pack distribué. Le vrai facteur limitant est la latence entre les joueurs et la machine, donc la localisation du point de présence et la qualité du peering.

Attaques et disponibilité

Les serveurs Minecraft publics sont des cibles fréquentes, souvent pour des motifs de rivalité entre communautés. Une protection anti-DDoS active en permanence au niveau de l'infrastructure filtre les floods volumétriques avant qu'ils n'atteignent le processus Java. Chez Nexus Games, cette protection est incluse par défaut sur les machines de jeu.

Côté administration, le reste relève des pratiques standards : mot de passe RCON solide, port RCON non exposé publiquement, whitelist sur les serveurs privés, plugins à jour et sauvegardes testées. Un plugin abandonné depuis plusieurs versions est un risque autant qu'un frein aux performances.

Diagnostiquer soi-même une chute de ticks

Avant d'augmenter les ressources, il faut savoir ce qui consomme. Le profileur spark est l'outil de référence, disponible en plugin Paper comme en mod Fabric ou NeoForge. Il produit un rapport lisible et partageable qui pointe la méthode exacte responsable des pics.

/spark profiler start --timeout 300
/spark profiler stop
/spark tps --memory
/spark health

Lire le rapport dans le bon ordre

1. Identifier le thread : si la charge est sur le thread principal, cherchez plugins et entités. Sur les threads de chunks, regardez le stockage et la distance de vue.
2. Repérer le plugin : spark attribue le temps par package. Un plugin qui pèse plusieurs millisecondes par tick est un candidat au remplacement.
3. Compter les entités : la commande /spark heapsummary et les plugins de listing de mobs révèlent les fermes hors de contrôle.
4. Vérifier le GC : des pauses longues et régulières signalent une allocation mémoire mal calibrée, pas un manque de CPU.

Les causes récurrentes

• Fermes à mobs ou à items surdimensionnées, souvent construites par un seul joueur.
• Horloges redstone laissées actives dans un chunk maintenu chargé.
• Plugin de protection de zones qui scanne à chaque pose de bloc.
• Hoppers en cascade, particulièrement gourmands sur les gros builds techniques.
• Distance de simulation trop élevée pour la taille de la communauté.

La documentation officielle de Paper détaille chaque option de paper-world-defaults.yml, notamment les portées d'activation des entités qui donnent les gains les plus rapides : Source. Les articles du Blog Nexus Games reviennent régulièrement sur ces réglages, et la logique reste comparable sur les autres jeux de tous nos serveurs de jeux.

Conclusion

Priorisez la fréquence mono-cœur avant tout le reste : c'est elle qui fixe le plafond réel de votre monde. Ajustez ensuite la mémoire au moteur utilisé, sans jamais sur-allouer, et gardez un stockage NVMe pour absorber les vagues de chunks. L'erreur la plus fréquente reste d'ajouter des ressources sans avoir profilé. Lancez spark, lisez le MSPT, corrigez la cause identifiée. Dans huit cas sur dix, un plugin ou une ferme suffit à expliquer la chute.

FAQ

Pourquoi mon serveur lag alors que le TPS affiche 20 ?

Parce que le ralentissement vient du réseau ou du client, pas de la boucle de jeu. Vérifiez le ping des joueurs concernés, la distance de rendu côté client et la présence d'un resource pack lourd. Des pauses de ramasse-miettes trop longues produisent aussi ce symptôme : le TPS moyen reste bon, mais des blocages de plusieurs centaines de millisecondes se répètent. La commande /spark health affiche la latence de tick et les temps de GC pour trancher entre les deux causes.

Faut-il pré-générer le monde pour stabiliser un serveur Minecraft ?

Oui, dès que plusieurs joueurs explorent en même temps. La génération de terrain neuf est l'une des opérations les plus lourdes, car elle combine calcul de bruit, structures, lumière et écriture disque. Pré-générer avec un outil comme Chunky pendant une période creuse déplace ce travail hors des heures de jeu. Associez la pré-génération à une bordure de monde définie avec /worldborder set pour éviter que l'exploration ne reparte à l'infini et ne gonfle la taille des sauvegardes.

Plus de joueurs connectés fait-il forcément baisser le TPS ?

Non, la relation n'est pas linéaire. Vingt joueurs rassemblés dans un même hub coûtent souvent moins cher en temps de tick que cinq joueurs dispersés sur des milliers de blocs, car chacun maintient ses propres chunks chargés et actifs. Ce qui pèse vraiment, c'est le nombre de chunks tickés, la quantité d'entités vivantes et les mécanismes automatisés laissés en fonctionnement. Réduire la distance de simulation limite cette dispersion sans dégrader la sensation visuelle.