Minecraft-Server ruckelt: Ursachen finden und beheben

"Der Server laggt" ist die häufigste Meldung im Ticketsystem eines jeden Gameserver-Betreibers und zugleich die unbrauchbarste. Hinter diesem einen Satz stecken mindestens drei völlig verschiedene technische Probleme, die nichts miteinander zu tun haben und die man mit völlig verschiedenen Mitteln behebt. Wer hier rät statt misst, dreht wochenlang an view-distance und Java-Flags herum, während die eigentliche Ursache eine kaputte Hopper-Kette im Keller eines Spielers ist.

Dieser Beitrag geht den Weg in der Reihenfolge, in der er funktioniert: erst die Unterscheidung, dann die Messung, dann die Ursache, dann die Gegenmaßnahme. Und am Ende die Frage, die die meisten Anleitungen auslassen: woran Sie eigentlich erkennen, dass es wirklich behoben ist.

Zwei Fehlerbilder, die sich identisch anfühlen

Es gibt zwei grundverschiedene Arten von Ruckeln, plus einen dritten Fall, der gar nichts mit dem Server zu tun hat.

Server-Lag bedeutet: der Server schafft seine 20 Berechnungsschritte pro Sekunde nicht mehr. Die Welt selbst läuft langsamer. Mobs stehen still oder zucken, Öfen brauchen länger, abgebaute Blöcke erscheinen wieder, Rüstungsständer schweben verzögert.

Netz-Lag bedeutet: der Server rechnet einwandfrei, aber die Pakete zwischen Spieler und Server brauchen zu lange oder gehen verloren. Der Spieler wird beim Laufen zurückgezogen (Rubberbanding), Schläge treffen nicht, der Chat kommt verspätet, aber die Mobs in der Umgebung bewegen sich völlig flüssig.

Client-Lag ist der dritte Fall: zu wenige Bilder pro Sekunde auf dem Rechner des Spielers, meist durch Shader, hohe Sichtweite im Client oder zu wenig zugewiesenen Arbeitsspeicher. Das ist auf dem Server unsichtbar und dort auch nicht behebbar.

Die eine Regel, die fast immer stimmt: betrifft es alle gleichzeitig, ist es der Server. Betrifft es einzelne, ist es die Leitung. Ein Sonderfall bricht diese Regel: ein völlig überlasteter Server bestätigt auch Netzwerkpakete zu spät und erzeugt dann zusätzlich erhöhte Pings. Deshalb misst man immer beides.

Der erste Test dauert 60 Sekunden

Verbinden Sie sich per SSH auf den Server und öffnen Sie die Serverkonsole. Falls Sie den Dienst noch nicht sauber im Hintergrund laufen haben, hilft der Beitrag zu Minecraft-Server automatisch starten.

Auf Paper, Purpur und Folia ab 1.21 ist der Profiler Spark bereits im Server enthalten, es muss nichts installiert werden. Im Spiel oder in der Konsole:

spark tps
spark health --memory --network

Die Ausgabe von spark tps zeigt vier Zeitfenster (5 Sekunden, 1, 5 und 15 Minuten) sowie die Tickdauern als Minimum, Median, 95. Perzentil und Maximum.

Auf reinem Vanilla ohne Plugins gibt es /tick query. Der Befehl liefert die Zielrate und die durchschnittliche Tickzeit. Zusätzlich blendet F3 plus 2 für Operatoren einen Tick-Graphen ein.

Die Konsole verrät das Problem oft schon von selbst. Nach diesen Zeilen im Wortlaut suchen Leser typischerweise:

