Serveur Minecraft qui lag : solutions pour améliorer les performances

Les lags proviennent de trois familles principales : calcul serveur (CPU / entités / redstone), mémoire (RAM / pauses GC) et entrées-sorties (disque / réseau). Viser des TPS à ~20 et un MSPT < 50ms (idéalement < 25ms) est l’objectif. Ce guide propose une méthode reproductible pour diagnostiquer et corriger les problèmes, des réglages concrets côté Paper/Spigot/Bukkit, des recommandations JVM, et des conseils matériel (CPU/RAM/stockage/réseau) adaptés aux gros serveurs.

1) Comprendre le lag

• Lag serveur (tick lent) : TPS < 20, MSPT élevé. Causé par IA/entités, redstone, génération de chunks, plugins lourds, disques lents.
• Lag réseau : ping/packet‑loss. Sensible à la distance, au peering, aux attaques DDoS, à la saturation.
• Lag client : FPS bas, shaders, pack lourds. Non imputable au serveur.

Mesures clés : /tps (Vue globale), /mspt (Paper), /timings et Spark pour profiler finement.

2) Méthode de diagnostic reproductible

1. Baseline : passez sur Paper (au minimum) avec Java 17/21, désactivez les plugins non essentiels, laissez tourner 30min.
2. Timings : /timings on → laissez 10-15min avec joueurs → /timings paste et analysez les sections lourdes (entités, tâches).
3. Spark (recommandé) :

   /spark profiler --timeout 300
   /spark profiler stop
   /spark profiler view

   Inspectez les hotspots : tâches de plugins, pathfinding, hoppers, redstone.
4. Hypothèses → tests ciblés : réduisez simulation-distance, limitez entités, ajustez hoppers, pré‑générez les chunks… puis re-testez.

3) RAM : quantités, Xms/Xmx, GC

• Repères réalistes (hébergeurs/retours terrain)
  • 6–8 Go : Vanilla/Paper, 10–30 joueurs, <25 plugins.
  • 12–16 Go : 50–100 joueurs, 40–60 plugins, plusieurs mondes (cible classique 50+ joueurs/50 plugins).
  • 16–24 Go : 100+ joueurs, hubs, anti‑cheat, gros logs.
  • 24–32 Go et + : modpacks Forge/Fabric lourds.
• DDR5/Fréquence : privilégiez de la DDR5 5200–6000 MHz (ECC si dispo). La latence mémoire impacte les pauses GC.
• Ne pas sur‑allouer : laissez 2–4 Go à l’OS/panels/DB. Trop de RAM non profilée = pauses GC plus longues.
• Allocation Java : Xms = Xmx pour éviter les redimensionnements.

  java -Xms8G  -Xmx8G  -jar server.jar   # serveur moyen
  java -Xms16G -Xmx16G -jar server.jar   # gros serveur (50+ joueurs, 50 plugins)

• GC : G1GC (Java 17/21) par défaut, stable. ZGC (Java 21) possible >16Go si tests concluants. Évitez d’empiler des flags sans mesure.

-XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200
-XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC
-XX:InitiatingHeapOccupancyPercent=15 -XX:G1NewSizePercent=20 -XX:G1MaxNewSizePercent=60
-XX:G1HeapRegionSize=16M -XX:G1ReservePercent=20 -XX:G1MixedGCCountTarget=4
-XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1

4) CPU : prioriser le mono‑thread et le MSPT

• Fréquence > cœurs : le tick reste majoritairement mono‑thread. Favorisez des CPU à forte perf single‑core (ex. Ryzen 7 5800X3D, 7800X3D, 7950X/7950X3D ; Intel 13600K/13900K/14900K).
• Gouverneur : en dédié Linux, performance plutôt que ondemand. Évitez l’over‑commit CPU en VPS.
• Conteneurs/VM : attention à la latence de scheduling ; réservez des cœurs, limitez le “bruit” des voisins.
• Objectif : MSPT < 25ms en charge ; au‑delà de 50ms, vous ressentirez des saccades.

5) Disque & IO : NVMe, auto‑save, backups

• NVMe recommandé. Évitez HDD/SSD SATA bas de gamme. Les IO de chunks et sauvegardes sont coûteux.
• Auto‑save : évitez les sauvegardes au milieu des pics.

  /save-off     # avant une grosse opération (pré-génération, migration)
  save-all
  /save-on

• Backups : planifiez hors‑charge (ex. de nuit), incrémentaux, en excluant /logs massifs. Pensez à rclone, restic.

6) Réglages Paper/Spigot/Bukkit (exemples concrets)

Ces valeurs sont des points de départ. Ajustez selon votre gameplay et mesurez.

bukkit.yml

settings:
  allow-end: true
  warn-on-overload: false
  query-plugins: false
  chunk-gc:
    period-in-ticks: 600
