Minecraft-Server überlastet: Watchdog, Lag und Speicherfehler beheben

Ein Minecraft-Server berechnet die Welt in Ticks, 20 Mal pro Sekunde. Dauert ein Tick zu lange oder geht der Arbeitsspeicher aus, schreibt der Server Warnungen ins Log oder bricht im schlimmsten Fall ab. Jeder Abschnitt unten erklärt eine dieser Meldungen: woran du sie erkennst, wie ernst sie ist und was du tun kannst. Zuerst kommen Meldungen, nach denen der Server abstürzt oder beendet wird, danach Warnungen, bei denen er weiterläuft.

Die vollständige Meldung findest du in der Konsole oder unter Dateien in logs/latest.log, Absturzberichte im Ordner crash-reports/. Lies immer auch die Zeilen davor: Dort steht oft, was den Server ausgebremst hat. Lege vor Änderungen an Konfigurations- oder Weltdateien unter Sicherungen eine Sicherung an.

Server reagiert nicht mehr: Watchdog-Abbruch

So sieht die Meldung aus:

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

Was dahintersteckt: Der Watchdog ist ein Wächter, der prüft, ob der Server noch arbeitet. Hängt ein einzelner Tick zu lange, gilt der Server als eingefroren, und der Watchdog beendet ihn. Bis dahin schreibt Paper Zwischenmeldungen wie „has not responded for 25 seconds“ samt einem Thread-Dump, einer Momentaufnahme dessen, was der Server gerade tut. Häufige Ursachen sind Speicherdruck oder ein schweres Plugin bzw. ein schwerer Mod.

So behebst du es:

1. Lies in logs/latest.log die Zeilen vor der ersten Watchdog-Meldung. Steht dort schon ein anderer Fehler oder Stopping server, ist dieser Fehler die eigentliche Ursache und der Watchdog nur die Folge.
2. Sieh dir im Thread-Dump die obersten Zeilen unter Server thread an. Ein Plugin- oder Mod-Name dort zeigt, was den Server zuletzt beschäftigt hat.
3. Prüfe den Arbeitsspeicher. Taucht im Log auch OutOfMemoryError auf, reicht er nicht (Abschnitte weiter unten).
4. Aktualisiere oder entferne das gefundene Plugin unter Plugins bzw. den Mod unter Mods und starte den Server neu.

Ausführlich: „Can't keep up“ und Watchdog-Timeout richtig beheben

Arbeitsspeicher erschöpft: Java heap space

So sieht die Meldung aus:

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

Was dahintersteckt: Java verwaltet den Arbeitsspeicher des Servers in einem Bereich namens Heap. Der ist vollgelaufen: Für die aktuelle Last war nicht genug Arbeitsspeicher da. Der Server stürzt dadurch meist ab oder wird instabil. Typische Speicherfresser sind viele geladene Chunks, große Modpacks, viele Mobs und Items sowie Plugins mit großen Datenmengen.

So behebst du es:

1. Starte den Server neu, damit er wieder stabil läuft.
2. Ermittle, wie viel Arbeitsspeicher dein Setup wirklich braucht. Ausführlich: Minecraft-RAM-Bedarf planen
3. Reicht dein Paket nicht, wähle unter Einstellungen & Abo → Plan eines mit mehr RAM.
4. Senke bis dahin die Last, etwa die Sichtweite view-distance in der server.properties.

Gut zu wissen: Der Thread, in dem die Meldung auftaucht, ist nicht automatisch der Verursacher. Ein Thread ist ein paralleler Arbeitsstrang, und dieser wollte nur als Erster Speicher, als keiner mehr frei war.

Server ist abgestürzt: Absturzbericht gespeichert

So sieht die Meldung aus:

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

Was dahintersteckt: Der Server wurde durch einen harten Fehler beendet und hat einen Absturzbericht geschrieben. Die Meldung selbst sagt nur, wo dieser Bericht liegt. Die eigentliche Ursache, etwa ein Mod, ein Plugin, die Welt oder fehlender Arbeitsspeicher, steht in der Datei.

So behebst du es:

