Serveur Minecraft qui lag : corriger correctement « Can't keep up » et le timeout Watchdog

Les trois messages de lag les plus fréquents dans les logs Minecraft ne veulent pas dire la même chose : Can't keep up! Is the server overloaded? signifie que ton serveur continue de tourner, mais n’arrive plus à suivre. A single server tick took 60.00 seconds signifie que le frein d’urgence intégré l’a arrêté brutalement. Exception in server tick loop signifie qu’une erreur de programme précise a fait exploser la boucle de jeu. Si tu traites les trois de la même façon, tu répares souvent le mauvais problème.

Distinguer les trois messages

Minecraft calcule le monde de jeu 20 fois par seconde. Un tel passage s’appelle un tick et doit durer au maximum 50 millisecondes. Tout lag que tu ressens est un écart par rapport à ce seul chiffre.

La dernière ligne prête régulièrement à confusion : Paper signale chaque requête externe comme un avertissement. C’est notre mesure de performance planifiée toutes les cinq minutes environ, pas une erreur ni une intervention dans ton jeu.

Le geste le plus important : lire plus haut en cas de message Watchdog

Le kill Watchdog est un symptôme, pas une cause. Il dit seulement : quelque chose a bloqué le thread du serveur plus longtemps que permis. Ce qui l’a bloqué se trouve ailleurs.

Il y a deux cas, et ils mènent à des actions complètement différentes :

Cas 1 — le Watchdog est arrivé en premier. Avant la ligne Watchdog, le serveur était en fonctionnement normal. Dans ce cas, le temps de tick est bien l’information importante : quelque chose a figé le serveur pendant qu’il tournait.

Cas 2 — le Watchdog est arrivé après. Avant la ligne Watchdog, on voit déjà Stopping server ou Preparing crash report. Dans ce cas, le serveur était déjà mort ou en train de s’arrêter, et le Watchdog a seulement nettoyé un arrêt bloqué.

Ce deuxième cas n’est pas rare. Dans un cas de support du 22 août 2026, le thread serveur a crashé à 13:20:15, a commencé un Stopping server propre — puis le Watchdog ne s’est déclenché que 60 secondes plus tard. Si tu déclares alors que la durée du tick est la cause, tu passes à côté du vrai message d’erreur, qui se trouvait une minute plus haut. C’est précisément pour cela que notre analyse de console évalue volontairement le hit Watchdog en dernier : si une signature plus précise se trouve dans le même extrait de log, c’est cette explication que tu vois, et non « un tick était lent ».

Trouver la cause étape par étape

1. Vérifier l’historique TPS dans le panel

Ouvre ton serveur dans le panel. Sous « Performance (dernières 24 h) », tu vois l’évolution TPS ; elle est mesurée environ toutes les cinq minutes tant que le serveur tourne. La forme de la courbe en dit déjà beaucoup :

• Une chute nette à une heure précise → un événement. Compare l’heure avec le log : génération de monde, sauvegarde, joueur en terrain inexploré, tâche de plugin.
• Des valeurs durablement basses → surcharge structurelle. Ici, un redémarrage ne suffit pas ; il faut alléger la charge.
• Un motif en dents de scie → typique d’une pression mémoire : le serveur travaille, le garbage collection interrompt, puis ça recommence.

Si les valeurs restent basses sur une période prolongée, le panel t’avertit automatiquement avec l’indication « TPS durablement bas ».

2. Mesurer le MSPT — le TPS seul ne suffit pas

Entre /spark tps dans la console. La commande fournit deux chiffres, et le second est le plus important :

• TPS — ticks par seconde, maximum 20.
• MSPT — millisecondes par tick. Jusqu’à 50 ms, tout va bien.

Pourquoi le MSPT ? Bukkit, Spigot et Paper ralentissent les processus serveur pour éviter un crash. L’affichage peut donc montrer un beau 20 TPS, alors qu’en réalité le serveur travaille déjà à sa limite. Une valeur MSPT de 45 ms signifie : il suffit d’une ferme à mobs de plus pour voir du lag — même si l’affichage TPS paraît encore parfait.

