Ein Watchdog-Abbruch sagt zuerst etwas über die verstrichene Zeit seit dem letzten Server-Tick aus, nicht direkt über dessen Ursache. Auf Paper setzt max-tick-time in server.properties dafür eine Schwelle in Millisekunden. Die Zeitgrenze allein zeigt nicht, ob CPU-Arbeit, ein Plugin-Aufruf oder Weltarbeit den Tick verzögert hat. Sichere zuerst die Meldung und den Server thread-Dump, ordne den Zeitpunkt der gerade laufenden Aktivität zu und ändere den Schwellenwert nicht als vermeintliche Leistungsverbesserung.
Was max-tick-time misst
Ein Tick ist ein Arbeitsschritt des Servers. Bei 20 Ticks pro Sekunde stehen rechnerisch 50 Millisekunden pro Tick zur Verfügung. Der aktuelle Paper-Eintrag für max-tick-time nennt 60000, also 60 Sekunden für einen einzelnen Tick. Das ist eine Abbruchschwelle, kein empfohlenes Tick-Ziel. Der Wert stammt aus der derzeitigen Paper-Referenz und gilt nicht automatisch für jede Minecraft-Version oder Server-Software. Prüfe deshalb die genaue Engine und Version im Startprotokoll sowie den tatsächlich verwendeten Eintrag deiner server.properties. PaperMC beschreibt dort Einheit, aktuellen Referenzwert und Wirkung.
Paper erklärt, dass ein Tick jenseits dieser Schwelle als festgefahren gilt und der Server beendet wird. Der Eintrag -1 schaltet laut derselben Referenz den Watchdog vollständig aus. Das verbirgt den Abbruchschutz, behebt aber keine lange Arbeit im Server-Thread. Verwende diesen Wert nicht als Reparatur. Für Vanilla, Purpur, Folia oder ältere Builds gelten die jeweils passenden Dokumente und erzeugten Konfigurationswerte.
Paper führt daneben settings.timeout-time in spigot.yml: Diese zweite Watchdog-Schwelle zählt laut Referenz Sekunden seit dem letzten Tick. Sie ist von max-tick-time in server.properties in Millisekunden zu unterscheiden. Die Paper-Klasse WatchdogThread gehört zu diesem zweiten Pfad; ihre Thread-Dump-Hinweise gelten, wenn die konkrete Meldung von diesem Watchdog stammt. Paper dokumentiert timeout-time und seine Einheit.
Meldung und Thread-Dump lesen
Öffne die Serverkonsole und – sofern verfügbar – logs/latest.log. Prüfe zusätzlich, ob für den Zeitpunkt ein Bericht unter crash-reports/ existiert. Suche nach dem ersten Watchdog-Hinweis und lies den gesamten Block danach. Notiere Datum, Uhrzeit, Minecraft-Version, Server-Software und den Wert von max-tick-time; bei Paper auch settings.timeout-time, falls die Meldung zu diesem zweiten Watchdog-Pfad gehört. Der Paper-WatchdogThread-Block enthält einen Server thread dump, die Paper-Version und Hinweise zu Plugin-Aufrufen und Weltänderungen. Der Quelltext belegt diese Paper-/Spigot-Watchdogmeldung, nicht automatisch den Ursprung jedes max-tick-time-Abbruchs. Im Paper-Quelltext ist dieser Diagnoseblock dokumentiert.
Gehe den Stacktrace im Abschnitt Server thread von oben nach unten durch. Ein Pluginname kann ein sinnvoller Prüfhinweis sein, beweist allein aber keinen Programmfehler. Achte darauf, welche Methode lief und ob derselbe Eintrag in mehreren Dumps auftaucht. Siehst du Welt- oder Chunk-Arbeit, prüfe, ob kurz davor viele Chunks geladen, generiert, gespeichert oder verändert wurden. Bei einer Plugin-Methode vergleiche den Zeitpunkt mit einer Aktion im Spiel oder einem geplanten Auftrag. Die Meldung zeigt den festgefahrenen Arbeitsweg; eine einzelne Zeile benennt nicht automatisch die Ursache.
Ursache sicher eingrenzen
- Vergleiche den Zeitpunkt. Notiere, was unmittelbar vor dem Abbruch geschah: Weltbearbeitung, neue Spieler, ein Plugin-Auftrag oder ein Neustart. Ändere zunächst nichts an Welt, Plugins oder Schwellenwert.
- Prüfe Wiederholungen. Wenn derselbe Ablauf erneut auftritt, sichere den vollständigen neuen Dump und vergleiche die obersten Einträge. Wiederkehrende Muster sind aussagekräftiger als eine einzelne Momentaufnahme.
- Miss während des Problems. Bei Paper ab Version 1.21 ist spark laut Paper gebündelt. Ein Profil muss das Problem tatsächlich erfassen; ein Profil nach dem Abbruch rekonstruiert den Stillstand nicht. Die Anleitung Minecraft mit spark gezielt untersuchen erklärt ein passendes Aufnahmefenster. Paper dokumentiert Version und Voraussetzung.
- Arbeite auf einer Kopie. Sichere vor einer Konfigurationsänderung mindestens die Datei. Wenn du eine Welt, ein Plugin oder eine umfangreiche Änderung prüfst, verwende eine getrennte Testkopie mit eigenem Serverordner. Stoppe die betroffene Instanz sauber, ändere pro Versuch nur eine Sache und bewahre das ursprüngliche Log.
Kontrolliere den Start danach und wiederhole nur die Aktivität, die den Fehler ausgelöst hat. Ein brauchbares Ergebnis ist ein Vergleich mit derselben Version, Weltkopie und Aktion: Tritt der Watchdog-Hinweis erneut auf, liegt weiter ein langsamer Tick vor. Bleibt er aus, ist das ein Hinweis für genau diesen Versuch und keine Garantie für alle späteren Sitzungen. Mehr zur allgemeinen Diagnose steht in Minecraft-Server laggt? TPS, RAM und Sichtweite prüfen; für den gezielten Dateiablauf hilft Minecraft server.properties richtig bearbeiten.
Häufige Fehlgriffe
- Den letzten Logeintrag als Ursache lesen:
Stopping serverkann erst nach dem Watchdog-Block erscheinen. Lies die Meldung davor samt Stacktrace. - Einen genannten Plugin-Namen sofort entfernen: Halte Version, Methode und Ereignis fest und prüfe auf einer Kopie. Ein Name im Stack ist zunächst ein Hinweis.
max-tick-timeblind erhöhen oder auf-1setzen: Ein längerer Grenzwert macht die Arbeit im Tick nicht kleiner;-1schaltet den Watchdog aus. Beides ersetzt die Ursachenprüfung nicht.- Den Paper-Referenzwert auf andere Engines übertragen: Vergleiche immer die Version, die tatsächlich gestartet wird, mit deren eigener Dokumentation und Konfigurationsdatei.
Wenn du Hilfe anfragst, teile nur den relevanten Zeitabschnitt aus Konsole, Log und Thread-Dump. Entferne vorher persönliche Daten, Adressen und Zugangswerte. Eine Anleitung zum Zusammenstellen eines passenden Ausschnitts bietet Gameserver-Logs für eine Supportanfrage vorbereiten.