Minecraft-Server-Lag beheben: erst die Ursache finden

Bevor du eine einzige Einstellung änderst, finde heraus, welche von drei Arten Lag du hast: Die Tick-Schleife des Servers hinkt hinterher, das Netzwerk zwischen Spielern und Server hakt, oder der Rechner eines Spielers kommt mit dem Zeichnen des Spiels nicht nach. Führe in deiner aktivsten Stunde /spark tps aus. Bleiben die Tick-Dauern unter 50 ms, kommt der Server mit, und der Lag, den deine Spieler spüren, kommt von woanders.

Die meisten „Optimierungs-Guides“ überspringen diesen Schritt und drücken dir eine Liste von Einstellungen in die Hand. Manche davon helfen, einige machen das Spiel schlechter, und keine löst ein Problem, das du noch nicht gefunden hast. Dieser Ratgeber beginnt mit der Diagnose.

Drei Arten von Lag (Server-Tick, Netzwerk, Client)

Ein kurzer Nerd-Exkurs zu den Zahlen, denn er erklärt, warum TPS lügt. Der Server strebt 20 Ticks pro Sekunde an, jeder Tick hat also ein Budget von 50 ms. TPS kann nie über 20 steigen, was bedeutet, dass ein Server, der 10 ms pro Tick braucht, und einer, der 48 ms braucht, beide 20,0 TPS anzeigen. Der erste könnte ein Vielfaches seiner jetzigen Last tragen, der zweite ist eine Trichterfarm vom Lag entfernt. MSPT (Millisekunden pro Tick) zeigt diesen Spielraum, achte also auf MSPT, nicht auf TPS.

Messen, bevor du etwas änderst

1. Wähle die richtige Stunde. Lag, der zur Stoßzeit auftritt, lässt sich um fünf Uhr morgens nicht messen. Die vier aktivsten Stunden unseres Netzwerks sind 14:00 UTC bis 18:00 UTC in deiner Zeitzone, und die öffentliche Statistikseite deines Eintrags zeigt deine eigenen aktivsten Stunden.
2. Führe /spark tps aus. Es zeigt die TPS der letzten 5 Sekunden bis 15 Minuten und die Tick-Dauern als Minimum, Median, 95. Perzentil und Maximum. Ein Median deutlich unter 50 ms bei einem 95. Perzentil darüber bedeutet Spitzen, keine Dauerüberlastung. Das /mspt von Paper gibt die Kurzfassung.
3. Führe /spark health aus. Es ergänzt CPU-Auslastung, Arbeitsspeicher und Festplatte, sodass du auf einen Blick siehst, ob der Maschine selbst etwas ausgeht.
4. Lies die Konsole. Die Vanilla-Warnung Can't keep up! Is the server overloaded? Running 2034ms or 40 ticks behind (die Serverkonsole schreibt sie auf Englisch) bedeutet, dass der Server ins Hintertreffen geraten ist und Ticks übersprungen hat, um aufzuholen. Eine pro Tag ist Rauschen. Eine pro Minute ist ein Problem.
5. Schreib die Ausgangswerte auf: Uhrzeit, Spieler online, MSPT-Median und 95. Perzentil und wo die Spieler waren (ein neues Gebiet, eine große Farm, ein Event). Nach jeder Änderung vergleichst du damit.

Auf einem Server ohne spark meldet /tick query aus Vanilla (Java Edition 1.20.3 und neuer, Berechtigungsstufe 3) die durchschnittliche Zeit pro Tick und deren Perzentile.

Höchststand 16:00 UTC

0003060912151821

Zeiten in UTC

Am vollsten um 16:00 UTC mit etwa 17.845 Spielern, am ruhigsten um 01:00 UTC. In der vollsten Stunde sind 2,6-mal so viele Spieler online wie in der ruhigsten.

Gemessen 19 Okt. 2026, 22:55 UTCSo messen wir

Ein spark-Profil lesen

Wenn die Zahlen sagen, dass der Server langsam ist, sagt der Profiler, warum. Die Dokumentation von PaperMC empfiehlt:

/spark profiler start --timeout 600

Das nimmt zehn Minuten lang von jedem Thread Stichproben und gibt dir einen Link zum Bericht. Zwei Varianten helfen bei bestimmten Problemen:

