Een Minecraft-server berekent de wereld in ticks, 20 keer per seconde. Duurt een tick te lang of raakt het werkgeheugen op, dan schrijft de server waarschuwingen naar het log of stopt hij in het slechtste geval. Elk onderdeel hieronder legt een van deze meldingen uit: hoe je ze herkent, hoe ernstig ze zijn en wat je kunt doen. Eerst komen meldingen waarna de server crasht of wordt beëindigd, daarna waarschuwingen waarbij hij blijft draaien.

De volledige melding vind je in de Console of onder Bestanden in logs/latest.log, crashrapporten in de map crash-reports/. Lees altijd ook de regels ervoor: daar staat vaak wat de server heeft vertraagd. Maak vóór wijzigingen aan configuratie- of wereldbestanden onder Back-ups een back-up aan.

Server reageert niet meer: Watchdog-afbreking

Zo ziet de melding eruit:

The server has not responded for 25 seconds! Creating thread dump
A single server tick took <Seconds> seconds

Wat erachter zit: De watchdog is een bewaker die controleert of de server nog werkt. Als een enkele tick te lang blijft hangen, geldt de server als bevroren en beëindigt de watchdog hem. Tot dan schrijft Paper tussentijdse meldingen zoals "has not responded for 25 seconds" samen met een thread dump, een momentopname van wat de server op dat moment doet. Veelvoorkomende oorzaken zijn geheugendruk of een zware plugin of mod.

Zo los je het op:

  1. Lees in logs/latest.log de regels vóór de eerste watchdog-melding. Staat daar al een andere fout of Stopping server, dan is die fout de eigenlijke oorzaak en de watchdog slechts het gevolg.
  2. Bekijk in de thread dump de bovenste regels onder Server thread. Een plugin- of modnaam daar laat zien waar de server het laatst mee bezig was.
  3. Controleer het werkgeheugen. Verschijnt in het log ook OutOfMemoryError, dan is het niet genoeg (zie de secties hieronder).
  4. Werk de gevonden plugin bij of verwijder hem onder Plugins, of doe hetzelfde met de mod onder Mods, en start de server opnieuw op.

Uitgebreid: „Can't keep up“ en watchdog-timeout goed oplossen

Werkgeheugen op: Java heap space

Zo ziet de melding eruit:

java.lang.OutOfMemoryError: Java heap space
Exception in thread "<Thread>" java.lang.OutOfMemoryError: Java heap space

Wat erachter zit: Java beheert het werkgeheugen van de server in een gebied dat heap heet. Dat is vol gelopen: er was niet genoeg werkgeheugen voor de huidige belasting. De server crasht hierdoor meestal of wordt instabiel. Typische geheugenvreters zijn veel geladen chunks, grote modpacks, veel mobs en items en plugins met grote hoeveelheden data.

Zo los je het op:

  1. Start de server opnieuw op, zodat hij weer stabiel draait.
  2. Bepaal hoeveel werkgeheugen jouw setup echt nodig heeft. Uitgebreid: Minecraft-RAM-behoefte plannen
  3. Is je pakket niet genoeg, kies dan onder Instellingen & abonnement → Plan er een met meer RAM.
  4. Verlaag tot die tijd de belasting, bijvoorbeeld de zichtafstand view-distance in de server.properties.

Goed om te weten: De thread waarin de melding verschijnt, is niet automatisch de veroorzaker. Een thread is een parallelle werkstroom, en deze wilde alleen als eerste geheugen toen er niets meer vrij was.

Server is gecrasht: crashrapport opgeslagen

Zo ziet de melding eruit:

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

Wat erachter zit: De server is door een harde fout beëindigd en heeft een crashrapport geschreven. De melding zelf zegt alleen waar dit rapport staat. De eigenlijke oorzaak, bijvoorbeeld een mod, een plugin, de wereld of ontbrekend werkgeheugen, staat in het bestand.

