Un serveur Minecraft calcule le monde en ticks, 20 fois par seconde. Si un tick dure trop longtemps ou si la mémoire vive est épuisée, le serveur écrit des avertissements dans le log ou, dans le pire des cas, s'arrête. Chaque section ci-dessous explique l'un de ces messages : comment le reconnaître, sa gravité et ce que tu peux faire. Les messages après lesquels le serveur plante ou se ferme viennent en premier, puis les avertissements pour lesquels il continue de tourner.

Tu trouveras le message complet dans la Console ou sous Fichiers dans logs/latest.log, et les rapports de crash dans le dossier crash-reports/. Lis toujours aussi les lignes qui précèdent : on y trouve souvent ce qui a ralenti le serveur. Avant de modifier des fichiers de configuration ou de monde, crée une sauvegarde sous Sauvegardes.

« A single server tick took … seconds » : le watchdog arrête le serveur

Voici à quoi ressemble le message :

The server has not responded for <Seconds> seconds! Creating thread dump
A single server tick took 60.00 seconds (should be max 0.05)

Ce qui se cache derrière : le watchdog vérifie que le serveur travaille encore. Si un tick, c'est-à-dire une étape de calcul de la simulation du jeu, dure trop longtemps, il arrête le serveur figé ; le jeu est alors interrompu. Auparavant, Paper écrit des messages intermédiaires avec un thread dump, un instantané du travail en cours : si le serveur se rétablit à temps, il continue de tourner. Les causes fréquentes sont une pression sur la mémoire ou un plugin ou un mod trop lourd.

Voici comment le résoudre :

  1. Dans Fichiers, lis dans logs/latest.log les lignes précédant le premier message du watchdog. Vérifie les erreurs antérieures ; si tu y vois Stopping server, examine aussi ce qui bloque l'arrêt.
  2. Dans le thread dump, regarde les premières lignes sous Server thread. Le nom d'un plugin ou d'un mod indique ce qui occupait le serveur en dernier.
  3. Vérifie la mémoire vive. OutOfMemoryError: Java heap space signifie que la mémoire Java est épuisée ; vérifie alors aussi ce qui l'occupe.
  4. Arrête le serveur avant de modifier des fichiers. Mets à jour le plugin concerné sous Plugins ou le mod sous Mods, ou supprime-le pour tester, redémarre et vérifie à nouveau.

En détail : Corriger correctement « Can't keep up » et le timeout du watchdog

« Java heap space » : la mémoire du serveur est épuisée

Voici à quoi ressemble le message :

An unexpected error while handling a WorldEdit command … java.lang.OutOfMemoryError: Java heap space
[LuckPerms] Thread <Thread> threw an uncaught exception … java.lang.OutOfMemoryError: Java heap space
failed to handle chunk data (write) … java.lang.OutOfMemoryError: Java heap space

