Minecraft Server TPS verstehen und Lag gezielt beseitigen

Die Minecraft Server TPS entscheiden darüber, ob sich eine Welt flüssig anfühlt oder ob Spieler bei jedem Rechtsklick eine Sekunde warten müssen. Wer regelmäßig Lag-Spitzen beobachtet, kennt das Problem: Die Tick-Rate sinkt, Redstone-Schaltungen stottern, Mobs bleiben mitten in der Bewegung stehen. In diesem Artikel schauen wir uns an, wie sich TPS zusammensetzen, welche Faktoren sie senken und wie Lag durch Chunk-Optimierung, Single-Core-Leistung und eine durchdachte RAM-Zuweisung reduziert werden kann.

Wie setzen sich die Minecraft Server TPS zusammen?

Minecraft arbeitet in Ticks. Ein Tick ist eine einzelne Berechnungsrunde, in der die Spiel-Engine Physik, Entitäten, Redstone, Wetter und Weltgenerierung aktualisiert. Der Zielwert liegt bei 20 Ticks pro Sekunde, also einem Tick alle 50 Millisekunden. Solange jeder Tick innerhalb dieses Zeitfensters abgeschlossen wird, laufen die Minecraft Server TPS konstant bei 20. Braucht ein Tick länger, verschiebt sich alles nach hinten: Bewegungen wirken ruckelig, Tränke wirken verzögert, und Redstone-Timings verschieben sich messbar.

Die Tick-Zeit setzt sich aus mehreren Blöcken zusammen, die sequenziell abgearbeitet werden:

• Entity-Updates (Mobs, Spieler, Projektile, Fallobjekte)
• Block-Updates und Redstone-Berechnungen
• Chunk-Loading und Weltgenerierung an den Rändern des simulierten Bereichs
• Netzwerkkommunikation mit den verbundenen Clients
• Plugin- oder Mod-Hooks, die sich in den Tick-Zyklus einhängen

Fällt einer dieser Blöcke aus dem Zeitbudget, sinkt die Tick-Rate für die gesamte Welt gleichzeitig, nicht nur lokal für einen Spieler. Das unterscheidet TPS-Probleme von reiner Netzwerklatenz: Ein hoher Ping betrifft einen einzelnen Client, ein TPS-Einbruch betrifft jeden.

Wer eine eigene Minecraft-Welt betreiben möchte, findet die passende Grundlage auf der Seite Minecraft Server mieten, inklusive Ryzen-CPU und NVMe-Speicher, die für stabile Tick-Zeiten von Vorteil sind.

Häufige Ursachen für sinkende TPS und Lag

Chunk-Loading als größter Einzelfaktor

Jeder geladene Chunk kostet Rechenzeit, unabhängig davon, ob ein Spieler ihn gerade sieht. Farmen mit vielen Entitäten, aktive Redstone-Uhren in unbesuchten Bereichen oder Spawn-Chunks, die permanent geladen bleiben, summieren sich schnell zu einer messbaren Last. Ein Server mit vielen aktiven Basen über eine große Fläche verteilt lädt deutlich mehr Chunks gleichzeitig als eine kompakte Spielerbasis.

Typische Chunk-Fresser

• Automatische Mob-Farmen mit hoher Spawnrate
• Ungenutzte Portal-Netze, die Chunks künstlich am Laden halten
• Zu große view-distance in der server.properties
• Item-Ansammlungen auf dem Boden (Hopper-Systeme ohne Filter)

Ein pragmatischer erster Schritt ist die Reduktion der Sichtweite und der Simulationsdistanz:

view-distance=8
simulation-distance=6

Diese beiden Werte in der server.properties senken direkt die Anzahl der aktiv simulierten Chunks pro Spieler und wirken sich messbar auf die Minecraft Server TPS aus, besonders bei mehr als zehn gleichzeitig aktiven Spielern.

Entities, Redstone und Plugin-Overhead

Nicht nur Chunks selbst, sondern auch die Anzahl der Entitäten pro Chunk treibt die Tick-Zeit hoch. Ein Zoo mit hunderten Tieren, ein Item-Stapel-Chaos oder eine schlecht optimierte Redstone-Rechenmaschine belasten den Server dauerhaft. Auf Servern mit Plugins (Paper, Spigot) oder Mods (Forge, NeoForge) kommt zusätzlicher Overhead hinzu, wenn Plugins bei jedem Tick eigene Logik ausführen, etwa Wirtschaftssysteme, die pro Tick Datenbankabfragen auslösen.

Ein Profiling-Tool wie Spark hilft, den Verursacher konkret zu identifizieren, statt zu raten:

/spark profiler --timeout 60
/spark profiler --stop

Der Report zeigt an, welcher Plugin-Hook, welche Mob-KI oder welcher Weltgenerator die meiste Tick-Zeit verbraucht. Damit lässt sich gezielt optimieren, statt Plugins wahllos zu deaktivieren.

Ursache	Wirkung auf TPS	Gegenmaßnahme
Hohe view-distance	Mehr Chunks pro Tick	view-distance und simulation-distance senken
Mob-Farmen ohne Cap	Entity-Update-Zeit steigt	mob-spawn-range begrenzen, Farmen entkoppeln
Redstone-Dauerlast	Block-Update-Warteschlange wächst	Uhren mit Comparator statt Repeater-Loop bauen
Plugin-Datenbankzugriffe pro Tick	Main-Thread blockiert	Async-Zugriffe oder Caching im Plugin nutzen

Single-Core-Leistung: der eigentliche Flaschenhals

