Warum die TPS deines Minecraft Servers einbrechen

Die Minecraft Server TPS ist der wichtigste Indikator dafür, ob dein Server flüssig läuft oder anfängt zu ruckeln. Viele Betreiber schauen nur auf die RAM-Auslastung, dabei liegt die eigentliche Ursache für Lags fast immer woanders: bei der Single-Core-Leistung der CPU, der gewählten Server-Software oder einer schlecht konfigurierten World. Dieser Artikel zeigt, wie du TPS-Probleme systematisch diagnostizierst.

Was bedeutet Minecraft Server TPS eigentlich?

TPS steht für „Ticks per Second". Ein Minecraft Server rechnet standardmäßig 20 Ticks pro Sekunde – jeder Tick verarbeitet Blockupdates, Redstone, Entity-Bewegungen, Chunk-Ladevorgänge und Plugin-Logik. Sinkt die Minecraft Server TPS unter 20, dauert jeder Tick länger als 50 Millisekunden, und das Spiel wird spürbar langsamer: Mobs bewegen sich ruckartig, Redstone-Uhren desynchronisieren, Tränke wirken verzögert.

Ein stabiler Wert liegt zwischen 19,5 und 20,0. Ab 18 beginnen erste Spieler es zu bemerken, unter 15 wird der Server praktisch unspielbar. Die TPS ist damit ein Symptom, keine Ursache – sie zeigt an, dass irgendein Prozess auf dem Server länger braucht, als er darf.

Wer die genaue Konfiguration eines Minecraft Server mieten möchte, sollte vorher wissen, welche Hardware-Faktoren die TPS überhaupt beeinflussen – genau darum geht es in den folgenden Abschnitten.

Single-Core-Leistung: der unterschätzte Flaschenhals

Minecraft-Server-Software – egal ob Vanilla, Paper, Purpur oder Forge – verarbeitet die Haupt-Tick-Schleife auf einem einzigen CPU-Kern. Mods und Plugins können zwar teilweise asynchrone Aufgaben auslagern, aber der World-Tick selbst bleibt single-threaded. Das bedeutet: Ein Prozessor mit acht Kernen bei niedriger Taktrate bringt hier weniger als ein Prozessor mit hoher Taktfrequenz pro Kern.

Warum Taktfrequenz wichtiger ist als Kernanzahl

Ryzen-Prozessoren mit hoher Basis- und Boost-Taktrate reduzieren die Zeit pro Tick spürbar, weil sie Berechnungen wie Pathfinding, Chunk-Generierung und Entity-Kollisionen schneller abarbeiten. Bei vielen gleichzeitig aktiven Redstone-Schaltungen oder großen Farmen mit hoher Entity-Dichte macht sich das direkt in der TPS-Kurve bemerkbar.

Typische Belastungsquellen für einen Kern

• Große Zucht- oder Mob-Farmen mit vielen gleichzeitigen Entities
• Redstone-Computer mit hoher Update-Frequenz
• Nicht optimierte Plugins, die synchron auf der Haupt-Thread-Schleife rechnen
• Viele gleichzeitig geladene Chunks durch weit verstreute Spielerbasen

Ein NVMe-Speicher hilft zusätzlich, weil Chunk-Speichern und -Laden auf SSDs mit klassischer Rotationstechnik deutlich langsamer abläuft und in Extremfällen ebenfalls die Tick-Dauer verlängert.

RAM-Bedarf je nach Server-Software

Der Arbeitsspeicher entscheidet nicht direkt über die TPS, aber ein zu knapp bemessener RAM führt zu häufigen Garbage-Collection-Pausen der Java Virtual Machine – und genau diese Pausen erzeugen die sichtbaren Ruckler, die viele fälschlich der CPU zuschreiben.

Vergleich der typischen Anforderungen

Software	Empfohlener RAM (10–20 Spieler)	Besonderheit
Vanilla / Paper	4–6 GB	Geringster Overhead, gute Basis
Purpur / Spigot mit Plugins	6–8 GB	Zusätzlicher Verbrauch durch Plugin-Logik
Forge / NeoForge mit Modpacks	8–12 GB	Mods laden zusätzliche Klassen und Entities
Fabric mit vielen Performance-Mods	6–10 GB	Abhängig von aktiven Optimierungs-Mods

