Améliorer les performances

Votre serveur Minecraft saccade, les blocs cassés réapparaissent, les mobs se figent. Cette page explique comment mesurer le problème avant de toucher aux réglages, puis quoi régler et dans quel ordre. Elle s’adresse à tout propriétaire d’un serveur Minecraft CloudFive, administré depuis panel.cloudfive.xyz.

Un principe à garder en tête : le cœur d’un serveur Minecraft tourne sur un seul fil d’exécution. Ajouter de la mémoire ne le rend pas plus rapide. Ce qui compte, c’est le travail demandé à chaque tick — entités, chunks chargés, plugins. Nos serveurs Minecraft tournent sur Ryzen 9 9950X, DDR5 et NVMe : si ça rame, la cause est presque toujours dans le contenu du monde.

Comprendre le TPS et le MSPT

Un serveur Minecraft exécute 20 ticks par seconde. Deux mesures le résument :

• TPS (ticks par seconde) : 20 est le maximum. En dessous de 19, le jeu ralentit ; à 15, tout le monde le sent.
• MSPT (millisecondes par tick) : le temps réellement passé à calculer un tick. En dessous de 50 ms, le serveur tient les 20 TPS. Au-delà, il décroche.

Le MSPT est la mesure utile, parce qu’il bouge avant le TPS : un serveur à 45 ms affiche encore 20 TPS, mais il n’a plus de marge et le moindre afflux de joueurs le fera tomber.

Sur un serveur Paper ou Spigot, relevez-les depuis la console (guide) :

tps
mspt

Note

Un joueur qui « lague » tout seul alors que les autres vont bien n’a pas un problème de TPS : c’est sa connexion. Les deux symptômes se confondent souvent. Voyez Latence, ping et tickrate pour faire le tri.

Allouer correctement la mémoire

La mémoire de votre serveur est fixée par votre palier, et le panel calcule la mémoire maximale de la machine virtuelle Java à partir de cette valeur. Vous n’avez pas à écrire -Xmx ni -Xms à la main.

Palier Minecraft	Joueurs annoncés	Mémoire	Disque
Essentiel	environ 16	8 Go DDR5	50 Go NVMe
Avantage	environ 32	16 Go DDR5	70 Go NVMe
Performant	environ 48	24 Go DDR5	85 Go NVMe
Expert	environ 64	32 Go DDR5	100 Go NVMe

Détail et tarifs sur la page des offres Minecraft. Pour choisir, voyez Combien de RAM pour un serveur Minecraft ?.

Attention

Forcer un -Xmx égal à toute la mémoire du serveur est contre-productif : Java a besoin de place en dehors du tas, et un tas surdimensionné allonge les pauses du ramasse-miettes. Le serveur se figera moins souvent, mais plus longtemps. Si vous ajoutez des arguments de démarrage dans le panel, laissez-lui la main sur la mémoire.

Deux repères utiles : un serveur vanilla ou Paper avec quelques plugins vit très bien dans la mémoire du premier palier, alors qu’un modpack Forge ou Fabric en demande beaucoup plus — la consommation monte avec le nombre de mods, pas avec le nombre de joueurs.

Un redémarrage quotidien automatique, programmé aux heures creuses, remet la mémoire à plat. Voyez Programmer des tâches automatiques.

Régler view-distance et simulation-distance

Ce sont les deux réglages avec le meilleur rapport effet/effort. Ils se trouvent dans server.properties.

server.properties

view-distance=8
simulation-distance=6

• view-distance : le nombre de chunks que le serveur envoie à chaque joueur. Il pèse sur la bande passante et la mémoire.
• simulation-distance : le nombre de chunks que le serveur calcule autour de chaque joueur — mobs, plantes, redstone. C’est lui qui coûte le plus cher en temps de tick.

1. Arrêtez le serveur (guide).

2. Ouvrez server.properties avec le gestionnaire de fichiers.

3. Descendez view-distance à 8, puis simulation-distance à 6.

4. Démarrez le serveur, laissez vos joueurs revenir, puis relevez mspt dans la console.

5. Si la marge est confortable, remontez d’un cran et mesurez à nouveau. Un réglage se valide avec du monde connecté, pas sur un serveur vide.

Attention aux fermes à mobs

Baisser simulation-distance arrête les mécanismes situés loin des joueurs : les fermes automatiques cesseront de produire quand leur propriétaire s’éloigne. Annoncez le changement, sinon vous recevrez des rapports de bug qui n’en sont pas.

Analyser un rapport de timings

Deviner est une perte de temps : un profilage dit exactement quelle part du tick part où.

1. Laissez le serveur tourner en conditions réelles, avec des joueurs, pendant la période où il rame.

2. Lancez un profilage. Les versions récentes de Paper embarquent spark : spark profiler start, puis spark profiler stop après quelques minutes. Sur les versions plus anciennes, utilisez timings on puis timings report.

3. Ouvrez le lien produit par la console : le rapport s’héberge sur un site public.

