Un serveur Minecraft tourne à 20 TPS (ticks par seconde). Tant que chaque tick s'exécute en moins de 50 millisecondes, les joueurs ne ressentent rien. Dès que ce budget est dépassé, les monstres se téléportent, les coffres tardent à s'ouvrir et les redstones ratent leurs cadences. Ce guide vous explique comment mesurer précisément la charge sur votre serveur VPS Linux, identifier la source du problème et corriger chaque paramètre sans sacrifier l'expérience de jeu.
Ressources matérielles et hébergement VPS
Avant d'optimiser la configuration logicielle, vérifiez que votre offre VPS dispose des ressources minimales. La RAM est le facteur le plus critique pour Minecraft Java Edition :
- 1 à 5 joueurs : 4 Go de RAM, 2 vCPU, SSD
- 5 à 15 joueurs : 6 à 8 Go de RAM, 4 vCPU, SSD NVMe
- 15 à 30 joueurs : 12 à 16 Go de RAM, 4 à 6 vCPU, SSD NVMe
- 30 joueurs et plus : serveur dédié avec 32 Go de RAM ou plus
Minecraft est fortement mono-threadé pour la boucle de jeu principale. La fréquence d'horloge (GHz) a plus d'impact que le nombre de coeurs. L'espace de stockage du monde augmente avec l'exploration : un monde de survie actif peut occuper entre 2 et 20 Go. Choisissez une offre VPS avec un espace de stockage suffisant et un système de backup automatique pour sécuriser la progression des joueurs. Votre serveur virtuel privé doit disposer d'une adresse IP dédiée pour que vos joueurs puissent s'y connecter directement depuis le client Minecraft. Vous pouvez aussi configurer un nom de domaine SRV pointant vers votre adresse IP pour une connexion plus simple.
Si vous hésitez entre un serveur VPS cloud et un serveur dédié, notre guide serveur dédié bare metal vs VPS vous aidera à choisir l'hébergement adapté à votre charge de joueurs.
TPS et MSPT : les deux chiffres à surveiller
La commande /tps (disponible sur Paper et Spigot) affiche la moyenne sur 1, 5 et 15 minutes. Une valeur de 20,0 ne signifie pas que le serveur est à l'aise : il peut afficher 20 TPS tout en consommant 48 ms par tick, à deux pas de la saturation. Le chiffre utile est le MSPT (millisecondes par tick), lisible avec /mspt sur Paper. Il donne la médiane et le 95e percentile sur les cinq, dix et soixante dernières secondes.
Le budget est 50 ms. Un serveur sain se situe en dessous de 35 ms en charge normale, avec des pics inférieurs à 48 ms. En accès SSH root sur votre VPS Linux ElypseCloud sous Ubuntu ou Debian, surveillez l'utilisation CPU du processus Java en temps réel :
top -p $(pgrep -f paper) -d 2Un processus Java bloqué à 100 % sur un seul coeur indique que le thread principal du jeu sature. Un serveur VPS avec SSD NVMe délivre des temps d'accès disque bien inférieurs à ceux d'un stockage HDD, réduisant mécaniquement la durée des sauvegardes et des chargements de chunks.
Diagnostiquer avec le plugin Spark
Avant de toucher la moindre configuration, identifiez ce qui consomme réellement les ticks. Spark est un profileur open source gratuit pour les serveurs Paper et Spigot. En accès SSH root, déposez le fichier .jar dans votre dossier plugins/ et redémarrez le serveur Minecraft. Spark expose aussi un serveur Web local pour afficher ses rapports de profiling dans un navigateur.
Pour détecter les pics de lag, lancez depuis la console ou en jeu :
/spark tickmonitor --threshold-tick 50Cette commande surveille chaque tick et signale en chat ceux qui dépassent 50 ms. Une fois un pic observé, lancez un profilage ciblé :
/spark profiler --only-ticks-over 100Spark produit un rapport de monitoring qui liste les méthodes les plus coûteuses tick par tick. Les causes les plus fréquentes : un plugin mal optimisé, une ferme à redstone trop dense, trop d'entités dans une même zone ou un chunk qui tarde à se charger. Une fois la source identifiée, les réglages qui suivent peuvent être appliqués en connaissance de cause.
Si vous soupçonnez un problème d'I/O disque plutôt que de CPU pur, consultez notre guide sur la surveillance des I/O disque avec iostat sur un serveur VPS Linux.
Distances de vue et de simulation : le levier principal
C'est le réglage qui a le plus d'impact sur les performances du serveur virtuel. Dans server.properties :
view-distance=8
simulation-distance=6La distance de vue (view-distance) contrôle le nombre de chunks chargés autour de chaque joueur. Passer de 10 à 8 supprime environ 35 % des chunks chargés par joueur, réduisant d'autant la RAM consommée et la bande passante réseau. La distance de simulation (simulation-distance, introduite en 1.18) détermine jusqu'où les mobs se déplacent, les cultures poussent et les redstones s'exécutent. Réduire la simulation de 10 à 6 allège le CPU sans que les joueurs ne voient de différence visuelle, puisque les chunks restent affichés par le client.
Valeurs recommandées selon la charge :
- Serveur calme, moins de 10 joueurs :
view-distance=10,simulation-distance=8 - Serveur normal, 10 à 25 joueurs :
view-distance=8,simulation-distance=6 - Serveur chargé, 30 joueurs et plus :
view-distance=6,simulation-distance=5
Paper propose en complément une option no-tick-view-distance dans config/paper-world-defaults.yml qui permet d'afficher les chunks jusqu'à 12 blocs sans les simuler. Cette option est utile sur un serveur Minecraft hébergé sur VPS où la RAM est allouée exclusivement à votre instance.
Régler les entités dans spigot.yml
Le fichier spigot.yml contrôle deux choses distinctes : jusqu'à quelle distance une entité tique réellement (activation range) et jusqu'à quelle distance elle est transmise au client (tracking range). L'activation range est celle qui soulage le CPU du serveur virtuel :
world-settings:
default:
entity-activation-range:
animals: 24
monsters: 24
raiders: 48
misc: 12
water: 12
villagers: 24
flying-monsters: 32
entity-tracking-range:
players: 48
animals: 48
monsters: 48
misc: 32
other: 64
hopper-transfer: 8
hopper-check: 8
merge-radius:
item: 3.5
exp: 6.0
mob-spawn-range: 5Les hoppers sont souvent la principale source de lag sur les serveurs avec des systèmes de tri automatique. Passer hopper-check de 1 à 8 divise par huit le nombre de vérifications par tick, sans modifier le débit de transfert si hopper-transfer reste à 8. Ne descendez pas raiders en dessous de 48 : les raids doivent pathfinder depuis loin pour fonctionner correctement.
Réglages Paper pour les chunks et les mobs
Depuis la version 1.19, Paper utilise deux fichiers de configuration distincts : config/paper-global.yml (paramètres du serveur dédié) et config/paper-world-defaults.yml (paramètres par monde). L'ancien paper.yml n'existe plus depuis cette version. Dans config/paper-world-defaults.yml :
chunks:
max-auto-save-chunks-per-tick: 8
delay-chunk-unloads-by: 10s
prevent-moving-into-unloaded-chunks: true
collisions:
max-entity-collisions: 2
entities:
spawning:
per-player-mob-spawns: true
despawn-ranges:
monster:
soft:
horizontal: 28
vertical: 28
hard:
horizontal: 96
vertical: 96
hopper:
disable-move-event: true
ignore-occluding-blocks: true
environment:
optimize-explosions: true
misc:
redstone-implementation: ALTERNATE_CURRENTmax-auto-save-chunks-per-tick: 8 etale les backups automatiques sur plusieurs ticks, éliminant les pics de latence toutes les cinq minutes. max-entity-collisions: 2 évite que les fermes d'élevage saturent le processeur. redstone-implementation: ALTERNATE_CURRENT remplace le moteur redstone vanilla par un moteur optimisé aux comportements identiques. disable-move-event: true sur les hoppers supprime un nombre considérable d'événements par tick.
Limites de mobs dans bukkit.yml
Le fichier bukkit.yml contrôle le nombre maximum de mobs vivants par joueur et la fréquence des tentatives de spawn sur votre serveur virtuel privé :
spawn-limits:
monsters: 50
animals: 8
water-animals: 3
water-ambient: 10
ambient: 1
ticks-per:
monster-spawns: 2
animal-spawns: 400
autosave: 6000Passer monsters de 70 à 50 réduit significativement le travail de pathfinding. Avec monster-spawns: 2, une tentative de spawn sur deux est sautée. autosave: 6000 repousse la sauvegarde mondiale à toutes les cinq minutes. Pour diagnostiquer une surcharge persistante, consultez notre guide sur le diagnostic de surcharge CPU sur un serveur de jeu Linux.
Drapeaux JVM : éviter les pauses du garbage collector
Les pauses de garbage collection Java peuvent bloquer le thread principal pendant 50 à 200 ms. Les drapeaux Aikar, référence dans la communauté Paper, sont conçus pour G1GC avec des pauses courtes et prévisibles. Sur votre serveur VPS Ubuntu ou Debian, éditez les scripts de démarrage de votre service Minecraft :
java -Xms6G -Xmx6G \
-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 paper.jar --noguiRègle impérative : -Xms et -Xmx doivent être identiques. Pour 10 à 20 joueurs, 6 Go de RAM est une valeur raisonnable. Au-delà de 12 Go, les pauses GC s'allongent. Pour démarrer automatiquement le serveur au boot et gérer les redémarrages sur crash, utilisez un service systemd : consultez notre guide sur la création d'un service systemd pour serveur de jeu Linux.
Prégénérer les chunks pour supprimer les pics d'exploration
La génération de nouveaux chunks est l'opération la plus coûteuse du serveur. Chaque joueur qui explore une zone non chargée provoque un pic de MSPT visible par tous. La solution est de prégénérer le monde avant d'ouvrir le serveur, avec le plugin Chunky (compatible Paper et Spigot) :
/chunky radius 5000
/chunky startCe processus génère tous les chunks dans un rayon de 5 000 blocs autour du spawn. Sur un serveur VPS à 4 vCPU, comptez quelques heures selon la complexité du monde. Combinez cette prégénération avec une limite de monde (worldborder) pour empêcher les joueurs d'explorer indéfiniment. Si votre serveur virtuel manque d'espace de stockage pendant la prégénération, notre guide sur la surveillance de l'espace disque Linux vous aidera à anticiper la saturation.
Migrer vers Paper : l'optimisation la plus impactante
Si votre serveur tourne encore sur le jar vanilla officiel ou sur Spigot, passer à Paper est l'optimisation la plus impactante que vous puissiez faire. Paper intègre le chargement de chunks asynchrone, les ranges d'activation d'entités, un moteur redstone amélioré et des centaines de correctifs de performance absents de Spigot. La migration est simple : téléchargez le jar Paper depuis le site officiel PaperMC, remplacez le jar existant, copiez votre dossier world/ et relancez. Vos plugins Spigot sont compatibles.
Pour les serveurs avec haute disponibilité et plus de 50 joueurs simultanés, le fork Folia répartit le traitement des chunks sur plusieurs threads. La compatibilité plugin est plus limitée. Assurez-vous que votre firewall autorise bien le port 25565 (UDP et TCP) sur l'adresse IP de votre serveur VPS cloud, et surveillez les ressources en temps réel avec notre guide sur htop et btop sur VPS Linux.
Support technique et choix d'hébergement pour un serveur Minecraft
Les optimisations présentées dans ce guide s'appliquent à tout serveur Minecraft Paper hébergé sur un VPS Linux ou un serveur dédié. Si vous rencontrez des performances anormales après avoir appliqué ces réglages, la cause peut être matérielle : un CPU à faible fréquence d'horloge, un hébergement avec stockage HDD ou un réseau saturé. Le support technique de votre hébergeur peut vous aider à identifier si la limite vient de l'infrastructure ou de la configuration logicielle.
Pour choisir l'offre VPS la plus adaptée à votre usage Minecraft, ElypseCloud propose des offres d'hébergement Minecraft sur serveurs VPS cloud SSD NVMe avec CPU haute fréquence, support technique réactif et bande passante dédiée.
Checklist d'optimisation Minecraft
- Vérifiez que la RAM de votre offre VPS correspond à votre nombre de joueurs
- Installez Spark et activez le monitoring des ticks avant tout changement
- Réduisez
view-distanceà 8 etsimulation-distanceà 6 dansserver.properties - Passez les drapeaux JVM Aikar sur les scripts de démarrage avec
-Xms=-Xmx - Ajustez les limites de mobs et la fréquence de spawn dans
bukkit.yml - Configurez les activation ranges et les hoppers dans
spigot.yml - Activez
ALTERNATE_CURRENTet réduisezmax-entity-collisionsdansconfig/paper-world-defaults.yml - Prégénérez les chunks avec Chunky avant d'ouvrir le serveur
- Migrez vers Paper si vous utilisez encore Vanilla ou Spigot
- Configurez un backup automatique régulier pour sécuriser la progression
Un serveur Minecraft bien configuré sur un VPS avec SSD NVMe peut accueillir 20 à 30 joueurs en maintenant un MSPT inférieur à 35 ms. Si vos ressources actuelles sont saturées malgré ces optimisations, découvrez comment héberger un serveur Minecraft avec les bonnes ressources depuis le départ.
Votre serveur Minecraft mérite un hébergement performant. ElypseCloud propose des serveurs VPS SSD NVMe avec CPU haute fréquence, conçus pour maintenir 20 TPS sous charge.
Voir les offres Minecraft