1. Öffne unter Dateien den Ordner crash-reports/ und darin die genannte Datei. Ihr Name enthält Datum und Uhrzeit des Absturzes.
2. Lies den ersten Abschnitt: Hinter Description: steht eine Kurzbeschreibung, darunter die Fehlerzeile und der Stacktrace, also die Liste der Programmstellen, die zum Fehler geführt haben.
3. Der dort genannte Mod- oder Plugin-Name ist der Verursacher. Aktualisiere ihn unter Mods bzw. Plugins oder entferne ihn.
4. Steht dort OutOfMemoryError, reicht der Arbeitsspeicher nicht. Wähle unter Einstellungen & Abo → Plan mehr RAM.
5. Starte den Server und beobachte die Konsole, bis er vollständig läuft.

Gut zu wissen: Absturzberichte bleiben liegen. Lösche gelesene Berichte, damit du beim nächsten Mal sofort den neuen findest. Für Mod-Server: Mod-Fehler auf Forge-, NeoForge- und Fabric-Servern

Fehler in der Spiel-Hauptschleife

So sieht die Meldung aus:

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

Was dahintersteckt: Die Hauptschleife berechnet Tick für Tick die Welt. Eine Exception, also ein Programmfehler, ist bis in diese Schleife durchgeschlagen und hat sie gestört. Der Server stürzt dann meist ab und schreibt einen Absturzbericht. Die eigentliche Ursache steht fast immer in der direkt folgenden Caused by-Zeile.

So behebst du es:

1. Suche die Meldung in logs/latest.log oder im neuesten Bericht unter crash-reports/.
2. Lies die Caused by-Zeile direkt darunter. Gibt es mehrere, führt die unterste meist zur Wurzel des Problems.
3. Die Zeilen mit at … darunter nennen Paket- und Dateinamen. Daran erkennst du das beteiligte Plugin oder den Mod.
4. Aktualisiere oder entferne es unter Plugins bzw. Mods und starte den Server neu.

Gut zu wissen: Diese Meldung ist kein Lag-Problem, sondern ein konkreter Fehler. Mehr Arbeitsspeicher hilft nur, wenn die Caused by-Zeile ein OutOfMemoryError nennt.

Ausführlich: „Can't keep up“ und Watchdog-Timeout richtig beheben

Arbeitsspeicher am Limit: GC overhead limit exceeded

So sieht die Meldung aus:

java.lang.OutOfMemoryError: GC overhead limit exceeded

Was dahintersteckt: Java räumt nicht mehr benötigten Speicher automatisch auf. Das nennt man Garbage Collection, kurz GC. Diese Meldung heißt: Java verbringt fast die ganze Zeit mit Aufräumen und gewinnt dabei kaum noch Speicher zurück. Der Heap, also der Arbeitsspeicher von Java, ist praktisch voll. Der Server reagiert kaum noch oder stürzt ab.

So behebst du es:

1. Starte den Server neu.
2. Ermittle, wie viel Arbeitsspeicher dein Setup braucht. Ausführlich: Minecraft-RAM-Bedarf planen
3. Reicht dein Paket nicht, wähle unter Einstellungen & Abo → Plan mehr RAM.
4. Verringere die Chunk- und Entity-Last: Senke die Sichtweite view-distance in der server.properties, verkleinere große Tierfarmen und räume herumliegende Items auf.

Gut zu wissen: Ein Neustart verschafft nur Luft. Steigt der Verbrauch nach jedem Neustart stetig bis zum Limit, obwohl die Last gleich bleibt, kann auch ein Plugin oder Mod Speicher festhalten.

Kein neuer Thread möglich: unable to create native thread

So sieht die Meldung aus:

java.lang.OutOfMemoryError: unable to create native thread

Was dahintersteckt: Ein Thread ist ein paralleler Arbeitsstrang. Java wollte einen weiteren starten und konnte es nicht. Trotz OutOfMemoryError im Namen ist das kein Nachweis für einen vollen Java-Heap. Meist laufen zu viele Threads gleichzeitig, eine Prozessgrenze ist erreicht oder es fehlt Speicher außerhalb des Heaps. Der Server kann dann neue Aufgaben nicht mehr starten und wird instabil. Welches Plugin oder welcher Mod die Threads erzeugt, verrät diese Zeile nicht.