Sur Paper à partir de la version 1.21, spark est déjà inclus, tu n’as rien à installer.

3. Profiler le responsable

Ne devine pas quel plugin est fautif — mesure-le :

/spark profiler start --timeout 120

Pendant ces deux minutes, rejoue la situation qui lag. Ensuite, ouvre le lien de résultat fourni par le serveur. Le rapport montre, trié par part de temps, où part le temps de tick : une mod précise, une tâche de plugin, le chargement de chunks, le traitement des entités ou le garbage collection.

C’est ici que ce guide se sépare du réflexe « acheter plus de RAM ». Le profiler répond à la question qu’un tableau de recommandations ne peut pas résoudre : qu’est-ce qui consomme exactement du temps sur ton serveur ?

4. Alléger de façon ciblée

Ce que montre le profiler détermine l’action :

Le dernier point est important : la RAM ne corrige qu’un problème de mémoire. Si une horloge Redstone dévore le temps de tick, un forfait plus gros ne rendra pas le serveur plus rapide. Notre calculateur de RAM Minecraft t’indique combien de mémoire convient à ton nombre de joueurs et à la taille de ton modpack.

5. max-tick-time — l’exception, pas la solution

La valeur se trouve dans server.properties et définit à partir de quelle durée de tick le Watchdog intervient. La valeur standard est de 60000 millisecondes, soit 60 secondes. Si cette valeur est dépassée, le serveur s’arrête lui-même.

Beaucoup de guides en ligne recommandent ici de désactiver le Watchdog avec -1. Ne fais pas de ça ta solution standard. Le Watchdog est le seul mécanisme intégré qui remarque vraiment un deadlock réel. Avec -1, un serveur mort reste accroché au port pendant des heures : les joueurs ne peuvent pas se connecter, rien dans le log n’explique pourquoi, et personne n’est alerté. Tu as supprimé l’indicateur, pas le problème.

Il n’existe qu’une bonne raison d’augmenter cette valeur : une opération connue dure légitimement longtemps. Le cas classique est le premier démarrage d’un gros modpack, où la génération du monde et l’initialisation des mods passent ensemble plus d’une minute dans un tick. Dans ce cas, une valeur comme 180000 (trois minutes) peut se défendre — temporairement, avec l’intention de la remettre à la normale après le premier démarrage réussi.

Si Exception in server tick loop apparaît dans le log

Ce message est le plus simple des trois, parce qu’il fournit sa cause. Juste en dessous, ou quelques lignes plus loin, se trouve une ligne Caused by: — c’est là que se trouve la vraie erreur, le plus souvent avec le nom de la mod ou du plugin responsable.

Procédure :

1. Chercher Caused by: et noter le nom de classe.
2. S’il contient le nom d’une mod ou d’un plugin, le responsable est identifié.
3. Si l’erreur est apparue après une modification (nouvelle mod, mise à jour, nouveau monde), annule d’abord cette modification.
4. Si l’erreur reste floue, envoie toute la section au support — avec l’heure.

L’analyse de console de ton serveur détecte automatiquement ces lignes et explique chaque message reconnu en clair, avec sa fréquence. Si tu n’as qu’un extrait de log venu d’ailleurs, tu peux le coller dans notre analyseur de rapports de crash Minecraft — même sans serveur chez nous.

Ce que nous prenons automatiquement en charge pour toi

• Mesure de performance sans action de ta part. Le TPS est relevé toutes les cinq minutes environ et affiché pendant 24 heures dans le panel — aucun plugin à installer.
• Alerte en cas de faiblesse prolongée. Si les performances restent basses sur une fenêtre fiable, tu es averti au lieu de devoir le remarquer toi-même.
• Lignes de log expliquées. Les messages reconnus reçoivent une cause et une solution en clair, dans ta langue — et lorsqu’un guide adapté existe, un lien vers celui-ci.
• Règle symptôme avant cause. Si un message d’erreur plus parlant que le kill Watchdog se trouve dans le même extrait de log, c’est celui-là que nous t’affichons.

