15 astuces pour optimiser un serveur Minecraft

Introduction

Un serveur Minecraft qui rame, ce n'est presque jamais une fatalité matérielle : c'est très souvent une configuration par défaut jamais retouchée. Entre le fichier server.properties généré à la première installation, les valeurs par défaut de Paper, Spigot ou Bukkit, et des plugins installés sans jamais être surveillés, il y a une marge énorme entre un serveur qui tourne « à peu près » et un serveur qui tient une bonne cadence avec du monde connecté. Voici 15 astuces concrètes, à appliquer une par une, pour optimiser un serveur Vanilla, Paper, Spigot ou moddé chez serv-minecraft. Chaque réglage est expliqué avec le fichier concerné et la valeur à modifier.

Astuce 1 : ajuster view-distance et simulation-distance

Ce sont les deux réglages qui pèsent le plus lourd sur la charge CPU d'un serveur. view-distance contrôle le nombre de chunks chargés et envoyés autour de chaque joueur, simulation-distance contrôle jusqu'où le monde est réellement simulé (mobs, redstone, cultures). Les valeurs par défaut (souvent 10) sont confortables mais coûteuses. Sur le panel serv-minecraft, ouvrez l'onglet Réglages de votre serveur : les deux champs view-distance et simulation-distance sont modifiables directement, sans passer par un éditeur de fichier.

• Petit serveur entre amis : 8 à 10 suffit largement.
• Serveur avec plugins et beaucoup de monde connecté : descendez à 6-8 si le TPS décroche.
• Modpack technique avec beaucoup de machines actives : privilégiez une simulation-distance basse (5-6) plutôt qu'une view-distance basse, pour garder un rendu correct sans simuler trop loin.

Astuce 2 : nettoyer les autres réglages de server.properties

Au-delà des distances, quelques lignes de server.properties méritent d'être vérifiées :

• spawn-protection : inutile au-delà de quelques blocs si vous avez de la confiance dans votre communauté ou un plugin de protection dédié (WorldGuard, par exemple).
• network-compression-threshold : une valeur trop basse compresse trop de petits paquets et consomme du CPU pour rien ; 256 est un bon point de départ.
• max-tick-time : ne le désactivez pas à la légère, c'est ce qui déclenche le watchdog en cas de blocage anormal du serveur.
• entity-broadcast-range-percentage : réduire cette valeur limite la distance à laquelle les entités sont synchronisées aux joueurs, utile sur un serveur avec beaucoup de mobs ou de mods.

Astuce 3 : régler paper-global.yml