4. Lisez-le de haut en bas, les entrées étant classées par part du temps de tick consommé. Ne vous occupez que des trois premières.

5. Appliquez une seule correction, puis refaites une mesure. Deux changements simultanés ne s’évaluent pas.

Ce que vous cherchez dans le rapport :

• un nom de plugin qui revient en haut de liste ;
• des entités (mobs, objets au sol) en nombre anormal ;
• du chargement de chunks continu, signe d’un chunk loader ou de joueurs qui explorent sans arrêt.

Astuce

Gardez le lien du rapport : c’est la pièce la plus utile à joindre à un ticket de support ou à une demande d’aide auprès de l’auteur d’un plugin.

Repérer les plugins et les entités coûteux

Les plugins. Un seul plugin suffit à ruiner un serveur. Si le rapport en désigne un, mettez-le à jour en priorité : la version prévue pour votre version de Minecraft corrige souvent le problème. Sinon, désactivez-le le temps d’une mesure — renommez son .jar en .jar.off dans plugins/, puis redémarrez. Voyez Installer des plugins et des mods.

Les entités. Les trois classiques, dans l’ordre de fréquence :

• les objets au sol qui s’accumulent après une explosion ou une récolte ;
• les élevages de centaines de bêtes dans un même enclos ;
• les fermes à mobs dont la production n’est jamais consommée.

La commande kill @e[type=item] nettoie les objets au sol. Elle ne touche pas aux inventaires, mais elle supprime définitivement ce qui traîne : prévenez vos joueurs avant.

Les réglages fins. Paper et Spigot exposent des paramètres pour calmer les entités : portée d’activation, fusion des objets au sol, limites d’apparition des mobs. Ils vivent dans les fichiers de configuration du moteur, dont l’emplacement change selon les versions (spigot.yml, bukkit.yml, paper.yml ou le dossier config/). Modifiez-les un par un.

Attention

Les configurations de Paper trouvées sur internet sont souvent écrites pour une autre version. Une valeur extrême casse des mécaniques de jeu de façon difficile à diagnostiquer. Prenez une sauvegarde avant (guide), et ne copiez jamais un fichier entier sans savoir ce qu’il contient.

Pré-générer les chunks

Générer du terrain neuf est l’opération la plus coûteuse d’un serveur Minecraft. Un joueur qui part explorer en ligne droite fait chuter le TPS de tout le monde. La solution : générer le terrain à l’avance, une fois, serveur fermé.

1. Fixez une bordure de monde. Un rayon de quelques milliers de blocs suffit à des mois de jeu, et empêche l’exploration infinie :

   worldborder set 6000

2. Installez un plugin de pré-génération (Chunky est le plus répandu) sur un serveur Paper ou Spigot.

3. Lancez la génération en dehors des heures de jeu, avec un rayon identique à la bordure :

   chunky radius 3000
   chunky start

4. Laissez travailler. Comptez de quelques minutes à plusieurs heures selon le rayon, et surveillez la console.

5. Une fois terminé, vérifiez l’espace disque restant dans le panel avant de rouvrir aux joueurs.

Danger

La pré-génération remplit le disque vite — un grand rayon produit plusieurs gigaoctets de fichiers de région. Un disque plein empêche le serveur de sauvegarder et peut corrompre le monde. Commencez petit, mesurez ce que ça occupe, puis agrandissez. Votre quota va de 50 à 100 Go de NVMe selon le palier.

Si ça ne marche pas

La console répète « Can’t keep up! Is the server overloaded? ». C’est le symptôme, pas la cause : le serveur a mis plus de temps que prévu à finir ses ticks. Profilez avant de changer quoi que ce soit. Pendant une pré-génération ou une sauvegarde, ce message est normal.

Le serveur s’arrête ou redémarre tout seul. Regardez la console juste avant l’arrêt. Un message de mémoire insuffisante côté Java, ou un arrêt signalé par le panel, indiquent un dépassement de la mémoire allouée — fréquent sur les modpacks, qui demandent bien plus qu’un serveur Paper à nombre de joueurs égal (comparatif). Allégez les mods, ou montez de palier (guide).

Tout va bien sur le serveur mais les joueurs se plaignent. Si le MSPT est bas et le TPS à 20, le problème est sur le chemin réseau. Vérifiez status.cloudfive.xyz, puis lisez Latence, ping et tickrate. L’anti-DDoS CloudFive filtre en permanence et n’a rien à activer de votre côté — voyez Comprendre l’anti-DDoS CloudFive.

Ça rame tous les jours à la même heure. Croisez avec vos tâches programmées : une sauvegarde ou un redémarrage planifié en pleine affluence produit exactement ce symptôme. Décalez-les (guide).

Rien n’y fait. Ouvrez un ticket de support avec le lien de votre rapport de profilage, le nombre de joueurs au moment de la mesure et la liste de vos plugins. C’est ce qui permet de répondre utilement du premier coup.