Dépannage : symptôme, vérification, solution

FAQ

À partir de quelle valeur TPS les joueurs remarquent quelque chose ?

Jusqu’à environ 18 TPS, rien ne se voit en jeu. Sous 15, ça devient clairement lourd. Mais ne te fie pas uniquement à ça : vérifie aussi le MSPT, car le limiteur TPS peut afficher une valeur saine alors que le serveur travaille déjà à sa limite.

Est-ce que plus de RAM aide contre le lag ?

Seulement si la mémoire est réellement le goulot d’étranglement. Si le profiler montre le garbage collection comme poste principal, oui. S’il montre une horloge Redstone ou une ferme à mobs, plus de RAM ne change rien. Mesure d’abord, achète ensuite.

Dois-je désactiver le Watchdog ?

Non, pas durablement. -1 te retire la seule détection automatique d’un vrai gel. Une augmentation temporaire de max-tick-time pour une opération connue et lente, comme le premier démarrage d’un modpack, peut se défendre — puis il faut remettre la valeur normale.

Pourquoi le message Watchdog apparaît-il après « Stopping server » ?

Parce que le serveur était déjà en train de s’arrêter et est resté bloqué à ce moment-là. Le Watchdog a alors nettoyé un arrêt suspendu, il n’a pas abattu un serveur en fonctionnement. La cause se trouve avant le Stopping server.

Un redémarrage aide-t-il ?

Contre un retard aigu, oui ; contre la cause, non. Si le lag revient peu après chaque redémarrage, il est structurel — dans ce cas, seule la mesure permet d’avancer.

Quelle est la différence entre view-distance et simulation-distance ?

view-distance détermine jusqu’où les joueurs voient ; simulation-distance détermine jusqu’où le monde est réellement calculé. Les deux valent 10 chunks par défaut. Comme seuls les chunks simulés coûtent du temps de calcul, baisser simulation-distance apporte plus de soulagement avec moins de perte visible.

Si ça lag encore

Avant une demande au support, rassemble trois choses : l’heure exacte du dernier incident, le lien de ton rapport de profiler spark et les mods ou plugins ajoutés récemment. Avec ça, on peut vérifier précisément la bonne section du log, au lieu de lancer une optimisation générale.

Les réglages généraux valables pour tous les jeux — plans de redémarrage, choix du forfait, réseau — se trouvent dans le guide améliorer les performances d’un serveur de jeu. Pour installer et retirer proprement des mods et plugins, consulte installer des mods et plugins Minecraft.

Tu veux un serveur avec mesure TPS, explication des logs et alertes sans travail supplémentaire ? Sur louer un serveur Minecraft, tu trouveras les forfaits adaptés.

Sources et banc de test

• max-tick-time, taux de tick et distances : PaperMC — server.properties. Documente la valeur standard de 60000 millisecondes, l’arrêt forcé en cas de dépassement, la désactivation avec -1 ainsi que les valeurs standard 10 pour view-distance et simulation-distance.
• spark est inclus dans Paper : PaperMC — Profiling. À partir de Paper 1.21, aucun téléchargement séparé n’est nécessaire.
• MSPT avant TPS : spark — TPS and MSPT. Explique pourquoi le limiteur TPS peut afficher un 20 stable alors que le serveur tourne réellement plus lentement.
• Commandes du profiler : spark — Command Usage. Source pour /spark profiler start --timeout <sekunden> et /spark profiler stop.

Banc de test : 24 août 2026. Les valeurs par défaut et les commandes peuvent changer avec les nouvelles versions serveur ; en cas de doute, vérifie la documentation du fabricant liée ci-dessus.