Optimiser un serveur Minecraft moddé (anti-lag)

D’abord comprendre : TPS, MSPT et les deux familles de lag

Le serveur vise 20 ticks par seconde (TPS), soit un tick toutes les 50 ms. Le MSPT (milliseconds per tick) mesure le temps réellement consommé par chaque tick : tant qu’il reste sous 50 ms, le serveur tient 20 TPS et tout va bien. Le TPS est donc un indicateur tardif — il ne chute qu’une fois le budget dépassé — alors que le MSPT montre la marge restante : un serveur à 20 TPS avec 45 ms de MSPT est au bord de la rupture. Sur Forge et NeoForge, la commande /forge tps donne un premier aperçu par dimension ; Spark fera beaucoup mieux.

Distinguez aussi le lag serveur du reste : si les mobs se figent et que les blocs minés réapparaissent, c’est le tick serveur (ce guide). Si votre affichage saccade mais que le monde vit normalement, c’est le client — voyez notre guide des mods d’optimisation. Si vos actions répondent en retard alors que le TPS est bon, c’est le réseau ou votre connexion.

Diagnostiquer avec Spark, pas à pas

Spark (Fabric, Forge, NeoForge, Paper) est le profileur de référence : il enregistre ce que fait réellement le serveur pendant quelques minutes et produit un rapport lisible dans le navigateur. Voici la procédure complète.

1. 1

   Installer Spark sur le serveur

   Téléchargez la version de Spark correspondant à votre loader depuis Modrinth et placez le fichier dans le dossier mods du serveur, puis redémarrez. Les commandes exigent le niveau opérateur.

2. 2

   Relever TPS et MSPT

   Exécutez /spark tps : la commande affiche le TPS moyen et le MSPT sur plusieurs fenêtres de temps. Un MSPT médian sous 35 ms est confortable ; au-dessus de 50 ms, le serveur décroche. Notez ces valeurs : ce sont vos chiffres de référence.

3. 3

   Lancer un profil en charge

   Aux heures de pointe — le lag se diagnostique quand il se produit — lancez /spark profiler start --timeout 300 : le profil s’enregistre pendant cinq minutes puis s’arrête seul et affiche un lien vers le rapport.

4. 4

   Lire le rapport

   Ouvrez le lien dans un navigateur et dépliez l’arborescence en suivant les pourcentages les plus élevés. Regardez quelle dimension, puis quel système (entités, block entities, génération de chunks) domine, et surtout quel mod apparaît dans les noms de méthodes : c’est votre coupable probable.

5. 5

   Croiser avec la santé du serveur

   /spark health résume mémoire, temps de GC et charge CPU. Des pauses de GC fréquentes signalent un problème de RAM ou d’arguments Java ; un CPU saturé sur un seul cœur signale que le matériel plafonne.

6. 6

   Corriger une chose, remesurer

   Appliquez une seule correction — réglage, mod, démontage d’une ferme — puis relancez un profil dans les mêmes conditions. C’est la seule façon de savoir ce qui a réellement fonctionné.

Les réglages server.properties qui comptent vraiment

Deux lignes dominent tout le reste. view-distance fixe le rayon de chunks envoyés aux joueurs : 6 à 8 suffisent sur un serveur moddé (10 par défaut), au-delà le coût mémoire et réseau grimpe vite. simulation-distance fixe le rayon où le serveur fait vivre le monde — entités, cultures, machines : c’est elle qui coûte du temps de tick. Passez-la à 4-6 ; sous 4, les fermes à mobs et certains dispositifs redstone cessent de fonctionner, prévenez vos joueurs.

La combinaison gagnante pour la plupart des serveurs moddés : view-distance=7, simulation-distance=5. Les joueurs voient loin, le serveur ne simule que le proche. Complétez par sync-chunk-writes=false (écriture des chunks asynchrone, gain notable sur disque lent) et, si votre pack le permet, une légère baisse des caps de spawn de mobs dans les configs des mods concernés. Chaque réglage modifié se valide au Spark suivant.

Prégénérer le monde avec Chunky

