Minecraft Server TPS verstehen: Warum die Serverleistung einbricht und wie du Lag beseitigst

Die Minecraft Server TPS geben an, wie viele der 20 geplanten Ticks pro Sekunde deine Welt tatsächlich abarbeitet. Fällt der Wert unter 20, ruckeln Mobs, Redstone-Schaltungen reagieren verzögert und platzierte Blöcke springen zurück. Die Ursache liegt fast nie beim Netzwerk, sondern bei einer überlasteten Rechenschleife. Wo sie hängt, lässt sich präzise messen und in den meisten Fällen dauerhaft beheben.

Wie die Minecraft Server TPS zustande kommen

Der Server arbeitet in festen Zeitscheiben. Zwanzig Mal pro Sekunde durchläuft er eine Schleife, in der er Entities bewegt, Redstone auswertet, Blöcke aktualisiert, Chunks lädt und Pakete an die Clients schickt. Jeder dieser Ticks hat ein Budget von 50 Millisekunden.

Braucht ein Tick weniger als 50 ms, wartet der Server den Rest der Zeit ab und meldet stabile 20 TPS. Braucht er länger, verschiebt sich alles nach hinten und die Tickrate sinkt. Der entscheidende Messwert ist deshalb nicht die TPS-Zahl selbst, sondern MSPT: die tatsächlich verbrauchten Millisekunden pro Tick.

MSPT	Resultierende TPS	Was Spieler wahrnehmen
unter 30 ms	20	keine spürbare Verzögerung, Reserve vorhanden
30 bis 49 ms	20	läuft sauber, aber ohne Puffer für Spitzen
50 bis 80 ms	etwa 12 bis 19	Mobs stottern, Hopper werden langsam
über 100 ms	unter 10	Blockplatzierung springt zurück, Kämpfe unspielbar

Wichtig ist die Trennung von TPS und Ping. Ein Ping von 120 ms bei 20 TPS ist ein Netzwerkthema (Route, Distanz, WLAN). 8 TPS bei 15 ms Ping ist ein Rechenproblem auf der Serverseite. Beide fühlen sich für Spieler ähnlich an, haben aber völlig verschiedene Lösungswege.

Warum Single-Core-Leistung und RAM-Zuweisung den Tick-Takt bestimmen

Die Tick-Schleife läuft weitgehend auf einem einzigen Kern. Ein Prozessor mit 32 Threads hilft dir daher wenig, wenn jeder einzelne Thread langsam ist. Wer beim Minecraft Server mieten auf Hardware wie den Ryzen 9 7950X3D mit DDR5 ECC und NVMe-Speicher setzt, bekommt pro Tick schlicht mehr Zeitbudget. Alles Weitere ist Konfigurationsarbeit.

Nebenläufige Aufgaben wie Chunk-Generierung, Weltspeicherung und Netzwerkkompression verteilen moderne Server-Forks auf zusätzliche Threads. Die Kernlogik bleibt seriell. Deshalb bringt ein zweiter Kern Entlastung bei Pregeneration und Autosave, verschiebt aber nicht die Grenze bei Redstone oder Entity-Berechnung.

RAM: mehr ist nicht automatisch besser

Eine zu große Heap-Zuweisung verlängert die Pausen der Garbage Collection. Statt gleichmäßiger Ticks bekommst du dann alle paar Minuten einen Einbruch von mehreren hundert Millisekunden. Setze -Xms und -Xmx auf denselben Wert und orientiere dich am realen Bedarf: eine Vanilla-Welt mit 20 Spielern kommt oft mit 4 bis 6 GB aus, ein großes Modpack braucht 8 GB oder mehr.

java -Xms6G -Xmx6G \
  -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 \
  -XX:InitiatingHeapOccupancyPercent=15 \
  -jar paper.jar nogui

Diese Flags sind der etablierte Standard für G1GC bei Java 17 und neuer. Sie verhindern keine Überlast, sie glätten nur die Speicherverwaltung. Wenn die TPS dauerhaft unter 15 liegen, findest du die Ursache nicht im Heap, sondern in der Welt. Eine Übersicht der Serverarten für weitere Spiele zeigt Alle unsere Gameserver.