• /spark profiler start --only-ticks-over 100 zeichnet nur Ticks auf, die langsamer als 100 ms sind, und trennt so kurze Lagspitzen vom normalen Hintergrund.
• /spark tickmonitor --threshold-tick 100 gibt jedes Mal eine Zeile aus, wenn ein Tick länger als 100 ms dauert, damit du Spitzen dem zuordnen kannst, was im Spiel gerade geschah.

Das Profil muss laufen, während der Lag passiert. Das Profil eines ruhigen Servers um 05:00 Uhr sagt dir nichts über den Lag um 18:00 Uhr.

Öffne im Viewer den Server-Thread und folge dem größten Prozentwert nach unten. Du suchst den Ast, in dem die Zeit bleibt:

• Entity-Ticking, oft mit Mob-KI oder Wegfindung von Dorfbewohnern darunter, deutet auf Mobs hin (nächster Abschnitt).
• Block-Entities, mit Trichtern weit oben in der Liste, deuten auf Trichterketten und Lagersysteme hin.
• Chunk-Arbeit (Generieren, Laden, Speichern) deutet auf Spieler hin, die neues Gelände erkunden.
• Der Name eines Plugins im Aufrufbaum oder weit oben in der Aufschlüsselung des Viewers nach Plugin deutet auf dieses Plugin hin. Notiere, was es gerade tat (ein Event-Handler, eine geplante Aufgabe, ein Datenbankaufruf), bevor du ihm die Schuld gibst, denn dasselbe Plugin kann mit einer anderen Einstellung unproblematisch sein.

Auch die Garbage Collection zeichnet spark auf. Häufige Pausen von Hunderten Millisekunden deuten auf Speicherdruck hin, den /spark gc im Zeitverlauf zeigt. Erstelle auch einmal ein Profil, wenn der Server in Ordnung ist, damit du weißt, wie der Normalzustand auf deinem Setup aussieht.

Die üblichen Verdächtigen (Entities, Chunk-Generierung, Redstone, Plugins, Garbage Collection)

Entities

Mob-Farmen, Handelshallen mit Dorfbewohnern, Haufen fallen gelassener Items, Loren-Systeme und Dekorationen aus Rüstungsständern ticken alle. Auf Paper zeigt /paper entity list die tickenden Entities nach Typ, und ein Filter wie /paper entity list minecraft:villager grenzt sie ein, sodass du findest, wo sie sich häufen. /paper mobcaps zeigt, wie voll die Mob-Caps sind, und /paper chunkinfo, wie viele Chunks geladen sind und ticken. Die Lösungen sind Limits, keine Verbote: eine Obergrenze für Entities pro Chunk, Farm-Regeln, auf die sich deine Spieler einigen, und ein Gespräch mit dem, der die Halle mit 400 Dorfbewohnern gebaut hat.

Chunk-Generierung

Einen neuen Chunk zu generieren gehört zu den teuersten Dingen, die ein Server tut, und Spieler mit Elytren können Dutzende pro Minute verlangen. Generiere die Welt einmal vor, mit einem Plugin wie Chunky (/chunky radius 5000, dann /chunky start), in ruhigen Stunden, und lege mit /worldborder set 10000 eine passende Weltgrenze fest. Die Grenze nimmt einen Durchmesser, der Chunky-Radius ist die Hälfte davon, beide Zahlen beschreiben also dasselbe Quadrat. Danach lädt das Erkunden nur noch Chunks von der Festplatte, was weit günstiger ist.

Redstone und Trichter

Schnelle Redstone-Uhren und lange Trichterketten summieren sich. Paper bietet in config/paper-world-defaults.yml zwei Stellschrauben. misc.redstone-implementation: ALTERNATE_CURRENT tauscht eine schnellere Implementierung des Redstone-Staubs ein. hopper.disable-move-event: true macht Trichter günstiger, macht aber Plugins kaputt, die sich auf dieses Event verlassen, etwa einige Schutz- und Trichterfilter-Plugins, teste also zuerst. hopper.cooldown-when-full ist standardmäßig schon aktiv.

Plugins