So behebst du es:

1. Buche nicht pauschal mehr RAM. Mehr Arbeitsspeicher für Java löst diese Meldung nicht automatisch.
2. Lies in logs/latest.log die Zeilen vor der Meldung: Was lief zum Fehlerzeitpunkt, welche Plugins meldeten sich gehäuft?
3. Belege den Verursacher zur Laufzeit. Mit spark profiler start --thread * in der Konsole siehst du alle laufenden Threads. Ihre Namen verraten oft das Plugin oder den Mod.
4. Erst wenn ein Verursacher belegt ist, aktualisierst du ihn unter Plugins bzw. Mods, prüfst seine Einstellungen oder entfernst ihn.

Kommst du nicht weiter, öffne ein Ticket und nenne die Uhrzeit der Meldung. Zu spark: spark: Lag finden und verstehen

Server kommt nicht hinterher: „Can't keep up“

So sieht die Meldung aus:

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

Was dahintersteckt: Minecraft rechnet 20 Ticks pro Sekunde, ein Tick darf also 50 Millisekunden dauern. Dauern Ticks länger, baut sich ein Rückstand auf, den die Meldung in Millisekunden und Ticks angibt. Der Server läuft weiter, aber spürbar langsamer: Abgebaute Blöcke tauchen wieder auf, Mobs ruckeln. Ursache ist meist Speicher- oder CPU-Druck. Einzelne Meldungen beim Start oder beim Erzeugen neuer Gebiete sind normal.

So behebst du es:

1. Miss die Last mit spark tps in der Konsole. Entscheidend ist MSPT, die Millisekunden pro Tick: Bis 50 ms ist alles gesund.
2. Finde den Verursacher mit spark profiler start --timeout 120 und öffne den Link, den der Server danach ausgibt.
3. Senke die Last: Sichtweite view-distance und Simulationsweite simulation-distance in der server.properties verringern, Welt vorgenerieren, große Farmen entschärfen.
4. Prüfe, ob der Arbeitsspeicher reicht (Abschnitt „Arbeitsspeicher erschöpft: Java heap space“).

Gut zu wissen: spark ist auf aktuellen Paper-Servern bereits enthalten, auf anderen Servern installierst du es als Plugin bzw. Mod.

Ausführlich: „Can't keep up“ und Watchdog-Timeout richtig beheben

Paper-Watchdog-Diagnose: Server hing kurz

So sieht die Meldung aus:

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

Was dahintersteckt: Hängt der Server-Thread für einige Sekunden, schreibt Paper eine Diagnose mit einem Thread-Dump, also einer Momentaufnahme, woran der Server gerade arbeitet. Wie die erste Zeile sagt: Das ist kein Fehler in Paper und kein Absturz, aber ein deutlicher Lag-Hinweis. Fängt sich der Server wieder, bleibt es bei dem Hänger. Dauert er bis zur Grenze, folgt der Watchdog-Abbruch aus dem ersten Abschnitt.

So behebst du es:

1. Lies im Dump die obersten Zeilen unter Server thread dump. Steht dort ein Plugin- oder Mod-Name, ist das ein starker Hinweis auf den Verursacher.
2. Aktualisiere dieses Plugin unter Plugins oder entferne es testweise.
3. Häufen sich die Dumps, prüfe den Arbeitsspeicher, deine Plugins und die Sichtweite view-distance in der server.properties.
4. Einzelne Dumps, etwa beim Start oder beim Speichern einer großen Welt, kannst du beobachten statt sofort einzugreifen.

Ausführlich: „Can't keep up“ und Watchdog-Timeout richtig beheben

Server hängt beim Laden eines Chunks

So sieht die Meldung aus:

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

Was dahintersteckt: Paper hat länger als erwartet auf das Laden oder Erzeugen eines Chunks gewartet, also eines Weltabschnitts von 16 × 16 Blöcken, und dazu eine Diagnose geschrieben. Der Server hakt in diesem Moment. currentGenStatus zeigt, wie weit der Chunk gekommen ist, requestedGenStatus das Ziel. Meist steckt Überlast dahinter: Weltgenerierung, viele Spieler weit auseinander oder langsame Plugins. Seltener ist eine Region beschädigt.