Zo los je het op:

  1. Open onder Bestanden de map crash-reports/ en daarin het genoemde bestand. De naam bevat de datum en tijd van de crash.
  2. Lees de eerste sectie: achter Description: staat een korte beschrijving, daaronder de foutregel en de stacktrace, oftewel de lijst met programmaonderdelen die tot de fout hebben geleid.
  3. De daar genoemde mod- of pluginnaam is de veroorzaker. Werk hem bij onder Mods of Plugins, of verwijder hem.
  4. Staat daar OutOfMemoryError, dan is het werkgeheugen niet genoeg. Kies onder Instellingen & abonnement → Plan meer RAM.
  5. Start de server en houd de Console in de gaten tot hij volledig draait.

Goed om te weten: Crashrapporten blijven staan. Verwijder gelezen rapporten, zodat je de volgende keer meteen het nieuwe vindt. Voor modservers: Modfouten op Forge-, NeoForge- en Fabric-servers

Fout in de hoofdlus van het spel

Zo ziet de melding eruit:

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

Wat erachter zit: De hoofdlus berekent tick voor tick de wereld. Een exception, oftewel een programmafout, is tot in deze lus doorgedrongen en heeft hem verstoord. De server crasht dan meestal en schrijft een crashrapport. De eigenlijke oorzaak staat bijna altijd in de direct volgende Caused by-regel.

Zo los je het op:

  1. Zoek de melding in logs/latest.log of in het nieuwste rapport onder crash-reports/.
  2. Lees de Caused by-regel direct eronder. Zijn het er meerdere, dan leidt de onderste meestal naar de kern van het probleem.
  3. De regels met at … daaronder noemen pakket- en bestandsnamen. Daaraan herken je de betrokken plugin of mod.
  4. Werk hem bij of verwijder hem onder Plugins of Mods en start de server opnieuw op.

Goed om te weten: Deze melding is geen lagprobleem, maar een concrete fout. Meer werkgeheugen helpt alleen als de Caused by-regel een OutOfMemoryError noemt.

Uitgebreid: „Can't keep up“ en watchdog-timeout goed oplossen

Werkgeheugen aan de limiet: GC overhead limit exceeded

Zo ziet de melding eruit:

java.lang.OutOfMemoryError: GC overhead limit exceeded

Wat erachter zit: Java ruimt geheugen dat niet meer nodig is automatisch op. Dat heet garbage collection, kortweg GC. Deze melding betekent: Java is bijna de hele tijd bezig met opruimen en krijgt daarbij nauwelijks nog geheugen terug. De heap, oftewel het werkgeheugen van Java, is praktisch vol. De server reageert nauwelijks nog of crasht.

Zo los je het op:

  1. Start de server opnieuw op.
  2. Bepaal hoeveel werkgeheugen jouw setup nodig heeft. Uitgebreid: Minecraft-RAM-behoefte plannen
  3. Is je pakket niet genoeg, kies dan onder Instellingen & abonnement → Plan meer RAM.
  4. Verlaag de chunk- en entitybelasting: verlaag de zichtafstand view-distance in de server.properties, verklein grote dierenfarms en ruim rondslingerende items op.

Goed om te weten: Een herstart geeft alleen even lucht. Stijgt het verbruik na elke herstart gestaag tot de limiet, terwijl de belasting gelijk blijft, dan kan ook een plugin of mod geheugen vasthouden.

Geen nieuwe thread mogelijk: unable to create native thread

Zo ziet de melding eruit:

java.lang.OutOfMemoryError: unable to create native thread

Wat erachter zit: Een thread is een parallelle werkstroom. Java wilde er nog een starten en kon dat niet. Ondanks OutOfMemoryError in de naam is dit geen bewijs van een volle Java-heap. Meestal draaien er te veel threads tegelijk, is een procesgrens bereikt of ontbreekt er geheugen buiten de heap. De server kan dan geen nieuwe taken meer starten en wordt instabiel. Welke plugin of mod de threads aanmaakt, vertelt deze regel niet.