[Server thread/WARN]: Can't keep up! Is the server overloaded? Running 2123ms or 42 ticks behind
[Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2340ms behind

Diese Meldung heißt schlicht: der Server hat für einen Rechenschritt deutlich länger gebraucht als die erlaubten 50 Millisekunden und muss Ticks überspringen. Eine einzelne Meldung nach einem Neustart oder einer Weltgenerierung ist normal. Alle paar Minuten eine ist ein echtes Problem.

Parallel dazu die Systemseite prüfen. mpstat gehört auf keinem der geprüften Systeme zur Grundausstattung, es kommt aus dem Paket sysstat und muss einmalig nachinstalliert werden:

apt-get install -y sysstat procps
uptime
free -h
mpstat 1 3

Auf AlmaLinux, Rocky Linux und Oracle Linux lautet die erste Zeile dnf -y install sysstat procps-ng iproute, dort heißt das Paket mit free, uptime, top und vmstat nicht procps, sondern procps-ng.

Interessant ist in der Ausgabe von mpstat vor allem die Spalte %steal. Werte dauerhaft über 5 Prozent bedeuten, dass die virtuelle Maschine auf CPU-Zeit wartet, die ein anderer Gast belegt. Das ist dann kein Minecraft-Problem, sondern ein Kapazitätsproblem der darunterliegenden Hardware.

Ein Vorbehalt zu diesen drei Befehlen: Auf einem eigenen Server oder VPS zeigen sie genau das, was Sie wissen wollen. Läuft Ihr Server dagegen in einem Container, etwa in einem Gamepanel wie Pterodactyl, melden free, uptime, vmstat und mpstat die Werte des Wirtssystems und nicht die Ihrer Instanz. Sie sehen dann fremde Auslastung und fremden Speicher. Verlassen Sie sich in dem Fall auf die Anzeige des Panels und auf spark health.

TPS und MSPT richtig lesen

Ein Minecraft-Server rechnet 20 Ticks pro Sekunde, jeder Tick hat also ein Budget von 50 Millisekunden. MSPT (Millisekunden pro Tick) ist der aussagekräftigere Wert, denn er zeigt Probleme, bevor die TPS überhaupt fallen. Ein Server mit 20,0 TPS und 46 ms MSPT läuft am absoluten Limit und kippt beim nächsten Spieler, der einen neuen Bereich betritt.

• MSPT unter 30 ms: gesund, Reserve vorhanden.
• MSPT 30 bis 45 ms: eng, aber spielbar. Jetzt handeln.
• MSPT über 50 ms: die TPS fallen zwangsläufig, Spieler merken es.

Wichtiger als der Mittelwert ist die Verteilung. Median 18 ms bei Maximum 900 ms bedeutet Spikes: einzelne teure Ereignisse wie das automatische Speichern, Chunkgenerierung oder ein Plugin-Task im Minutentakt. Median 60 ms bedeutet dagegen Dauerlast, also zu viel getickter Inhalt für die vorhandene Rechenleistung. Die Gegenmaßnahmen sind völlig unterschiedlich.

Ein Punkt, den Hardware-Berater gern übergehen: Der Haupttick von Minecraft läuft in einem einzigen Thread. Chunkladen und Netzwerk sind ausgelagert, die eigentliche Weltsimulation nicht. Ein Server mit 32 Kernen und schwacher Einzelkernleistung ist für Minecraft langsamer als einer mit 8 schnellen Kernen. Mehr Kerne helfen erst, wenn mehrere Serverinstanzen darauf laufen.

Spark: vom Verdacht zum Beweis

Timings, das jahrelange Standardwerkzeug, ist bei Paper seit der 1.21er-Reihe auf einen Leerlaufmodus gesetzt und liefert keine brauchbaren Daten mehr. Wer heute noch Timings-Links postet, misst nichts. Der Nachfolger heißt Spark und ist bei Paper eingebaut, für Fabric, Forge und NeoForge gibt es ihn als Mod, für Velocity und BungeeCord als eigene Variante.

Das entscheidende Vorgehen: profilieren Sie, während das Problem auftritt. Ein Profil vom leeren Server um drei Uhr nachts ist wertlos.

spark profiler start --timeout 300
spark profiler stop

Für Spikes, die nur gelegentlich auftreten, filtert man gezielt die schlechten Ticks heraus:

spark profiler start --only-ticks-over 60 --timeout 600

Damit werden nur Ticks aufgezeichnet, die länger als 60 Millisekunden gedauert haben. Genau das sind die, die Spieler spüren. Der Rest wird ignoriert und verrauscht das Bild nicht.

Beim Lesen des Flammendiagramms machen Anfänger fast immer denselben Fehler: sie schauen auf die tiefste Verästelung. Richtig ist der Blick auf die Breite der Balken direkt unter dem Server-Tick. Ein Eintrag mit 3 Prozent ist irrelevant, auch wenn er hundert Ebenen tief geht. Faustregel: Ein einzelnes Plugin über 15 Prozent Anteil an der Tickzeit ist ein Kandidat. Sehr breite Einträge rund um Blockentitäten deuten auf Redstone und Hopper, breite Einträge rund um Chunkladen auf Weltgenerierung.

Ein Hinweis zur Vertraulichkeit: Der hochgeladene Report ist über seinen Link öffentlich abrufbar und enthält Systeminformationen, Pfade, Startparameter und die vollständige Pluginliste. Geben Sie den Link nur an Personen weiter, denen Sie diese Informationen anvertrauen würden. Mit --save-to-file bleibt das Profil lokal.

Die üblichen Verursacher

Redstone und Farmen

Hopper sind mit Abstand die teuersten Blöcke im Spiel, weil jeder einzelne bei jedem Tick prüft, ob über ihm etwas liegt. Eine Sortieranlage mit 400 Hoppern kostet mehr Rechenzeit als hundert Mobs. Dazu kommen Observer-Uhren, die auch dann laufen, wenn niemand in der Nähe ist, sofern der Chunk simuliert wird. Wenn Spark auffällig viel Zeit in Blockentitäten verbringt, suchen Sie nach genau solchen Anlagen.

Entitäten

Auf Paper listet /paper entity list die Entitäten pro Welt und Typ samt Chunkkoordinaten auf. Das ist der schnellste Weg zum Problembereich. Typische Funde: mehrere tausend Item-Stapel in einer Mob-Farm, ein Zuchtstall mit 300 Kühen, ein vergessener Bereich voller abgeworfener Pfeile.

Sinnvolle Gegenmaßnahmen in spigot.yml: die entity-activation-range für Tiere und Monster senken (etwa Tiere von 32 auf 16, Monster von 32 auf 24) und die merge-radius für Items und Erfahrungskugeln leicht anheben, damit weniger Einzelobjekte existieren. In paper-world-defaults.yml begrenzt entity-per-chunk-save-limit, wie viele Objekte eines Typs pro Chunk überhaupt gespeichert werden.

Chunk-Ladung

Ein Spieler mit Elytra oder auf einem schnellen Pferd zwingt den Server, permanent neues Gelände zu erzeugen. Weltgenerierung ist die teuerste Einzeloperation überhaupt. Dasselbe passiert beim ersten Betreten des Nethers oder nach einem Worldborder-Ausbau. Die Lösung ist kein Konfigurationswert, sondern Vorgenerierung, und die ist wichtig genug für einen eigenen Abschnitt weiter unten.

Plugins

Wenn Spark ein Plugin ausweist, ist die Sache klar. Wenn nicht, hilft nur die Halbierungssuche: die Hälfte der Plugins deaktivieren, messen, je nach Ergebnis in der belasteten Hälfte weiterhalbieren. Bei 32 Plugins sind das fünf Neustarts statt 32. Vorher unbedingt ein Backup, denn Plugins, die Weltdaten schreiben, können beim Entfernen Inhalte hinterlassen, die ohne sie nicht mehr funktionieren.

Chunks vorgenerieren, bevor Spieler darauf laufen

Das ist die wirksamste Einzelmaßnahme dieses ganzen Artikels, und sie wird am häufigsten übersehen. Der Grund liegt darin, wie Minecraft arbeitet: Einen bereits erzeugten Chunk von der Platte zu laden kostet fast nichts. Einen neuen Chunk zu erzeugen bedeutet dagegen Höhenkarte, Biome, Erzverteilung, Höhlen, Strukturen und Lichtberechnung, und ein großer Teil davon läuft im Haupt-Thread. Genau dort, wo auch die 20 Ticks pro Sekunde entstehen müssen.

Deshalb ruckelt es typischerweise dann, wenn jemand mit Elytra losfliegt oder eine Bahnstrecke ins Nichts baut: Der Server erzeugt Welt, während er gleichzeitig das Spiel berechnen soll. Wer die Welt einmal vorab bis zur Weltgrenze erzeugt, verwandelt teure Rechenarbeit in billiges Lesen von der Platte.

Chunky, das Werkzeug der Wahl

Chunky ist der heute gebräuchliche Vorgenerator und läuft als Plugin auf Paper, Spigot und Purpur sowie als Mod auf Fabric und Forge. Der Ablauf ist auf allen Plattformen derselbe:

/chunky world world
/chunky center 0 0
/chunky radius 5000
/chunky start

Der Radius ist in Blöcken angegeben und sollte zur Weltgrenze passen. Fortschritt und geschätzte Restdauer meldet Chunky von selbst; mit /chunky pause und /chunky continue lässt sich der Lauf jederzeit anhalten und fortsetzen, auch über einen Neustart hinweg.

Nether und End sind eigene Welten und müssen einzeln vorgeneriert werden. Auf Paper und Spigot heißen sie standardmässig so:

/chunky world world_nether
/chunky radius 1000
/chunky start

Für den Nether genügt ein kleinerer Radius, weil dort ein Block acht Blöcken in der Oberwelt entspricht. Ein Nether-Radius von 1000 deckt also 8000 Blöcke Oberwelt ab.

Was Sie dabei einplanen müssen

• Zeit. Ein Radius von 5000 Blöcken sind rund 78 Millionen Blöcke Fläche. Je nach Hardware, Modpack und Weltgenerator dauert das von einer Stunde bis zu mehreren Tagen. Modpacks mit eigenen Weltgeneratoren sind deutlich langsamer als Vanilla.
• Speicherplatz. Eine vorgenerierte Welt belegt schnell mehrere Gigabyte. Prüfen Sie vorher, wie viel frei ist, sonst läuft die Platte während des Laufs voll und das trifft den Server härter als jedes Ruckeln. Wie Sie das prüfen und aufräumen, steht in Festplatte voll: Speicherplatz finden und freigeben.
• Zeitpunkt. Vorgenerieren Sie mit einem leeren Server, nicht im laufenden Betrieb. Während des Laufs ist die Tickrate erwartungsgemäss schlecht, das ist kein Fehler. Der Sinn der Sache ist ja gerade, diese Last aus der Spielzeit herauszunehmen.
• Weltgrenze setzen. Ohne Grenze läuft irgendwann jemand über den vorgenerierten Bereich hinaus und alles beginnt von vorn. Setzen Sie die Grenze auf denselben Radius, den Sie vorgeneriert haben.

Nachträglich aufräumen

Ist die Welt bereits gewachsen und enthält Gebiete, die niemand mehr betritt, entfernt Chunky die Chunks außerhalb der Weltgrenze:

/chunky trim

Das verkleinert die Welt und damit auch die Sicherungen spürbar. Legen Sie vorher unbedingt eine Sicherung an, denn gelöschte Chunks werden beim nächsten Betreten neu erzeugt und alles, was Spieler dort gebaut hatten, ist verloren.

Wenn Chunky nicht in Frage kommt

Auf älteren Servern findet sich häufig noch WorldBorder mit /wb fill. Das erfüllt denselben Zweck, das Projekt wird aber seit Jahren kaum noch gepflegt, und für aktuelle Serverversionen ist Chunky die zuverlässigere Wahl. Prüfen Sie in beiden Fällen vor der Installation, ob die angebotene Fassung wirklich zu Ihrer Serverversion passt.

view-distance und simulation-distance

Diese beiden Werte in server.properties werden ständig verwechselt.

• view-distance bestimmt, wie weit Chunks an den Client gesendet werden. Kostet Bandbreite und etwas Speicher.
• simulation-distance bestimmt, wie weit der Server Entitäten, Redstone und Blockupdates berechnet. Kostet CPU-Zeit im Haupttick.

Chunks zwischen Simulations- und Sichtgrenze werden angezeigt, sind serverseitig aber eingefroren. Die Kosten wachsen quadratisch: bei view-distance=10 sind es 21 mal 21, also 441 Chunks pro Spieler.

Bewährte Ausgangswerte für ein Survival-Netzwerk mit 10 bis 30 Spielern:

view-distance=8
simulation-distance=5

Wer noch Anleitungen mit no-tick-view-distance findet: Diese Paper-Option ist überholt. Mojang hat mit 1.18 simulation-distance eingeführt und damit dasselbe Problem offiziell gelöst. Wer den alten Wert heute setzt, bewirkt nichts.

Der Preis niedriger Werte wird selten genannt: Bei simulation-distance unter 4 brechen AFK-Farmen zusammen, Mobspawns verhalten sich anders, Öfen im Nachbarchunk laufen nicht weiter und Redstone-Uhren stehen still. Wer eine Farm-lastige Community hat, spart hier an der falschen Stelle und tauscht ein technisches Problem gegen ein Spielerproblem. Gehen Sie in Einerschritten vor und messen Sie nach jedem Schritt.

Aufräumen, ohne die Welt zu zerstören

Jeder Eingriff in die Weltdaten beginnt mit einem Backup bei gestopptem Server. Kein Kompromiss, keine Ausnahme:

tar -czf welt-backup.tar.gz world world_nether world_the_end

Danach lohnt der Blick auf die Größe der Regionsdaten:

du -sh world/region

Welten, die über Jahre gewachsen sind, enthalten oft Hunderte Megabyte an Gelände, das ein einziger Spieler einmal überflogen hat. Diese Chunks kosten keine Tickzeit, aber Plattenplatz und verlängern jeden Speichervorgang. Wenn der Platz knapp wird, hilft zusätzlich der Beitrag Festplatte voll unter Linux aufräumen.

Regelmäßige Spikes im Sekundenbereich, die exakt alle fünf Minuten auftreten, sind fast immer das automatische Speichern. In bukkit.yml steuert ticks-per.autosave das Intervall, in paper-world-defaults.yml begrenzt max-auto-save-chunks-per-tick, wie viel pro Tick geschrieben wird. Ein kleinerer Wert verteilt die Last, statt sie zu bündeln.

Für kleine private Server gibt es seit der 1.21er-Reihe in server.properties die Option pause-when-empty-seconds. Steht dort ein Wert größer als null, hört der Server nach dieser Zeit ohne Spieler auf, die Welt zu ticken. Das spart auf einem geteilten Rootserver spürbar Rechenzeit.

Wenn die JVM bremst

Bleibt die Tickzeit im Mittel niedrig, springt aber unregelmäßig auf mehrere hundert Millisekunden, ist oft die Speicherbereinigung der Java-Laufzeitumgebung schuld. Prüfen lässt sich das direkt:

spark gcmonitor
spark heapsummary

Zwei verbreitete Irrtümer: Mehr Heap ist nicht automatisch besser, denn große Heaps erzeugen längere Pausen bei der Bereinigung. Und der Heap darf niemals so groß gewählt werden, dass das Betriebssystem in den Auslagerungsspeicher gedrängt wird. Ein swappender Minecraft-Server ist unrettbar langsam. Prüfen Sie das mit vmstat 1 5: dauerhafte Werte in den Spalten si und so sind das Todesurteil. Hintergrund dazu im Beitrag Swap einrichten und Out of Memory vermeiden.

Diese Meldung ist ein Symptom, keine Ursache:

java.lang.OutOfMemoryError: Java heap space

Heap zu erhöhen verschiebt den Absturz nur nach hinten, wenn ein Plugin Speicher leckt oder Millionen Entitäten existieren.

Bei der Java-Version unterscheiden sich die Distributionen deutlich, und genau daran scheitern viele Installationen. Ab Minecraft 1.20.5 wird Java 21 vorausgesetzt. Debian 12 liefert im Standardrepository nur OpenJDK 17 und kein OpenJDK 21, Debian 13 liefert 21 und 25, aber kein 17. Ubuntu 22.04 und 24.04 haben 17 und 21 im Repository. Wer auf Debian 12 bleiben muss, installiert Temurin aus dem Adoptium-Repository. Die Schritte stehen in Java 21 auf Debian installieren, für ältere Serverversionen in Java 17 auf Debian installieren.

Greifen Sie dabei nicht zum bequemen Sammelpaket default-jre-headless. Es zeigt je nach Release auf eine völlig andere Version: Debian 13 und Ubuntu 24.04 liefern damit Java 21, Debian 12 liefert Java 17, Debian 11 und Ubuntu 22.04 liefern Java 11. Die Installation läuft überall fehlerfrei durch, der Server startet auf den beiden letztgenannten trotzdem nicht. Nennen Sie die Version deshalb ausdrücklich, also openjdk-21-jre-headless.

java -version
java -XX:+PrintFlagsFinal -version 2>/dev/null | grep -w MaxHeapSize

Das 2>/dev/null unterdrückt das Versionsbanner, das die JVM auf die Fehlerausgabe schreibt und das sonst mitten in der Ausgabe steht. Und grep -w MaxHeapSize liefert genau eine Zeile, während die unscharfe Suche zusätzlich SoftMaxHeapSize findet.

Wenn es schiefgeht und wie Sie zurückkommen

Der Server bricht mit einem Watchdog-Fehler ab. Im Log steht dann sinngemäß, dass ein einzelner Tick 60 Sekunden gedauert habe und der Server als abgestürzt betrachtet wird. Das ist keine Fehlfunktion, sondern eine Schutzmaßnahme gegen einen dauerhaft hängenden Prozess. Der beigefügte Stacktrace ist Gold wert: Er zeigt exakt, worin der Server feststeckte. Der Wert max-tick-time in server.properties steuert diese Schwelle. Ihn abzuschalten behebt nichts, es verwandelt den Absturz nur in einen dauerhaft eingefrorenen Server.

Nach einer Konfigurationsänderung ist es schlimmer. Genau deshalb gilt die wichtigste Regel dieser Fehlersuche: immer nur eine Änderung pro Messung, und den Ausgangswert notieren. Wer view-distance, Entity-Ranges und Java-Flags gleichzeitig anfasst, weiß hinterher nicht, was gewirkt hat.

Der Server startet nach dem Absturz nicht mehr. Meist ist die level.dat beschädigt. Im Weltordner liegt level.dat_old, das Sie nach einer Kopie des kaputten Stands darüberkopieren können. Bei beschädigten Regionsdateien hilft nur das Backup.

Alles ist optimiert und es ruckelt weiter. Dann prüfen Sie die Ebene darunter: %steal in mpstat, Auslagerung in vmstat und die Plattenlatenz. Bleibt die Tickzeit hoch, obwohl Spark keinen einzelnen Verursacher über 10 Prozent zeigt, ist es schlicht zu viel Inhalt für zu wenig Einzelkernleistung. Dann hilft Aufteilen auf mehrere Instanzen oder mehr Rechenleistung, nicht die nächste Konfigurationsschraube.

Nur die Spieler haben hohe Pings, der Server ist ruhig. Dann liegt es am Netz. Ein Standort mit kurzen Wegen zur Spielerschaft macht hier den größten Unterschied. Für Server in Frankfurt am Main liegen typische Latenzen aus dem deutschsprachigen Raum im niedrigen zweistelligen Bereich. Treten Ausfälle plötzlich und gebündelt auf, kann auch ein Angriff dahinterstecken, siehe Server vor DDoS-Angriffen schützen. Auf der Clientseite tauchen dann Meldungen dieser Art auf:

Internal Exception: io.netty.handler.timeout.ReadTimeoutException
Timed out
Connection reset

Woran Sie erkennen, dass es wirklich behoben ist

Ein Fix gilt erst als bestätigt, wenn er unter genau der Last standhält, unter der das Problem aufgetreten ist. Nachts bei zwei Spielern läuft auch ein kaputter Server rund. Prüfen Sie zur Stoßzeit:

• spark tps zeigt im 15-Minuten-Fenster 20,0 und nicht nur im 5-Sekunden-Fenster.
• Das 95. Perzentil der Tickzeit liegt unter 40 ms, das Maximum unter 100 ms.
• 24 Stunden Log ohne eine einzige Zeile "Can't keep up!".
• Ein frisches Spark-Profil zeigt keinen Einzelposten über 15 Prozent mehr.
• spark gcmonitor meldet keine Pausen über 200 ms.
• Die Spieler, die sich gemeldet hatten, bestätigen die Besserung an demselben Ort im selben Spielgeschehen.

Notieren Sie sich Vorher- und Nachher-Werte, idealerweise mit Datum und der jeweils vorgenommenen Änderung. Beim nächsten Einbruch in drei Monaten ist diese Liste mehr wert als jede Anleitung, denn sie zeigt, was auf genau Ihrem Server schon einmal gewirkt hat. Wer den Server neu aufsetzt, findet die passenden Grundlagen in Minecraft-Server auf Debian installieren und in der Checkliste für einen neuen Rootserver.