Ein schweres Plugin taucht im Profil mit Namen auf. Die üblichen Muster sind Scoreboards, Hologramme oder Tab-Listen, die sich jeden Tick neu aufbauen, Datenbank- oder Web-Anfragen im Hauptthread, Weltkarten-Renderer, die eine große Welt abarbeiten, und Anti-Cheat-Prüfungen unter Last. Die Lösung ist meist zuerst Konfiguration (Aktualisierungsintervalle, Render-Limits), dann ein Update, dann ein Ersatz.

Garbage Collection

Zeigt spark lange oder häufige Collection-Pausen, prüfe zuerst den Speicher: Ist -Xmx zu klein für Welt und Plugins, und ist -Xms auf denselben Wert gesetzt? Die empfohlenen Flags von PaperMC sind ein solider Standard. Mehr Speicher hilft nur, wenn die Collection das Problem ist, und auf einem geteilten Host lässt die Zuweisung des gesamten Speichers das Betriebssystem verhungern.

Fixes, die funktionieren

Wenn du die Ursache kennst, zahlen sich diese Änderungen meist aus, grob in der Reihenfolge, in der wir sie probieren würden:

Die Änderung bei simulation-distance ist größer, als sie aussieht. Um jeden Spieler tickt der Server grob ein Quadrat aus Chunks. Von 10 auf 6 zu gehen schrumpft es von etwa 21 mal 21 Chunks auf 13 mal 13, von rund 441 Chunks auf rund 169, während die Spieler weiterhin so weit sehen, wie view-distance es erlaubt.

Manche beliebten Ratschläge helfen nicht. Plugins, die alle paar Minuten alle fallen gelassenen Items löschen, behandeln ein Symptom und nerven Spieler. „Optimierungs“-Plugins, die höhere TPS versprechen, ohne zu sagen, was sie ändern, sind ein Profil davor und danach wert. Und alle zwei Stunden neu zu starten versteckt Probleme, statt sie zu finden.

Netzwerk-Lag von außen gesehen

Ein Detail überrascht viele Betreiber. Den Status-Ping, den Serverlisten nutzen, beantworten die Netzwerk-Threads des Servers, nicht die Tick-Schleife. Ein Server kann im Spiel also schwer laggen und unseren Pinger trotzdem in wenigen Millisekunden beantworten. Tick-Lag können wir von außen nicht sehen, und genau dafür gibt es spark. Hinter Velocity spricht der Pinger immer nur mit dem Proxy.

Was unser Pinger sehen kann, ist das Netzwerk. Die öffentliche Statistikseite deines Eintrags (/server/your-server/stats) zeigt drei Dinge, die sich zu lesen lohnen:

• Antwortzeit, wie lange der Server brauchte, um unseren Pinger zu beantworten, mit Median, üblicher Spanne und einem Diagramm. Das Niveau bestimmt vor allem die Entfernung zu unserem Pinger in Westeuropa, ein Server in den USA zeigt dort also keine 10 ms, es sei denn, ein Schutznetzwerk antwortet von einem nahen Edge-Standort. Schau auf die Form im Zeitverlauf, nicht auf den Wert.
• Spitzen über der üblichen Spanne. Steigen die Antworten nur zu deinen Stoßzeiten weit über die übliche Spanne, ist die Maschine oder ihre Netzwerkanbindung zu diesen Zeiten ausgelastet. Ist die Spanne zu allen Stunden breit, verdächtige die Route oder das Netzwerk des Hosts.
• Das Ausfallprotokoll. Kurze Lücken sind Neustarts oder Abstürze. Bei langen Lücken lohnt ein Blick auf die Statusseite deines Hosts und auf deine Crash-Reports.

Frag betroffene Spieler nach einem Traceroute zu deiner Adresse (tracert unter Windows, traceroute unter macOS und Linux) und nach ihrer Region. Laggen alle in einem Land und sonst niemand, liegt es an der Route, und ein Umzug oder ein Schutznetzwerk mit nahem Edge-Standort kann mehr helfen als jede Einstellung. Spieler, die sich gar nicht verbinden können, haben andere Probleme, die unser Ratgeber zu Verbindungsfehlern behandelt.

Wann neu starten, und wann nicht

Neustarts sind nicht gratis. Alle, die online sind, werden gekickt, und ein Spieler, der an einem Sonntagabend mitten im Kampf gekickt wird, merkt sich das. Unsere Ausfalldaten zeigen, wie Betreiber sie tatsächlich planen.

