Comment résoudre le lag du serveur avec le profileur Spark ?

Votre serveur semble ramer : les blocs réapparaissent après que vous les avez cassés, les mobs se figent, les commandes répondent en retard et la console affiche Can't keep up! Is the server overloaded?. Inutile de deviner quelle ferme ou quel plugin est en cause — le profileur gratuit Spark mesure précisément où chaque tick perd son temps. Dans ce guide, vous installez Spark, capturez un profil pendant le lag et transformez le rapport en correctif concret.

D'abord, comprendre : TPS, MSPT et « Can't keep up »

Un serveur Minecraft tourne à 20 ticks par seconde (TPS). À chaque tick, le serveur met à jour le monde entier et dispose pour cela de 50 millisecondes au maximum. Le MSPT (milliseconds per tick) indique la durée réelle d'un tick. Tant que le MSPT reste sous les 50, vous tenez sans peine les 20 TPS ; dès qu'il les dépasse, le TPS chute et littéralement tout ralentit sur le serveur.

Le message Can't keep up! Is the server overloaded? Running 2000ms or 40 ticks behind signifie exactement cela : les ticks ont duré trop longtemps, le serveur a pris du retard et saute des ticks pour le rattraper. Une seule fois au démarrage, c'est anodin ; si le message revient pendant que l'on joue, vous avez un vrai lag serveur.

Vérifiez d'abord que le problème vient bien du serveur. Des FPS bas ou une image qui saccade (surtout avec des shaders), c'est du lag client ; du rubber-banding avec un ping élevé, c'est du lag de connexion. Tapez /spark tps : si vous voyez 20 TPS stables avec un MSPT bas, cherchez plutôt côté client ou réseau.

Étape 1 : installer Spark

1. Vous tournez sous Paper ou Purpur 1.21 ou plus récent ? Spark est déjà intégré. Tapez spark tps dans l'onglet Console du panel MC-Node ; si vous obtenez une réponse, passez directement à l'étape 2.
2. Sinon, téléchargez Spark sur spark.lucko.me/download. Choisissez la version Bukkit pour Paper/Spigot, ou la version Fabric/Forge/NeoForge pour un serveur moddé.
3. Ouvrez l'onglet Files du panel et téléversez le jar dans le dossier plugins (sur un serveur moddé : mods).
4. Redémarrez le serveur depuis l'onglet Console et vérifiez avec spark tps que la commande fonctionne.

Étape 2 : profiler pendant le lag

Le piège le plus courant : profiler un serveur vide ou tout juste redémarré. Sans joueurs, les fermes, hoppers et chunks responsables du lag ne tournent pas, et le rapport ne montre donc rien. Lancez le profileur au moment où le lag se produit réellement, avec des joueurs en ligne.

1. Attendez que le lag apparaisse, ou demandez aux joueurs de reproduire la situation (par exemple près de la ferme suspecte).
2. Tapez dans la console : spark profiler start --timeout 300. Le profileur mesure pendant 5 minutes puis s'arrête tout seul. Sans --timeout, arrêtez-le vous-même avec spark profiler stop.
3. Laissez tout le monde jouer normalement ; la mesure elle-même ne coûte quasiment aucune performance.
4. À la fin, la console affiche un lien vers spark.lucko.me. Ouvrez-le dans votre navigateur.

Étape 3 : lire le rapport

1. En haut, vous voyez le TPS et le MSPT pendant la mesure — de quoi confirmer que vous avez bien capturé le lag.
2. Ouvrez l'arborescence sous le thread serveur et dépliez à chaque fois la ligne au pourcentage le plus élevé. Vous descendez ainsi jusqu'à la tâche qui dévore le plus de temps de tick.
3. Reconnaissez les schémas : beaucoup de temps dans entityTick ou l'IA des mobs indique trop d'entités ; HopperBlockEntity pointe vers des lignes de hoppers ; chunk generation ou ServerChunkCache vers le chargement de chunks ; et un nom de package comme com.exemple.nomduplugin désigne ce plugin précis comme coupable.

Causes fréquentes et leurs correctifs

• Trop d'entités — Le plus souvent des fermes à mobs ou des objets qui traînent au sol. Réglez /gamerule maxEntityCramming 8 (24 par défaut), baissez les spawn-limits dans bukkit.yml et l'entity-activation-range dans spigot.yml, et équipez les grandes fermes d'un interrupteur marche/arrêt.
• Hoppers — Les longues lignes de hoppers vérifient leur contenu à chaque tick. Augmentez dans bukkit.yml la valeur ticks-per.hopper-transfer (par exemple de 8 à 16) et, sur Paper, passez l'option hopper.cooldown-when-full à true dans config/paper-world-defaults.yml. Remplacez les lignes très longues par des courants d'eau avec moins de hoppers.
• Chargement de chunks et worldgen — Les joueurs qui explorent forcent le serveur à générer de nouveaux chunks. Baissez la simulation-distance dans server.properties (par exemple à 6) et éventuellement la view-distance, définissez une bordure de monde et pré-générez le monde avec le plugin Chunky : /chunky radius 3000 suivi de /chunky start.
• Un plugin en tête du rapport — Mettez d'abord le plugin à jour, désactivez les fonctions lourdes (scans, animations, hologrammes) dans sa config ou cherchez une alternative plus légère. Pour tester, déplacez temporairement le jar hors de plugins et redémarrez.
• « Can't keep up » uniquement au démarrage — Anodin : le serveur rattrape le pic de démarrage. N'agissez que si le message revient en cours de jeu.
• Le TPS est à 20 mais les joueurs se plaignent quand même — C'est alors du lag client ou réseau : réduisez la distance de rendu ou désactivez les shaders côté client, ou examinez le ping.

Optimiser davantage

Vous utilisiez /timings autrefois ? Notre article sur la création de timings est dépassé ; Spark en est le successeur moderne. Vous trouverez des améliorations structurelles dans notre guide d'optimisation, et pour savoir si un manque de mémoire entre en jeu, consultez le guide RAM. Vous bloquez ? Ouvrez un ticket via notre page de support en joignant le lien de votre rapport Spark — nous y jetterons un œil avec vous.