Sur un serveur Paper, la configuration globale se trouve dans config/paper-global.yml (dossier config à la racine du serveur, visible depuis l'onglet Fichiers du panel). C'est là que se trouvent les réglages qui s'appliquent à l'ensemble du serveur, indépendamment du monde :

• Section chunks : fréquence de sauvegarde automatique des chunks, nombre maximum de chunks sauvegardés par tick.
• Section watchdog : délai avant redémarrage forcé en cas de blocage complet du serveur.
• Section collisions : désactiver les collisions entre entités identiques peut alléger un serveur avec énormément de mobs empilés.

Modifiez ce fichier serveur arrêté, puis redémarrez pour appliquer les changements : contrairement à certains plugins, Paper ne recharge pas toujours proprement sa configuration globale à chaud.

Astuce 4 : régler paper-world-defaults.yml par monde

À côté du fichier global, config/paper-world-defaults.yml (et son équivalent par monde) contient les réglages appliqués monde par monde : comportement des hoppers, limites de spawn naturel, gestion des entités. Deux réglages à surveiller en priorité sur un serveur qui rame à cause des redstone et des tris automatiques :

• Section hopper : cooldown appliqué aux hoppers pleins, désactivation de certains événements coûteux liés au déplacement d'items.
• Section entities : limites de spawn et comportement des entités « spawner » (spawneurs de mobs).

Ces deux fichiers (global et par monde) sont complémentaires : le global fixe le cadre du serveur, le par-monde affine selon l'usage réel de chaque monde (survie, créatif, monde annexe).

Astuce 5 : ajuster spigot.yml

Que vous tourniez sur Spigot ou sur Paper (qui hérite de la configuration Spigot), le fichier spigot.yml reste pertinent pour trois réglages qui ont un impact direct sur les performances :

• entity-activation-range : distance à laquelle les entités (animaux, monstres, autres) sont réellement actives et traitées par le serveur plutôt que mises en veille.
• mob-spawn-range : rayon autour du joueur où les mobs peuvent apparaître naturellement, à ne pas confondre avec la view-distance.
• merge-radius : rayon de fusion des items au sol et des orbes d'expérience, pour éviter des centaines d'entités distinctes qui font le même travail.

Réduire prudemment ces trois valeurs peut faire gagner plusieurs points de TPS sur un serveur avec beaucoup de mobs, sans changement visible pour les joueurs.

Astuce 6 : ajuster bukkit.yml

Plus modeste mais toujours utile, bukkit.yml contrôle notamment :

• spawn-limits : le nombre maximum de monstres, animaux, animaux aquatiques et mobs ambiants pouvant exister simultanément sur le serveur.
• ticks-per (monster-spawns, animal-spawns) : la fréquence des tentatives de spawn naturel ; l'augmenter réduit légèrement la charge sans supprimer le spawn.
• chunk-gc.period-in-ticks : la fréquence de nettoyage des chunks inactifs en mémoire.

Ce fichier se modifie serveur arrêté, comme les précédents, depuis l'onglet Fichiers du panel.

Astuce 7 : utiliser les flags JVM Aikar

Le choix des arguments passés à la machine virtuelle Java a un impact réel sur les micro-freezes liés au ramasse-miettes (garbage collector). Le jeu de flags le plus recommandé par la communauté serveur reste celui dit « Aikar » :

java -Xms{RAM}M -Xmx{RAM}M -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

Remplacez {RAM} par la même valeur en Xms et Xmx (allouer directement toute la RAM disponible évite au serveur de devoir en redemander en cours de route). Sur le panel serv-minecraft, ces flags sont déjà appliqués automatiquement selon l'offre : vous n'avez rien à faire, sauf si vous gérez vous-même une ligne de démarrage personnalisée en mode expert.

Astuce 8 : pré-générer le monde avec Chunky

Un monde qui se génère « en direct » au fur et à mesure que les joueurs explorent est une source classique de lag ponctuel : chaque nouveau chunk généré coûte du CPU au moment précis où un joueur avance. Le plugin Chunky (Paper/Spigot) permet de pré-générer une zone entière à l'avance, hors ligne ou à faible charge :

/chunky world world
/chunky radius 5000
/chunky center 0 0
/chunky start

La pré-génération peut prendre du temps selon le rayon choisi, mais elle se fait en tâche de fond et peut être mise en pause (/chunky pause) puis reprise (/chunky continue) sans perte de progression.

Astuce 9 : profiler avec Spark avant d'optimiser à l'aveugle

Avant de changer des réglages au hasard, la bonne pratique est d'identifier précisément ce qui consomme le plus de temps serveur. Le plugin Spark (installable comme n'importe quel plugin, dans le dossier plugins) fournit un profiler léger :

/spark profiler start
/spark profiler stop
/spark tps
/spark health

La commande /spark profiler stop génère un lien vers un rapport détaillé, plugin par plugin et méthode par méthode, qui montre exactement où part le temps de calcul. C'est l'outil à utiliser en premier avant de suspecter un plugin en particulier.

Astuce 10 : garder les timings en complément

Sur les versions où Spark n'est pas installé, le système de timings historique de Spigot/Paper reste disponible en dernier recours :

/timings on
/timings paste

Il donne une vue plus ancienne mais toujours lisible de la répartition du temps entre plugins et tâches internes du serveur. En pratique, Spark est aujourd'hui recommandé en priorité pour sa précision et sa lisibilité, mais les timings restent utiles si un plugin spécifique n'est pas encore compatible avec Spark.

Astuce 11 : maîtriser les entités et les hoppers

Les hoppers sont pratiques pour le tri automatique, mais chaque transfert d'item consomme du temps serveur. Un réseau de dizaines de hoppers qui tournent en continu peut, à lui seul, faire chuter le TPS d'un serveur pourtant peu peuplé. Quelques réflexes :

• Limitez le nombre de hoppers empilés verticalement quand un seul aurait suffi.
• Le réglage hopper de paper-world-defaults.yml (astuce 4) permet d'ajouter un cooldown quand un hopper est plein, pour éviter des vérifications inutiles.
• Sur un monde moddé avec de l'automatisation intensive (type usine), privilégiez les machines de transport propres au mod plutôt que d'empiler des hoppers vanilla.

Astuce 12 : nettoyer les items au sol et les entités inutiles