Lag messen statt raten: spark, MSPT und Tick-Reports

Ohne Messung drehst du an zufälligen Stellschrauben. Auf Paper und den darauf aufbauenden Forks liefern zwei Befehle sofort ein Bild der Lage:

/tps
/mspt

/tps zeigt die Durchschnittswerte der letzten 1, 5 und 15 Minuten. /mspt gibt die Tickdauer als Median und im 95. Perzentil aus. Ein guter Median bei schlechten Perzentilwerten bedeutet: der Server läuft grundsätzlich sauber, wird aber regelmäßig von einzelnen Spitzen getroffen, etwa durch Autosave oder eine geplante Plugin-Aufgabe.

Ein Profil mit spark aufzeichnen

Der Profiler spark hat die früheren Timings-Reports abgelöst und ist in vielen aktuellen Builds bereits enthalten. Er sampelt den Server-Thread und zeigt, welche Methode wie viel Tick-Zeit belegt.

/spark profiler start --timeout 300
/spark profiler stop
/spark tps
/spark health --memory

Zeichne immer dann auf, wenn das Problem auftritt, nicht nachts bei drei Spielern. Im fertigen Report gehst du von oben nach unten durch den Aufrufbaum und suchst den ersten Eintrag, der nicht zum Vanilla-Kern gehört. Details zu den Parametern stehen in der offiziellen Paper-Dokumentation.

Tick-Fresser in der Welt: Redstone, Mob-Farmen und Chunk-Ladeverhalten

Redstone-Uhren und Hopper-Ketten

Eine einzelne schnelle Redstone-Uhr aktualisiert Blöcke in jedem Tick und zieht auf Dauer mehr Rechenzeit als zehn Spieler beim Bauen. Hopper sind noch teurer: jeder Hopper prüft mehrfach pro Sekunde seinen Inhalt und den Block darüber. Eine Sortieranlage mit dreihundert Hoppern ist ein klassischer Grund für dauerhaft 15 TPS.

Suche solche Bauten gezielt mit einem Lag-Report oder per Chunk-Analyse, statt pauschal Redstone zu verbieten. Meist reichen zwei oder drei Umbauten: Uhren mit einem Hebel abschaltbar machen, Hopper-Ketten durch Trichterloren oder Wasserströme ersetzen, Item-Zuflüsse begrenzen.

Mob-Farmen und Entity-Zahlen

Entities kosten Tick-Zeit über Pfadfindung, Kollision und KI. Riesige Item-Stapel am Boden, hunderte Tiere in einem Gehege oder eine Iron-Farm im Dauerbetrieb summieren sich schnell. Die Activation-Range in der spigot.yml friert entfernte Mobs ein, ohne sie zu löschen:

entity-activation-range:
  animals: 16
  monsters: 24
  raiders: 48
  misc: 8
  water: 12
  tick-inactive-villagers: false

ticks-per:
  hopper-transfer: 8
  hopper-check: 8

merge-radius:
  item: 3.5
  exp: 4.0

Ergänzend begrenzt spawn-limits in der bukkit.yml die Gesamtzahl an Mobs pro Kategorie. Reduziere in kleinen Schritten und beobachte den MSPT-Median danach mindestens eine Stunde lang, sonst schreibst du eine zufällige Schwankung dem Eingriff zu.

Chunk-Ladeverhalten

Jeder Spieler hält einen Bereich geladener Chunks um sich herum. Zwanzig Spieler, die über die ganze Karte verteilt sind, belasten den Server deutlich stärker als zwanzig Spieler an einem Spawnpunkt. Neu generierte Chunks sind besonders teuer, weil Terrain, Strukturen und Lichtberechnung zusammenkommen.

Setze deshalb eine Weltgrenze und generiere den Bereich innerhalb dieser Grenze im Voraus, zum Beispiel mit Chunky, während niemand online ist. Danach fällt die Generierung im laufenden Betrieb weg und nur noch das Laden von der NVMe bleibt übrig.

Plugins als versteckte Tick-Fresser