Zu viel zugewiesener RAM ist ebenfalls kontraproduktiv: Größere Heaps verlängern die Dauer einzelner Garbage-Collection-Zyklen. Wichtiger als „mehr RAM" ist die passende Java-Flag-Konfiguration.

Sinnvolle JVM-Startparameter

java -Xms6G -Xmx6G -XX:+UseG1GC -XX:MaxGCPauseMillis=130 \
-XX:+ParallelRefProcEnabled -XX:+DisableExplicitGC \
-jar paper-1.21.jar nogui

Feste Mindest- und Maximalwerte (-Xms = -Xmx) verhindern, dass die JVM den Heap zur Laufzeit vergrößert, was ebenfalls kurze Ruckler auslösen kann.

Ruckler systematisch diagnostizieren

Bevor du irgendetwas änderst, brauchst du Daten. Rate-basierte Optimierung führt selten zum Ziel.

Schritt 1: TPS und MSPT im Blick behalten

/tps
/forge tps
/mspt

MSPT (Milliseconds per Tick) ist präziser als TPS, weil TPS erst bei starker Überlastung sichtbar abfällt, während MSPT jede kleine Verzögerung sofort anzeigt. Werte über 50 ms pro Tick sind das erste Warnsignal.

Schritt 2: Profiling mit spark

/plugman load spark
/spark profiler start
/spark profiler stop --save

Der spark-Profiler zeigt, welche Plugins, Mods oder Vanilla-Prozesse die meiste Zeit pro Tick beanspruchen. In den meisten Fällen entpuppen sich ein oder zwei Plugins als Hauptverursacher, nicht die Server-Hardware selbst.

Schritt 3: Timings-Report auswerten

/timings on
# nach 10-15 Minuten Normalbetrieb
/timings paste

Der generierte Link listet jede Funktion nach CPU-Zeit auf. Achte besonders auf „Entity Ticking" und „Tile Entity Ticking" – hier verstecken sich oft überladene Zuchtfarmen oder ineffiziente Redstone-Konstruktionen.

Checkliste für die Praxis

• View-Distance und Simulation-Distance in server.properties reduzieren
• Entity-Cramming und Mob-Caps über Plugins wie ClearLagg limitieren
• Regelmäßige Neustarts per systemctl restart minecraft.service planen, um Memory-Fragmentierung zu vermeiden
• Automatische Sauvegarden vor größeren Konfigurationsänderungen anlegen, um im Fehlerfall schnell zurückzukehren

Über ein Pterodactyl-Panel lassen sich Live-Konsole, Ressourcenverbrauch und Dateizugriff zentral einsehen – praktisch, um TPS-Einbrüche mit CPU- oder RAM-Spitzen in Echtzeit zu korrelieren. Wer eigene Panel-Instanzen betreiben möchte, findet dazu passende Pterodactyl VPS-Umgebungen. Einen Überblick über alle unterstützten Titel bietet zudem die Übersicht der Alle unsere Gameserver.

Fazit

Eine niedrige Minecraft Server TPS ist selten Zufall: Meist steckt eine Kombination aus Single-Core-Last, ungünstiger RAM-Konfiguration oder ressourcenintensiven Plugins dahinter. Mit TPS-Befehlen, spark-Profiling und Timings-Reports lässt sich die Ursache gezielt eingrenzen, statt blind an Einstellungen zu drehen.

FAQ

Wie oft sollte ich die TPS meines Servers überprüfen?

Ein Blick per /tps nach jedem größeren Update, neuen Plugin oder Spieleransturm reicht meist aus. Bei dauerhaft aktiven Farmen lohnt sich eine wöchentliche Kontrolle mit spark, um schleichende Verschlechterungen früh zu erkennen.

Warum sinkt die TPS trotz niedriger RAM-Auslastung?

Das deutet meist auf CPU-seitige Last hin, etwa durch zu viele Entities, komplexe Redstone-Schaltungen oder ineffiziente Plugin-Berechnungen im Haupt-Thread. Ein Timings-Report zeigt schnell, welcher Prozess die Ticks verlängert.

Hilft mehr RAM automatisch gegen Lags?

Nicht zwangsläufig. Zu wenig RAM verursacht Garbage-Collection-Pausen, aber übermäßig viel zugewiesener Speicher kann diese Pausen sogar verlängern. Entscheidend sind passende JVM-Flags und eine dem Modpack angemessene Speichergröße.