ticks-per:
  animal-spawns: 400
  monster-spawns: 4
  autosave: 6000

spigot.yml

world-settings:
  default:
    merge-radius:
      exp: 3.0
      item: 2.5
    entity-activation-range:
      animals: 16
      monsters: 24
      raiders: 32
      misc: 8
    entity-tracking-range:
      players: 48
      animals: 48
      monsters: 48
      misc: 32
    tick-inactive-villagers: true
    nerf-spawner-mobs: true
    hopper-amount: 1
    hopper-transfer: 8
    hopper-check: 8
    view-distance: 8

paper-global.yml (ou paper.yml)

timings:
  enabled: true

chunk-loading:
  global-max-chunk-load-rate: 100.0
  player-max-chunk-load-rate: 20.0

unsupported-settings:
  allow-permanent-block-break-exploits: false

world-settings:
  default:
    despawn-ranges:
      soft: 28
      hard: 96
    per-player-mob-spawns: true
    optimize-explosions: true
    max-auto-save-chunks-per-tick: 8
    prevent-moving-into-unloaded-chunks: true
    fix-climbing-bypassing-cramming-rule: true
    armor-stands:
      tick: false
      do-collision-entity-lookups: false
    mobs:
      spawn-cap:
        monsters: 70
        animals: 10
      villager:
        brain-ticks: 2
    redstone-implementation: ALTERNATE_CURRENT

Points clés : per-player-mob-spawns stabilise les spawns, merge-radius réduit le coût des items/XP, hopper‑* limite le débit, despawn‑ranges contrôle la densité d’entités, optimize‑explosions et alternate redstone réduisent la charge.

7) Monde & chunks : pré‑génération, distances, spawn

• Pré‑générez vos mondes (Overworld, Nether, End) pour éviter la génération sous charge.

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

• Distances : démarrez à simulation-distance: 6–8, view-distance: 8, réduisez si nécessaire.
• Spawn : évitez keep‑spawn‑loaded si vous n’avez pas d’activité permanente au spawn ; limitez les chunk loaders.

8) Entités, hoppers, redstone : gros impacts

• Entités : limitez l’IA quand elles sont éloignées (activation-range), utilisez despawn‑ranges adaptés, évitez les fermes démesurées.
• Hoppers : gros consommateurs. Réduisez hopper-transfer/hopper-check, évitez les horloges de hoppers, préférez des trémies “passives”.
• Redstone : préférez Alternate Current (Paper), limitez les clocks très rapides, centralisez la logique au besoin.

9) Plugins : profiler, trier, remplacer

1. Profiling d’abord : Spark/timings pour identifier les hotspots.
2. À surveiller : pathfinding agressif, anti‑cheat très stricts, chunk loaders, outils réclamant des scans lourds.
3. Remplacements : évitez les doublons (plusieurs économies/chat), préférez des plugins maintenus et réputés.
4. Base de données : si MySQL/PG, utilisez un pool (HikariCP), local si possible (réseau local/Unix socket) ; évitez les requêtes sur le thread principal.

10) Réseau & proxy

• Proxy : pour un réseau multi‑serveurs, préférez Velocity (moderne) à BungeeCord ; activez le modern forwarding.
• Compression : évitez une compression trop forte (CPU) ; testez un seuil compression-threshold raisonnable (ex. 256/512).
• Anti‑DDoS/latence : hébergeur avec mitigation solide, datacenter proche de vos joueurs, bons peers.

11) Hébergement : CPU, RAM DDR5, anti‑DDoS

• CPU : haute fréquence/single‑core (ex. 5800X3D, 7800X3D, 7950X3D ; 13600K/13900K/14900K).
• RAM : DDR5 5200–6000 MHz (ECC si possible). Pour 50+ joueurs/50 plugins, visez ~16 Go dédiés à la JVM (en laissant 2–4 Go à l’OS).
• Stockage : NVMe, pas de HDD ; surveillez l’endurance si backups fréquents.
• Réseau : anti‑DDoS, faible latence vers votre cible (FR/UE), peering de qualité.

12) Checklist rapide (ordre conseillé)

1. Passer sur Paper (Java 17/21), config basique saine.
2. Mesurer : /tps, /mspt, /timings, Spark.
3. Ajuster distances (simulation 6–8, view 8), per-player-mob-spawns.
4. Configurer merge-radius, despawn-ranges, hopper-*, alternate redstone.
5. Pré‑générer les mondes avec Chunky.
6. RAM : Xms=Xmx (8–16 Go selon charge), G1GC par défaut ; re‑mesurer.
7. Plugins : profiler → retirer/remplacer les plus lourds.
8. IO : NVMe, backups hors‑pics, /save-off lors d’opérations coûteuses.
9. Matériel/hébergeur : CPU single‑core fort, DDR5 rapide, anti‑DDoS.
10. Documenter chaque changement et conserver une configuration versionnée.