So behebst du es:

1. Senke die Sichtweite view-distance in der server.properties.
2. Erzeuge die Welt vorab, damit Chunks nicht erst beim Spielen entstehen: Chunky: Minecraft-Welt vorgenerieren
3. Prüfe Plugins mit spark profiler start --timeout 120 in der Konsole.
4. Nennt die Diagnose immer dieselbe Welt und dieselben Chunk-Koordinaten, ist die Region beschädigt. Stoppe den Server und spiele unter Sicherungen eine Sicherung ein.

Gut zu wissen: Stehen dort auffällig große Koordinaten, war jemand sehr weit draußen unterwegs. Eine Weltgrenze mit worldborder set <Durchmesser> begrenzt das.

Hinweisblock des Paper-Watchdogs: Server reagierte nicht

So sieht die Meldung aus:

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

Was dahintersteckt: Diese Zeilen sind ein fester Hinweistext, den Paper vor den Thread-Dump schreibt. Der Haupt-Thread des Servers hat länger als das Watchdog-Limit nicht reagiert. Typische Gründe nennt der Text selbst: ein überlastetes Plugin, sehr große Weltoperationen auf einmal oder HTTP- und Datenbankzugriffe, die den Server-Thread blockieren.

So behebst du es:

1. Lies den Thread-Dump unterhalb des Blocks. Taucht dort ein Plugin auf, aktualisiere, konfiguriere oder entferne es unter Plugins.
2. Siehst du dort das Speichern oder Bearbeiten der Welt, teile große Aktionen, etwa mit WorldEdit, in kleinere Schritte auf.
3. Siehst du HTTP- oder MySQL-Zugriffe, wartet meist ein Plugin auf einen externen Dienst oder eine Datenbank. Prüfe dessen Verbindungsdaten.
4. Erhöhe timeout-time in der spigot.yml nur bewusst. Wie der Hinweis sagt, tauschst du damit den Absturz gegen lange Hänger.
5. Bei wiederholten Hängern senkst du die Plugin-Last und prüfst den Arbeitsspeicher.

Ausführlich: „Can't keep up“ und Watchdog-Timeout richtig beheben

Chunk-Aufgabe von Paper scheitert mit BootstrapMethodError

So sieht die Meldung aus:

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

Was dahintersteckt: Paper lädt und erzeugt Chunks in eigenen Threads, also parallelen Arbeitssträngen neben dem Hauptspiel. In einem davon konnte Java eine Aufrufstelle im Programm nicht vorbereiten. Mögliche Gründe sind ein Fehler in Paper, eine inkompatible Erweiterung oder eine nicht unterstützte Java-Version. Die Meldung allein legt keine dieser Ursachen fest.

So behebst du es:

1. Aktualisiere Paper unter Version auf einen aktuellen stabilen Build deiner Minecraft-Version.
2. Verwende eine Java-Version, die dieser Build unterstützt: Welche Java-Version braucht dein Minecraft-Server?
3. Lies den vollständigen Stacktrace in logs/latest.log. Nennt eine Caused by-Zeile ein Plugin, aktualisiere es unter Plugins.
4. Tausche keine Serverbibliotheken von Hand aus. Das verursacht eher neue Fehler.
5. Tritt der Fehler nach dem Update wiederholt auf, melde den vollständigen Stacktrace beim Paper-Projekt.

Deine Meldung ist nicht dabei?

Lies die ganze Meldung in logs/latest.log und vor allem die Zeilen davor: Überlast hat fast immer einen Auslöser, der vor der ersten Warnung steht. Im Stacktrace oder Thread-Dump verraten Paketnamen, also die durch Punkte getrennten Ordnernamen wie com.<Entwickler>.<Plugin>, und Dateinamen wie <Plugin>.jar, welches Plugin oder welcher Mod beteiligt ist. Lege vor Änderungen an Konfigurationsdateien unter Sicherungen eine Sicherung an. Kommst du nicht weiter, öffne ein Ticket und nenne die Uhrzeit der Meldung.