La génération de chunks est le poste le plus coûteux d’un serveur moddé jeune : chaque exploration déclenche biomes, structures et minerais de dizaines de mods à la fois. La solution est de payer ce coût à l’avance, sans joueurs connectés. Chunky (Fabric, Forge, NeoForge, Paper) s’en charge : /chunky radius 3000 puis /chunky start prégénèrent un rayon de 3 000 blocs autour du spawn — comptez plusieurs heures selon le pack et la machine, idéalement de nuit ou avant l’ouverture.

Associez-y une bordure de monde (/chunky border, ou le mod WorldBorder de votre pack) au même rayon : sans limite, le premier joueur parti en exploration avec un élytra recréera du lag de génération à l’infini et fera enfler la sauvegarde. Prégénérez aussi le Nether (rayon huit fois plus petit pour couvrir la même surface logique) et augmentez le rayon plus tard si la population grandit.

Installer la stack de mods de performance serveur

Une fois les réglages posés, les mods de performance font gagner le reste : Lithium allège chaque tick, C2ME parallélise les chunks, Krypton optimise le réseau, FerriteCore réduit la mémoire, ModernFix corrige et accélère. Tous sont côté serveur uniquement — vos joueurs n’installent rien — et disponibles sur Fabric comme NeoForge en 2026.

La liste détaillée — rôle de chaque mod, loaders exacts, équivalents pour l’ancien Forge et pièges de compatibilité — fait l’objet de notre guide dédié aux mods d’optimisation, lié en bas de page. Retenez la règle d’or : ajoutez les mods un par un et validez chacun par un profil Spark, car deux mods touchant au même système peuvent se neutraliser ou crasher.

La chasse aux causes de gameplay

Sur un serveur moddé installé depuis des mois, le lag vient rarement de la technique : il vient des constructions. Le rapport Spark vous dira laquelle de ces familles domine chez vous.

• Fermes à mobs surdimensionnées : des centaines d’entités vivantes qui pathfindent en permanence. Imposez des systèmes d’abattage automatique et des caps raisonnables par joueur.
• Tapis de hoppers : chaque hopper vérifie son inventaire à chaque tick. Remplacez les lignes de hoppers par les tuyaux, convoyeurs ou conduits de vos mods tech, incomparablement plus légers.
• Objets au sol : une ferme qui déborde ou un mort non ramassé laissent des milliers d’entités item. Réduisez leur durée de vie dans les configs ou via un mod de nettoyage périodique.
• Chunk loaders oubliés : chaque zone maintenue chargée est simulée en continu, joueur présent ou non. Faites l’inventaire régulier des chunk loaders et limitez-les par joueur.
• Block entities en masse : des milliers de machines, coffres et câbles actifs pèsent même à l’arrêt. Encouragez des usines compactes — quelques machines rapides plutôt que des centaines de lentes.
• Une dimension oubliée : le rapport Spark par dimension révèle parfois qu’un monde minier ou une dimension de mod concentre le lag — souvent une ferme ou un chunk loader qu’on n’y cherchait pas.

Quand c’est le matériel ou l’hébergement, le reconnaître

Si, après réglages, prégénération, mods et grand ménage, le MSPT reste haut avec un profil Spark sans coupable évident, le serveur manque simplement de puissance. Le tick principal de Minecraft reste monothread : c’est la performance par cœur du processeur qui compte, pas le nombre de cœurs. Un gros pack (400 mods et plus) veut un CPU récent à haute fréquence, 8 à 12 Go de RAM dédiés au serveur et un stockage NVMe — et méfiez-vous des offres d’hébergement mutualisées vendues au nombre de gigaoctets : la RAM ne remplace jamais le CPU.

Attention au faux réflexe inverse : trop de RAM allouée allonge les pauses du ramasse-miettes et crée un lag périodique caractéristique. Les repères d’allocation et les arguments Java adaptés (ZGC ou G1 selon la taille du tas) sont détaillés dans nos guides dédiés, liés ci-dessous. Enfin, si /spark health montre des pointes réseau ou un voisinage bruyant sur une offre mutualisée, le passage sur un serveur dédié ou un VPS bien doté règle ce qu’aucun mod ne peut régler.