Zo los je het op:

  1. Boek niet zomaar meer RAM. Meer werkgeheugen voor Java lost deze melding niet automatisch op.
  2. Lees in logs/latest.log de regels vóór de melding: wat liep er op het moment van de fout, welke plugins meldden zich opvallend vaak?
  3. Onderbouw de veroorzaker tijdens runtime. Met spark profiler start --thread * in de Console zie je alle lopende threads. Hun namen verraden vaak de plugin of mod.
  4. Pas als een veroorzaker is aangetoond, werk je hem bij onder Plugins of Mods, controleer je zijn instellingen of verwijder je hem.

Kom je er niet uit, open dan een ticket en noem het tijdstip van de melding. Over spark: spark: lag vinden en begrijpen

Server loopt achter: "Can't keep up"

Zo ziet de melding eruit:

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

Wat erachter zit: Minecraft rekent met 20 ticks per seconde, dus een tick mag 50 milliseconden duren. Duren ticks langer, dan bouwt zich een achterstand op, die de melding in milliseconden en ticks aangeeft. De server blijft draaien, maar merkbaar trager: afgebroken blokken verschijnen opnieuw en mobs haperen. De oorzaak is meestal druk op het geheugen of de CPU. Losse meldingen bij het starten of bij het genereren van nieuwe gebieden zijn normaal.

Zo los je het op:

  1. Meet de belasting met spark tps in de Console. Het gaat om MSPT, de milliseconden per tick: tot 50 ms is alles gezond.
  2. Vind de veroorzaker met spark profiler start --timeout 120 en open de link die de server daarna weergeeft.
  3. Verlaag de belasting: verlaag de zichtafstand view-distance en de simulatieafstand simulation-distance in de server.properties, genereer de wereld vooraf en maak grote farms minder zwaar.
  4. Controleer of het werkgeheugen toereikend is (sectie "Werkgeheugen vol: Java heap space").

Goed om te weten: spark zit al in actuele Paper-servers, op andere servers installeer je het als plugin of mod.

Uitgebreid: "Can't keep up" en watchdog-timeout goed oplossen

Paper-watchdogdiagnose: server hing even

Zo ziet de melding eruit:

--- 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!):

Wat erachter zit: Als de serverthread enkele seconden vastloopt, schrijft Paper een diagnose met een threaddump, oftewel een momentopname van waar de server op dat moment mee bezig is. Zoals de eerste regel zegt: dit is geen fout in Paper en geen crash, maar wel een duidelijke aanwijzing voor lag. Herstelt de server zich, dan blijft het bij die hapering. Duurt het tot aan de limiet, dan volgt de watchdog-afbreking uit de eerste sectie.

Zo los je het op:

  1. Lees in de dump de bovenste regels onder Server thread dump. Staat er een plugin- of modnaam, dan is dat een sterke aanwijzing voor de veroorzaker.
  2. Werk die plugin bij onder Plugins of verwijder hem om te testen.
  3. Komen de dumps vaker voor, controleer dan het werkgeheugen, je plugins en de zichtafstand view-distance in de server.properties.
  4. Losse dumps, bijvoorbeeld bij het starten of bij het opslaan van een grote wereld, kun je gewoon in de gaten houden in plaats van meteen in te grijpen.

Uitgebreid: "Can't keep up" en watchdog-timeout goed oplossen

Server hangt bij het laden van een chunk

Zo ziet de melding eruit:

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

Wat erachter zit: Paper heeft langer dan verwacht gewacht op het laden of genereren van een chunk, oftewel een wereldsegment van 16 × 16 blokken, en heeft daarbij een diagnose geschreven. De server haperkt op dat moment. currentGenStatus toont hoe ver de chunk is gekomen, requestedGenStatus het doel. Meestal zit overbelasting erachter: wereldgeneratie, veel spelers die ver uit elkaar zitten of trage plugins. Minder vaak is een regio beschadigd.