Ce qui se cache derrière : Java gère la mémoire du serveur dans une zone appelée heap, qui est saturée par la charge actuelle. De grosses actions WorldEdit, de nombreux chunks chargés (c'est-à-dire des sections du monde), de gros modpacks ou des plugins manipulant beaucoup de données peuvent nécessiter beaucoup de mémoire. Le serveur plante souvent ou devient instable ; l'enregistrement des données du monde ou des entités, comme les créatures et les objets, peut aussi échouer. Le thread ou le plugin indiqué montre où la mémoire a manqué, pas forcément le plus gros consommateur de mémoire.

Voici comment le résoudre :

  1. Redémarre le serveur pour terminer le processus saturé. Si la charge reste identique, l'erreur peut revenir.
  2. Détermine les besoins en mémoire : Planifier les besoins en RAM de Minecraft. Si ton offre ne suffit pas, choisis plus de RAM sous Paramètres et abonnement → Plan.
  3. Fractionne les grosses actions WorldEdit et, si nécessaire, réduis view-distance dans server.properties sous Fichiers.
  4. Après le redémarrage, vérifie la Console et les zones du monde concernées. En cas de messages concernant chunk data (write), contrôle tout particulièrement si le dernier état a bien été enregistré.

Bon à savoir : Une sauvegarde avant la prochaine grosse modification du monde aide à restaurer les changements perdus.

« This crash report has been saved to … » : le serveur a planté

Voici à quoi ressemble le message :

This crash report has been saved to: crash-reports/crash-<Date>_<Time of day>-server.txt

Ce qui se cache derrière : le serveur a été arrêté par une erreur grave et a écrit un rapport de plantage. Le message indique uniquement où se trouve ce rapport. La véritable cause, par exemple un mod, un plugin, le monde ou un manque de mémoire vive, figure dans le fichier.

Comment résoudre le problème :

  1. Dans Fichiers, ouvre le dossier crash-reports/, puis le fichier indiqué. Son nom contient la date et l'heure du plantage.
  2. Lis la première section : après Description: se trouve une courte description, suivie de la ligne d'erreur et de la stacktrace, c'est-à-dire la liste des endroits du programme qui ont conduit à l'erreur.
  3. Vérifie que les mods ou plugins mentionnés dans l'erreur sont dans des versions compatibles. Mets à jour celui concerné sous Mods ou Plugins, ou retire-le à titre d'essai après avoir fait une sauvegarde.
  4. En cas d'OutOfMemoryError, lis le complément du message. S'il indique Java heap space, la mémoire Java est saturée ; si la RAM réservée est insuffisante, choisis plus de RAM sous Paramètres et abonnement → Plan.
  5. Démarre le serveur et surveille la Console jusqu'à ce qu'il soit complètement lancé.

Bon à savoir : conserve le rapport pour le dépannage et compare la date et l'heure avec le plantage actuel. Pour les serveurs avec mods : Erreurs de mods sur les serveurs Forge, NeoForge et Fabric

Erreur dans la boucle principale du jeu

Voici à quoi ressemble le message :

Exception in server tick loop
Caused by: java.lang.<ErrorType>: <Details>

Ce qui se passe : la boucle principale calcule le monde tick après tick. Une exception, c'est-à-dire une erreur de programme, a remonté jusque dans cette boucle et l'a perturbée. Le serveur plante alors le plus souvent et écrit un rapport de plantage. La véritable cause se trouve presque toujours dans la ligne Caused by qui suit directement.

Voici comment le corriger :

  1. Cherche le message dans logs/latest.log ou dans le rapport le plus récent sous crash-reports/.
  2. Lis la ligne Caused by juste en dessous. S'il y en a plusieurs, la dernière mène généralement à la racine du problème.
  3. Les lignes avec at … en dessous indiquent des noms de paquets et de fichiers. Tu y reconnais le plugin ou le mod concerné.
  4. Mets-le à jour ou supprime-le dans Plugins ou Mods, puis redémarre le serveur.

Bon à savoir : ce message n'est pas un problème de lag, mais une erreur concrète. Plus de mémoire vive n'aide que si la ligne Caused by mentionne un OutOfMemoryError.

Pour en savoir plus : Résoudre correctement « Can't keep up » et le timeout du Watchdog

Mémoire vive à la limite : GC overhead limit exceeded

Voici à quoi ressemble le message :

java.lang.OutOfMemoryError: GC overhead limit exceeded

Ce qui se passe : Java libère automatiquement la mémoire dont il n'a plus besoin. C'est ce qu'on appelle le Garbage Collection, ou GC. Ce message signifie que Java passe presque tout son temps à nettoyer et ne récupère presque plus de mémoire. Le heap, c'est-à-dire la mémoire vive de Java, est pratiquement plein. Le serveur ne réagit presque plus ou plante.

Voici comment le corriger :

  1. Redémarre le serveur.
  2. Détermine combien de mémoire vive ta configuration nécessite. Pour en savoir plus : Planifier les besoins en RAM de Minecraft
  3. Si ton offre ne suffit pas, choisis plus de RAM sous Paramètres et abonnement → Plan.
  4. Réduis la charge des chunks et des entités : diminue la distance de vue view-distance dans le fichier server.properties, réduis les grandes fermes d'animaux et nettoie les items qui traînent.

Bon à savoir : un redémarrage ne fait que souffler un peu. Si la consommation augmente régulièrement jusqu'à la limite après chaque redémarrage alors que la charge reste la même, un plugin ou un mod peut aussi retenir de la mémoire.

Impossible de créer un nouveau thread : unable to create native thread

Voici à quoi ressemble le message :

java.lang.OutOfMemoryError: unable to create native thread

Ce qui se passe : un thread est un fil de travail parallèle. Java a voulu en démarrer un de plus et n'y est pas parvenu. Malgré OutOfMemoryError dans le nom, ce n'est pas la preuve d'un heap Java plein. Le plus souvent, trop de threads tournent en même temps, une limite de processus est atteinte ou il manque de la mémoire en dehors du heap. Le serveur ne peut alors plus lancer de nouvelles tâches et devient instable. Cette ligne ne révèle pas quel plugin ou quel mod crée les threads.

Voici comment le corriger :

  1. Ne réserve pas systématiquement plus de RAM. Davantage de mémoire vive pour Java ne résout pas automatiquement ce message.
  2. Dans logs/latest.log, lis les lignes avant le message : qu'est-ce qui tournait au moment de l'erreur, quels plugins se sont manifestés de façon répétée ?
  3. Identifie le responsable en cours d'exécution. Avec spark profiler start --thread * dans la Console, tu vois tous les threads en cours. Leurs noms révèlent souvent le plugin ou le mod.
  4. Ce n'est qu'une fois le responsable identifié que tu le mets à jour dans Plugins ou Mods, vérifies ses paramètres ou le supprimes.

Si tu n'avances pas, ouvre un ticket et indique l'heure du message. À propos de spark : spark : trouver et comprendre le lag

« Can't keep up » : le serveur n'arrive pas à suivre ses ticks

Voici à quoi ressemble le message :

Can't keep up! Is the server overloaded? Running 2014ms or 40 ticks behind

Ce qui se cache derrière : Minecraft calcule normalement 20 ticks par seconde, soit un budget de temps de 50 millisecondes par tick. Si ces étapes durent trop longtemps, un retard s'accumule, que le message indique en millisecondes et en ticks. Le serveur continue de tourner, mais nettement plus lentement : les blocs minés réapparaissent, les mobs saccadent. La cause est le plus souvent une pression sur la mémoire ou le CPU ; quelques messages isolés peuvent apparaître au démarrage ou lors de la génération de nouvelles zones.

Voici comment le résoudre :

  1. Vérifie si spark est disponible. Les versions récentes de Paper l'incluent ; sur les autres serveurs pris en charge, installe la version adaptée en plugin ou en mod.
  2. Pendant le lag, mesure avec spark tps dans la Console. Le MSPT correspond aux millisecondes par tick : si la durée d'un tick dépasse durablement le budget de temps, le taux de ticks diminue.
  3. Trouve le responsable avec spark profiler start --timeout 120 et ouvre le lien affiché ensuite.
  4. Serveur arrêté, réduis la distance d'affichage view-distance et la distance de simulation simulation-distance dans server.properties. Allège les grandes fermes ou pré-génère le monde.
  5. Vérifie que la mémoire vive suffit et redémarre après les modifications de configuration.

En détail : Corriger correctement « Can't keep up » et le timeout du watchdog

« DO NOT REPORT THIS TO PAPER » : diagnostic en cas de blocage du serveur

Voici à quoi ressemble le message :

--- DO NOT REPORT THIS TO PAPER - THIS IS NOT A BUG OR A CRASH ---
Server thread dump (Look for plugins here before reporting to Paper!):

Ce qui se cache derrière : si le thread du serveur reste bloqué pendant quelques secondes, Paper écrit un diagnostic avec un thread dump, c'est-à-dire un instantané de ce sur quoi le serveur travaille. Le jeu se fige pendant ce temps ; après le blocage, le serveur peut continuer de tourner. Si le blocage dure trop longtemps, le watchdog l'arrête.

Voici comment le résoudre :

  1. Dans le dump, lis les premières lignes sous Server thread dump. Si le nom d'un plugin ou d'un mod y apparaît, c'est un indice fort du responsable.
  2. Arrête le serveur, mets à jour le plugin concerné sous Plugins ou le mod sous Mods, ou supprime-le pour tester, puis redémarre.
  3. Si les dumps se multiplient, vérifie la mémoire vive, tes plugins et la distance d'affichage view-distance dans le fichier server.properties.
  4. Pour des dumps isolés, par exemple au démarrage ou lors de la sauvegarde d'un grand monde, tu peux simplement observer au lieu d'intervenir immédiatement.

En détail : Corriger correctement « Can't keep up » et le timeout du watchdog

« ChunkTaskScheduler » : Paper attend le chargement ou la génération d'un chunk

Voici à quoi ressemble le message :

[ChunkTaskScheduler] Chunk wait task info below:
[ChunkTaskScheduler] Chunk holder: NewChunkHolder{world=<Monde>, chunkX=<x>, chunkZ=<z>, …, currentGenStatus=minecraft:initialize_light, requestedGenStatus=minecraft:full, …}

Ce qui se cache derrière : Paper a attendu plus longtemps que prévu le chargement ou la génération d'un chunk, c'est-à-dire d'une section de monde de 16 × 16 blocs, et a écrit un diagnostic. Le serveur rame à ce moment-là. currentGenStatus indique l'étape atteinte, requestedGenStatus l'objectif. Il s'agit le plus souvent d'une surcharge : génération du monde, beaucoup de joueurs éloignés les uns des autres ou plugins lents. Plus rarement, une région est endommagée.

Voici comment résoudre le problème :

  1. Dans Fichiers, réduis la distance de vue view-distance dans server.properties et redémarre le serveur.
  2. Pré-génère le monde : Chunky : pré-générer un monde Minecraft.
  3. Si spark est disponible, analyse la charge pendant la perturbation avec spark profiler start --timeout 120 dans la Console. Le rapport montre quels processus consomment du temps.
  4. Si cela concerne à plusieurs reprises le même monde et les mêmes coordonnées de chunk, vérifie les lignes de log environnantes à la recherche d'erreurs de chargement de cette région. En cas de dommage confirmé, arrête le serveur, sauvegarde l'état actuel et restaure une sauvegarde intacte dans Sauvegardes. Les modifications effectuées depuis cette sauvegarde seront perdues.

Bon à savoir : Des coordonnées très élevées indiquent des déplacements loin du centre du monde. Une bordure de monde adaptée limite l'exploration supplémentaire.

« The server has stopped responding » : le watchdog de Paper signale un blocage

Voici à quoi ressemble le message :

The server has stopped responding! This is (probably) not a Paper bug.
If you see a world save or edit, then it means you did far more than your server can handle at once
If this is the case, consider increasing timeout-time in spigot.yml but note that this will replace the crash with LARGE lag spikes

Ce qui se cache derrière : Ces lignes font partie du bloc d'avertissement du watchdog de Paper, qui détecte un thread principal bloqué trop longtemps, c'est-à-dire le thread chargé du déroulement du jeu. Pendant le blocage, le jeu est à l'arrêt ; si le blocage persiste, le watchdog arrête le serveur. Les causes typiques sont des plugins surchargés, de grosses opérations sur le monde ou des accès HTTP et base de données bloquants. Le thread dump en dessous montre les appels de programme en cours d'exécution.

Voici comment le résoudre :

  1. Lis le thread dump dans logs/latest.log sous Fichiers. Vérifie si les plugins mentionnés ont des mises à jour ; adapte leur configuration ou retire-les à titre d'essai, serveur arrêté.
  2. S'il indique de l'édition du monde ou de l'enregistrement, fractionne les grosses actions, par exemple avec WorldEdit, en étapes plus petites.
  3. S'il indique des accès HTTP ou MySQL, vérifie la connexion et l'accessibilité du service dans le plugin concerné.
  4. Augmenter timeout-time dans spigot.yml allonge le délai d'attente, mais ne résout pas le blocage.
  5. En cas de blocages répétés, réduis la charge des plugins et vérifie la mémoire.

Pour aller plus loin : Résoudre correctement « Can't keep up » et le timeout du watchdog

La tâche de chunk de Paper échoue avec un BootstrapMethodError

Voici à quoi ressemble le message :

[ca.spottedleaf.concurrentutil.executor.thread.BalancedPrioritisedThreadPool] Exception thrown from thread <Thread>
java.lang.BootstrapMethodError: bootstrap method initialization exception

Ce qui se passe : Paper charge et génère les chunks dans ses propres threads, c'est-à-dire des fils d'exécution parallèles en dehors du jeu principal. Dans l'un d'eux, Java n'a pas pu préparer un point d'appel dans le programme. Les causes possibles sont un bug de Paper, une extension incompatible ou une version de Java non prise en charge. Le message seul ne permet pas de déterminer laquelle.

Comment le corriger :

  1. Mets Paper à jour dans Version vers un build stable récent correspondant à ta version de Minecraft.
  2. Utilise une version de Java prise en charge par ce build : Quelle version de Java ton serveur Minecraft requiert-il ?
  3. Lis la stacktrace complète dans logs/latest.log. Si une ligne Caused by mentionne un plugin, mets-le à jour dans Plugins.
  4. Ne remplace pas à la main des bibliothèques du serveur. Cela provoque plutôt de nouvelles erreurs.
  5. Si l'erreur se reproduit après la mise à jour, signale la stacktrace complète au projet Paper.

Minecraft ne peut pas enregistrer le rapport de plantage

Voici à quoi ressemble le message :

We were unable to save this crash report to disk.

Ce qui se cache derrière : Le message concerne l'écriture du rapport de plantage. Après une erreur, Minecraft a tenté d'enregistrer le diagnostic sur le disque et n'a pas pu sauvegarder le fichier de rapport. La cause de l'erreur initiale figure plus haut dans la Console ; l'absence de rapport complique le dépannage ultérieur.

Voici comment résoudre le problème :

  1. Commence par sauvegarder le bloc d'erreur complet de la Console, y compris les lignes précédant ce message.
  2. Dans Fichiers, vérifie les fichiers présents dans crash-reports/ ainsi que logs/latest.log. Lis le message d'erreur d'écriture précis et vérifie l'espace de stockage disponible.
  3. Corrige la cause indiquée. Si le chemin reste inaccessible en écriture, ouvre un ticket et indique l'heure ainsi que l'erreur d'écriture.

Ton message n'est pas dans la liste ?

Lis le message en entier dans logs/latest.log et surtout les lignes qui précèdent : une surcharge a presque toujours un déclencheur qui se trouve avant le premier avertissement. Dans la stacktrace ou le thread dump, les noms de paquets, c'est-à-dire les noms de dossiers séparés par des points comme com.<Développeur>.<Plugin>, et les noms de fichiers comme <Plugin>.jar indiquent quel plugin ou quel mod est concerné. Avant de modifier des fichiers de configuration, crée une sauvegarde sous Sauvegardes. Si tu ne t'en sors pas, ouvre un ticket et indique l'heure du message.