In den 30 Tagen bis zum 16. Oktober 2026 waren 90 Einträge auf unserer Liste zu mindestens 90 % der Zeit spielbar. 58 davon hatten mindestens einen Ausfall, den wir als drei oder mehr Pings in Folge ohne spielbare Antwort zählen, und zusammen kamen sie auf 515. Gemessen vom ersten verpassten Ping bis zum letzten war die Hälfte der Ausfälle in unter fünf Minuten vorbei, und das längste Zehntel dauerte über zwei Stunden. 375 der 515 (73 %) dauerten 15 Minuten oder weniger, die Länge eines Neustarts oder eines Absturzes mit Reboot.

Wann begannen diese kurzen Ausfälle? Eine Stunde sticht heraus: 04:00 Uhr UTC, mit 39 der 375, das typische Muster geplanter nächtlicher Neustarts. Außerhalb dieser Stunde verteilen sie sich ziemlich gleichmäßig über den Tag. 64 der 375 (17 %) begannen zwischen 14:00 und 18:00 Uhr UTC, den vier aktivsten Stunden auf unserer Liste, ungefähr der Anteil, den man erwarten würde, wenn Neustartzeiten zufällig gewählt würden.

19 %Kurze Ausfälle, die in den vier aktivsten Stunden des Netzwerks begannen, letzte 30 Tage

Gemessen 19 Okt. 2026, 21:52 UTCSo messen wir

Live, für die letzten 30 Tage: 472 Ausfälle bei 83 Einträgen mit 90 % oder mehr, ein Median von 5 Minuten Minuten, 70 % davon 15 Minuten oder kürzer. Die häufigste Startstunde kurzer Ausfälle ist 04:00 UTC in deiner Zeitzone, und die ruhigste Stunde des Netzwerks ist 01:00 UTC.

Was du daraus mitnimmst:

1. Starte in deiner eigenen ruhigen Stunde neu, nicht einfach zu einer runden Uhrzeit. Die Heatmap auf deiner Statistikseite zeigt sie, und wann Server am vollsten sind zeigt, wie sie sich nach Region unterscheidet. Sind deine Spieler über Zeitzonen verteilt, wähle den tiefsten Punkt deiner Kurve, nicht Mitternacht.
2. Kündige es an, mit einem Countdown im Chat, und halte es kurz.
3. Starte aus einem Grund neu. Updates, ein Speicherleck, dem du nachgehst, eine Config-Änderung, die es braucht. Ein täglicher Neustart, der nichts behebt, kostet trotzdem jeden Tag einen Kick.
4. Finde das Leck, statt es zu verstecken. Wächst der Speicher bis zum Neustart, zeigt /spark heapsummary, was ihn füllt.

Neustarts beheben keinen Tick-Lag. Eine Farm, die 30 ms pro Tick kostet, kostet fünf Minuten nach einem Neustart auch 30 ms pro Tick. Unser Uptime-Bericht hat die vollständigen Ausfallzahlen über die ganze Liste.

Wann du Hardware aufrüsten solltest

Rüste auf, wenn das Profil es sagt. Die Anzeichen:

• MSPT zur Stoßzeit bleibt über etwa 40 ms, nachdem du dich um die obigen Verdächtigen gekümmert hast.
• Das Profil zeigt Zeit, die über gewöhnliche Vanilla-Arbeit verteilt ist (Entities, Chunks, Block-Updates), ohne dass ein einzelner Übeltäter übrig bleibt.
• Auf einem VPS zeigt top, dass CPU-Steal (der Wert st) zu den Stoßzeiten steigt, was bedeutet, dass deine Nachbarn Kerne nutzen, für die du zahlst.

Kaufe dann zuerst Single-Core-Geschwindigkeit, denn die Tick-Schleife läuft auf einem Kern. Mehr RAM behebt nur Speicherprobleme. Darüber hinaus lautet die Antwort, die Last aufzuteilen: mehrere Server hinter einem Velocity-Proxy oder Folia für eine sehr große Welt, beides in unserem Ratgeber zur Server-Software behandelt. In Hosting wählen stehen die Fragen, die du stellen solltest, bevor du für die neue Maschine zahlst.