Zo los je het op:

  1. Verlaag de zichtafstand view-distance in de server.properties.
  2. Genereer de wereld vooraf, zodat chunks niet pas tijdens het spelen ontstaan: Chunky: Minecraft-wereld vooraf genereren
  3. Controleer plugins met spark profiler start --timeout 120 in de Console.
  4. Noemt de diagnose steeds dezelfde wereld en dezelfde chunkcoördinaten, dan is de regio beschadigd. Stop de server en zet onder Back-ups een back-up terug.

Goed om te weten: Staan er opvallend grote coördinaten, dan was iemand heel ver weg op pad. Een wereldgrens met worldborder set <Diameter> beperkt dat.

Informatieblok van de Paper-watchdog: server reageerde niet

Zo ziet de melding eruit:

The server has stopped responding! This is (probably) not a Paper bug.
If you see a plugin in the Server thread dump below, then please report it to that author
If this is the case, consider increasing timeout-time in spigot.yml but note that this will replace the crash with LARGE lag spikes

Wat erachter zit: Deze regels vormen een vaste informatietekst die Paper voor de threaddump schrijft. De hoofdthread van de server heeft langer dan de watchdoglimiet niet gereageerd. Typische oorzaken noemt de tekst zelf: een overbelaste plugin, zeer grote wereldbewerkingen ineens of HTTP- en databasetoegang die de serverthread blokkeert.

Zo los je het op:

  1. Lees de threaddump onder het blok. Verschijnt daar een plugin, werk die dan bij, configureer hem of verwijder hem onder Plugins.
  2. Zie je daar het opslaan of bewerken van de wereld, verdeel grote acties, bijvoorbeeld met WorldEdit, in kleinere stappen.
  3. Zie je HTTP- of MySQL-toegang, dan wacht meestal een plugin op een externe dienst of een database. Controleer de verbindingsgegevens daarvan.
  4. Verhoog timeout-time in de spigot.yml alleen bewust. Zoals de melding zegt, ruil je daarmee de crash in voor lange haperingen.
  5. Bij herhaalde haperingen verlaag je de pluginbelasting en controleer je het werkgeheugen.

Uitgebreid: "Can't keep up" en watchdog-timeout goed oplossen

Chunktaak van Paper mislukt met BootstrapMethodError

Zo ziet de melding eruit:

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

Wat erachter zit: Paper laadt en genereert chunks in eigen threads, oftewel parallelle werkstromen naast het hoofdspel. In een daarvan kon Java een aanroeppunt in het programma niet voorbereiden. Mogelijke oorzaken zijn een fout in Paper, een incompatibele uitbreiding of een niet-ondersteunde Java-versie. De melding alleen wijst geen van deze oorzaken aan.

Zo los je het op:

  1. Werk Paper onder Versie bij naar een actuele stabiele build van jouw Minecraft-versie.
  2. Gebruik een Java-versie die door deze build wordt ondersteund: Welke Java-versie heeft jouw Minecraft-server nodig?
  3. Lees de volledige stacktrace in logs/latest.log. Noemt een Caused by-regel een plugin, werk die dan bij onder Plugins.
  4. Vervang serverbibliotheken niet met de hand. Dat veroorzaakt eerder nieuwe fouten.
  5. Komt de fout na de update herhaaldelijk terug, meld dan de volledige stacktrace bij het Paper-project.

Staat jouw melding er niet bij?

Lees de hele melding in logs/latest.log en vooral de regels ervoor: overbelasting heeft bijna altijd een aanleiding die vóór de eerste waarschuwing staat. In de stacktrace of thread dump verraden pakketnamen, dus de door punten gescheiden mapnamen zoals com.<ontwikkelaar>.<plugin>, en bestandsnamen zoals <Plugin>.jar welke plugin of welke mod erbij betrokken is. Maak vóór wijzigingen aan configuratiebestanden onder Back-ups een back-up aan. Kom je er niet uit, open dan een ticket en vermeld het tijdstip van de melding.