Ein Plugin, das jede Sekunde alle geladenen Chunks nach Blöcken durchsucht, ruiniert die Tickrate zuverlässig. Typische Kandidaten sind Schutzsysteme mit Block-Logging, dynamische Karten mit synchronem Rendern und Wirtschafts-Plugins, die für jede Transaktion die Datenbank im Haupt-Thread abfragen.

• Sortiere den spark-Report nach Anteil an der Tick-Zeit und prüfe die drei größten Einträge.
• Deaktiviere ein verdächtiges Plugin einzeln, nicht fünf gleichzeitig, sonst kennst du den Verursacher nicht.
• Stelle Datenbankzugriffe von SQLite auf MySQL um, wenn das Plugin viele Schreibvorgänge erzeugt.
• Halte alle Plugins auf einer Version, die zur Serverversion passt: Kompatibilitätsschichten kosten zusätzliche Zeit.

view-distance und Konfigurationsdateien systematisch nachziehen

Die Sichtweite ist die wirksamste einzelne Stellschraube, weil sie quadratisch wirkt. Von 10 auf 8 Chunks reduziert die Fläche geladener Chunks um rund ein Drittel. In der server.properties trennst du dabei zwei Werte, die oft verwechselt werden.

view-distance=8
simulation-distance=6
max-tick-time=60000
sync-chunk-writes=false
network-compression-threshold=256
entity-broadcast-range-percentage=80

Parameter	Wirkung	Praxiswert
view-distance	wie weit Chunks an den Client gesendet werden	8 bis 10
simulation-distance	wie weit Mobs, Redstone und Pflanzenwachstum ticken	4 bis 6
sync-chunk-writes	blockierendes Schreiben der Chunks	false auf NVMe
entity-broadcast-range-percentage	Reichweite der Entity-Pakete	70 bis 100

Eine niedrige simulation-distance bei hoher view-distance ist der übliche Kompromiss: Spieler sehen weiterhin eine weite Landschaft, aber es tickt nur der nahe Bereich. Auf Paper lässt sich die Sichtweite zusätzlich pro Welt setzen, sodass die Nether-Dimension mit weniger auskommt als die Hauptwelt.

Vorgehen in fünf Schritten

1. MSPT und TPS über eine Stoßzeit hinweg protokollieren.
2. Profil mit spark aufzeichnen und die drei größten Verbraucher notieren.
3. Genau eine Änderung umsetzen (Sichtweite, Plugin, Farm).
4. Server neu starten und mindestens 30 Minuten unter Last beobachten.
5. Ergebnis dokumentieren, dann zur nächsten Änderung übergehen.

Plane außerdem einen automatischen Neustart in einer ruhigen Stunde ein. Er räumt fragmentierten Heap-Speicher auf und beseitigt hängende Entities, ersetzt aber keine Ursachenanalyse. Weitere Anleitungen zur Serveradministration findest du im Nexus Games Blog.

Fazit

Miss zuerst, drehe danach. Wer ohne spark-Profil an Werten schraubt, verschlechtert die Lage meist. Setze simulation-distance auf 6, halte -Xms und -Xmx identisch, generiere die Welt innerhalb einer Grenze vor und räume Hopper-Ketten auf: damit ist der Großteil aller Tick-Einbrüche erledigt. Der häufigste Fehler bleibt das blinde Aufstocken des Arbeitsspeichers, denn die Tick-Schleife hängt an der Rechenleistung eines Kerns, nicht am Heap.

FAQ

Was bedeutet die Konsolenmeldung "Can't keep up! Is the server overloaded?"

Diese Meldung erscheint, wenn ein Tick deutlich länger als 50 Millisekunden gedauert hat und der Server die verlorene Zeit überspringt. Einzelne Meldungen beim Start oder während des Autosave sind normal. Wiederholt sie sich im laufenden Betrieb im Sekundentakt, liegt eine echte Überlast vor: zeichne dann ein Profil auf und prüfe Entity-Zahlen, Redstone-Bauten und geplante Plugin-Aufgaben.

Bringt ein Wechsel von Vanilla oder Spigot auf Paper wirklich