Die Minecraft-Engine läuft für den Haupt-Tick-Loop überwiegend auf einem einzigen CPU-Kern. Zwar entlasten moderne Paper-Versionen einige Aufgaben wie Chunk-Generierung auf zusätzliche Threads, doch der kritische Pfad – Entity-Ticking, Redstone, Netzwerklogik – bleibt weitgehend Single-Thread-gebunden. Das bedeutet konkret: Ein Prozessor mit vielen Kernen, aber niedriger Taktfrequenz pro Kern, bringt für die Tick-Rate weniger als ein Prozessor mit hoher Einzelkern-Leistung.

Warum Taktfrequenz wichtiger ist als Kernanzahl

Ryzen-CPUs mit hohem Boost-Takt sind für Minecraft-Welten deshalb günstiger positioniert als reine Kernanzahl-Monster, weil der Haupt-Tick nicht parallelisierbar ist. Wer merkt, dass die TPS trotz wenig Spielern und moderater Weltgröße dauerhaft unter 18 liegen, sollte die tatsächliche Einzelkern-Auslastung prüfen, bevor mehr RAM zugewiesen wird – das ist ein klassischer Fehlschluss.

top -H -p $(pgrep -f server.jar)

Dieser Befehl zeigt auf einem Linux-System die Thread-Auslastung des Java-Prozesses. Läuft ein einzelner Thread konstant nahe 100 %, während andere Kerne kaum belastet sind, bestätigt das die Single-Core-Bindung des Tick-Loops.

NVMe-Speicher und I/O-Wartezeiten

Neben der CPU spielt der Speicherzugriff eine Rolle bei Chunk-Laden und Weltspeicherung. Klassische Festplatten oder überlastete Netzwerkspeicher erzeugen I/O-Wartezeiten, die sich als kurze TPS-Einbrüche beim automatischen Speichern zeigen. NVMe-SSDs reduzieren diese Wartezeit deutlich, da Lese- und Schreibzugriffe auf Regionsdateien nahezu verzögerungsfrei erfolgen.

RAM-Zuweisung richtig konfigurieren

Ein verbreiteter Irrtum lautet: mehr RAM gleich mehr TPS. Tatsächlich verbessert überschüssiger Arbeitsspeicher die Tick-Rate nicht automatisch – zu viel zugewiesener Heap kann sie sogar verschlechtern, weil die Java Virtual Machine bei größeren Heaps längere Garbage-Collection-Pausen durchführt. Diese Pausen frieren den gesamten Server kurz ein und erzeugen sichtbare Lag-Spitzen, unabhängig von Chunk-Zahl oder Plugin-Last.

Sinnvolle Heap-Größe statt Maximalwert

Für die meisten Survival-Welten mit Plugins liegt eine sinnvolle Heap-Größe zwischen 4 und 8 GB, abhängig von Weltgröße und Spielerzahl. Ein Startskript mit den Aikar-Flags optimiert die Garbage-Collection gezielt für Minecraft-Workloads:

java -Xms4G -Xmx4G \
-XX:+UseG1GC \
-XX:+ParallelRefProcEnabled \
-XX:MaxGCPauseMillis=200 \
-XX:+UnlockExperimentalVMOptions \
-XX:+DisableExplicitGC \
-XX:G1NewSizePercent=30 \
-XX:G1MaxNewSizePercent=40 \
-XX:G1HeapRegionSize=8M \
-jar server.jar nogui

Wichtig ist, -Xms und -Xmx auf denselben Wert zu setzen. Ein dynamisch wachsender Heap erzeugt zusätzliche Pausen, wenn die JVM zur Laufzeit Speicher nachfordert – genau in dem Moment, in dem die Tick-Rate am empfindlichsten reagiert.

RAM-Monitoring im laufenden Betrieb

Über die Konsole lässt sich der aktuelle Speicherverbrauch direkt abfragen:

/tps
/gc

Zeigt /gc regelmäßig hohe Pausenzeiten, ist meist die Heap-Konfiguration statt der absoluten RAM-Menge das eigentliche Problem. Wer den Server über ein Panel wie Pterodactyl verwaltet, kann Speicherlimits und JVM-Flags direkt in der Startzeile der Server-Konfiguration hinterlegen, ohne die Konsole manuell neu zu starten. Wer eigene Infrastruktur betreibt, findet passende Grundlagen unter Pterodactyl VPS oder in der Übersicht Alle unsere Gameserver.

Offizielle Details zu Spielmechanik und Tick-Verhalten liefert das Source.

Stabile Minecraft Server TPS entstehen aus dem Zusammenspiel von Chunk-Management, Einzelkern-Leistung und einer durchdacht konfigurierten Heap-Größe. Wer Chunks begrenzt, den Tick-Loop mit Profiling-Tools beobachtet und die JVM-Flags sinnvoll setzt, reduziert Lag nachhaltig, statt nur Symptome zu bekämpfen.

FAQ

Wie prüfe ich die aktuelle Tick-Rate meines Servers?

Der Befehl /tps in der Konsole zeigt die durchschnittliche Tick-Rate der letzten Minuten. Werte konstant unter 19 deuten auf eine bestehende Belastung hin, die genauer analysiert werden sollte, etwa mit einem Profiling-Tool wie Spark.

Hilft mehr Arbeitsspeicher automatisch gegen Lag?

Nein. Zu viel zugewiesener Heap kann die Garbage-Collection-Pausen verlängern und dadurch neue Lag-Spitzen erzeugen. Entscheidend ist eine passende Heap-Größe mit stabilen JVM-Flags, nicht die maximale RAM-Menge.

Warum sinkt die Tick-Rate trotz wenig Spielern?

Meist liegt es an vielen geladenen Chunks, aktiven Mob-Farmen oder Plugin-Logik, die bei jedem Tick ausgeführt wird. Da der Haupt-Tick-Loop überwiegend auf einem Kern läuft, reicht schon ein einzelner rechenintensiver Prozess, um die TPS unabhängig von der Spielerzahl zu senken.