Les items lâchés au sol (loot de mobs, récoltes, explosions) et les entités abandonnées (chariots vides, bateaux, armor stands oubliés) s'accumulent avec le temps et finissent par peser sur le serveur. Un plugin de nettoyage périodique (avec un message d'avertissement avant suppression) est largement recommandé sur un serveur communautaire actif, en complément du réglage merge-radius vu à l'astuce 5.

Astuce 13 : surveiller les plugins à risque

Tous les plugins ne se valent pas côté performance. Avant d'en installer un, vérifiez :

• La date de dernière mise à jour et la compatibilité annoncée avec votre version de Minecraft.
• Les avis et retours sur sa consommation CPU/RAM (les plugins de scan de zone en boucle, de particules permanentes ou d'anti-triche mal optimisés sont des classiques à surveiller).
• Les doublons de fonctionnalités : deux plugins d'économie ou deux plugins anti-grief qui se chevauchent consomment pour rien et peuvent entrer en conflit.

Pour un serveur orienté plugins, notre page serveur Minecraft plugins détaille les offres adaptées à ce type d'usage.

Astuce 14 : choisir la bonne quantité de RAM selon mods et plugins

Beaucoup de lag vient tout simplement d'un serveur sous-dimensionné pour ce qu'il fait tourner. Quelques repères :

• Vanilla ou Paper sans (ou avec très peu de) plugins : l'offre Start (8 Go, 4,99 €/mois) suffit largement.
• Paper/Spigot avec une vraie liste de plugins (économie, protection, mini-jeux, permissions) : l'offre Plugins (16 Go, 8,99 €/mois) est pensée pour ça.
• Modpack moyen sous Forge, Fabric ou NeoForge : l'offre Moddé (24 Go, 15,99 €/mois), voir notre guide créer un serveur Minecraft moddé.
• Gros modpack très chargé : l'offre Modpack (32 Go, 21,99 €/mois) donne la marge nécessaire.

Toutes les offres et leurs détails sont sur la page offres, avec possibilité de changer d'offre depuis le panel si votre serveur grandit.

Astuce 15 : activer les sauvegardes automatiques

Ce n'est pas un gain de performance à proprement parler, mais c'est l'astuce qui évite de tout reperdre après une mauvaise manipulation, un plugin buggé ou un problème de plugin de redstone qui corrompt une zone. L'option Sauvegardes (4,49 €/mois) crée des points de restauration automatiques, gérables depuis l'onglet Backups du panel : création manuelle à la demande, restauration en un clic, et verrouillage d'une sauvegarde importante pour éviter qu'elle soit supprimée automatiquement.

FAQ

Par quelle astuce commencer si mon serveur rame déjà ?

Commencez par profiler avec Spark (astuce 9) avant de toucher aux fichiers de configuration : ça évite de deviner et de perdre du temps sur un réglage qui n'était pas le vrai problème. Ensuite, view-distance/simulation-distance (astuce 1) et les hoppers (astuce 11) sont les deux causes les plus fréquentes.

Ces réglages fonctionnent-ils aussi sur un serveur moddé (Forge/Fabric/NeoForge) ?

Les flags JVM Aikar (astuce 7), la pré-génération (astuce 8) et le choix de la RAM (astuce 14) s'appliquent à tout type de serveur. Les fichiers paper-global.yml, paper-world-defaults.yml, spigot.yml et bukkit.yml sont en revanche spécifiques à Paper/Spigot et n'existent pas sur un serveur Forge ou Fabric pur.

Faut-il redémarrer le serveur après chaque modification ?

Pour server.properties, paper-global.yml, paper-world-defaults.yml, spigot.yml et bukkit.yml, oui : ce sont des fichiers lus au démarrage, un redémarrage complet est nécessaire pour appliquer les changements.

Combien de temps prend une pré-génération avec Chunky ?

Ça dépend du rayon choisi et de la puissance allouée au serveur : de quelques minutes pour une petite zone à plusieurs heures pour un rayon très large. La tâche tourne en tâche de fond et peut être mise en pause à tout moment.

Ces astuces suffisent-elles si mon offre est trop juste ?

Non : au-delà d'un certain point, aucun réglage ne remplace des ressources suffisantes. Si le TPS reste bas malgré tous ces réglages appliqués, c'est le signal qu'il faut passer à l'offre supérieure via le panel plutôt que de continuer à chercher un réglage miracle.