Minecraft Server TPS verstehen und Lag vermeiden

Minecraft Server TPS sind der zuverlässigste Indikator dafür, ob dein Survival- oder Modded-Server flüssig läuft oder unter der Last von Redstone, Mobs und Chunks einknickt. Sinkt der Wert dauerhaft unter 20, spüren Spieler Rubberbanding, verzögerte Block-Updates und hakende Kämpfe. Dieser Artikel zeigt, welche Ursachen hinter TPS-Einbrüchen stecken und wie Single-Core-Leistung, RAM-Zuweisung und View-Distance zusammenspielen.

Was TPS auf einem Minecraft Server wirklich bedeutet

TPS steht für Ticks pro Sekunde. Die Minecraft-Engine rechnet im Idealfall 20 Ticks pro Sekunde, jeder Tick dauert also 50 Millisekunden. In diesem Zeitfenster muss der Server alle Mobs bewegen, Redstone-Schaltungen berechnen, Chunks laden, Kollisionen prüfen und die Welt an jeden verbundenen Client senden. Dauert ein Tick länger als 50 ms, verschiebt sich die Spielzeit – die TPS fallen unter 20, und das Spielgefühl wird träge, selbst wenn die Netzwerklatenz einwandfrei ist.

Wichtig für die Diagnose: TPS-Werte sind ein Symptom, keine Ursache. Ein Wert von 15 TPS sagt dir, dass irgendetwas zu lange rechnet – aber nicht was. Genau hier verzettelt sich die Fehlersuche oft, wenn Admins pauschal mehr Arbeitsspeicher zuweisen, ohne die eigentliche Engpassquelle zu identifizieren.

Wer einen Minecraft Server mieten möchte und dabei auf Ryzen-CPUs mit hoher Taktfrequenz setzt, schafft von Anfang an die technische Grundlage, um TPS-Einbrüche gar nicht erst entstehen zu lassen – denn genau diese Komponente entscheidet über die Tick-Berechnung, wie der nächste Abschnitt zeigt.

Single-Core-Leistung: der größte Hebel für stabile Minecraft Server TPS

Die Haupt-Tick-Schleife von Minecraft läuft auf einem einzigen CPU-Thread. Mob-KI, Weltgenerierung im Hintergrund, Redstone-Updates und Entity-Kollisionen werden sequenziell abgearbeitet – auch wenn der Prozessor zwölf Kerne hat, nutzt die Kernlogik davon faktisch nur einen. Zusatzthreads kümmern sich um Netzwerkpakete, Chunk-I/O oder bei Paper-Forks um ausgelagerte Teilaufgaben, aber der entscheidende Flaschenhals bleibt die Geschwindigkeit eines einzelnen Kerns.

Warum Mehrkern-CPUs kaum helfen

Ein Prozessor mit vielen Kernen, aber niedriger Taktrate pro Kern, bringt für Minecraft Server TPS wenig. Entscheidend ist die Single-Thread-Performance, also wie viele Instruktionen ein Kern pro Sekunde abarbeitet. Das erklärt, warum zwei Maschinen mit identischer Kernanzahl völlig unterschiedliche TPS-Werte liefern können, sobald viele Spieler, Farmen oder Redstone-Uhren gleichzeitig aktiv sind.

Woran du Single-Core-Engpässe erkennst

Nutze das eingebaute Debug-Kommando oder ein Profiling-Plugin, um die Tick-Dauer sichtbar zu machen:

/forge tps
/timings report
/spark profiler --timeout 60

Ein Spark-Report zeigt konkret, welche Plugins, Mods oder Entities die meiste Zeit pro Tick verbrauchen. Häufige Übeltäter sind:

• Große Mob-Farmen mit hoher Entity-Dichte
• Komplexe Redstone-Schaltungen mit kurzen Taktintervallen
• Schlecht optimierte Plugins mit synchronen Datenbankabfragen
• Zu viele geladene Chunks durch Spieler, die weit auseinander unterwegs sind

Liegt die Ursache tatsächlich bei der Rechenleistung des Kerns, hilft kein zusätzlicher Arbeitsspeicher – nur eine schnellere Einzelkern-Performance oder eine Reduzierung der Tick-Last bringt messbare Besserung.

RAM-Zuweisung richtig konfigurieren

Arbeitsspeicher beeinflusst die TPS nur indirekt: zu wenig RAM führt zu häufigen Garbage-Collection-Pausen, die den Tick blockieren. Zu viel zugewiesener RAM kann paradoxerweise ebenfalls schaden, weil die JVM größere Heap-Bereiche verwaltet und die GC-Pausen länger statt kürzer werden.

Warum mehr RAM nicht automatisch mehr TPS bedeutet

Eine verbreitete Fehlannahme: 16 GB zugewiesen sind besser als 8 GB. In der Praxis braucht ein Vanilla-Server mit 20 Spielern selten mehr als 4–6 GB. Modpacks mit vielen Entities, Chunk-Loadern oder technischen Mods benötigen mehr, aber die Grenze liegt meist bei 8–12 GB, bevor Garbage Collection zum limitierenden Faktor statt zur Lösung wird.

Server-Typ	Spieleranzahl	Empfohlener RAM
Vanilla / leicht moddiert	bis 15	4–6 GB
Paper mit Plugins	15–40	6–8 GB
Modpack (mittel)	10–25	8–10 GB
Modpack (schwer, z. B. tech-heavy)	10–20	10–14 GB

Aikar's Flags als Startparameter

Für Paper, Purpur oder Spigot haben sich spezielle JVM-Flags etabliert, die Garbage-Collection-Pausen reduzieren und damit TPS-Einbrüche abfedern:

java -Xms8G -Xmx8G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
-XX:+DisableExplicitGC -XX:G1NewSizePercent=30 \
-XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M \
-jar paper.jar nogui

Wichtig: -Xms und -Xmx auf denselben Wert setzen verhindert, dass die JVM den Heap während des Betriebs dynamisch vergrößert – das vermeidet zusätzliche Mikro-Ruckler genau in dem Moment, in dem viele Spieler online sind.

View-Distance und Simulation-Distance als TPS-Killer

Jeder geladene Chunk kostet Rechenzeit: Entity-Ticking, Blockaktualisierungen, Lichtberechnung. Eine hohe View-Distance wirkt grafisch angenehm, treibt aber die Zahl gleichzeitig aktiver Chunks pro Spieler massiv nach oben. Bei zehn Spielern und view-distance 12 verwaltet der Server potenziell hunderte zusätzliche Chunks gegenüber view-distance 8.

Die relevanten Werte in server.properties

view-distance=8
simulation-distance=6
max-tick-time=60000
entity-broadcast-range-percentage=80

Seit den neueren Versionen trennt Minecraft View-Distance (sichtbare Chunks) von Simulation-Distance (Chunks, in denen Mobs und Redstone tatsächlich berechnet werden). Die Simulation-Distance zu senken bringt oft mehr TPS-Gewinn als die View-Distance, weil genau hier die Tick-Last entsteht – die Sichtweite bleibt für Spieler subjektiv kaum spürbar reduziert.

Weitere praxisnahe Stellschrauben

• Paper- oder Purpur-Build statt Vanilla für feingranulare Performance-Einstellungen nutzen
• Entity-Cramming und Mob-Caps in der paper-world-defaults.yml begrenzen
• Hopper-Timer verlangsamen, wenn viele Sortiersysteme parallel laufen
• Regelmäßig mit Spark oder Timings prüfen, bevor die Spielerzahl wächst
• Pre-Generate der Welt, damit Chunk-Generierung nicht live während hoher Spielerlast passiert

Über ein Pterodactyl VPS lässt sich die Live-Konsole direkt im Panel beobachten, während du view-distance oder simulation-distance schrittweise anpasst – so siehst du den TPS-Effekt sofort, ohne ständig per SSH neu zu verbinden. Einen Überblick über weitere unterstützte Titel findest du unter Alle unsere Gameserver.

Stabile Minecraft Server TPS entstehen selten durch eine einzelne Maßnahme, sondern durch das Zusammenspiel aus ausreichender Single-Core-Leistung, sinnvoll dimensioniertem RAM und einer realistisch gewählten View- und Simulation-Distance. Wer diese drei Stellschrauben regelmäßig überprüft, verhindert die meisten Tick-Einbrüche, bevor Spieler sie überhaupt bemerken.

FAQ

Wie oft sollte ich die TPS meines Minecraft Servers prüfen?

Am besten regelmäßig per /forge tps oder Spark, besonders vor und nach größeren Spieler-Events, Updates oder dem Hinzufügen neuer Plugins/Mods. So erkennst du Trends, bevor TPS-Einbrüche dauerhaft werden.

Hilft mehr RAM immer gegen TPS-Einbrüche?

Nein. Mehr RAM hilft nur, wenn die Ursache Garbage-Collection-Pausen sind. Liegt der Engpass bei Single-Core-Rechenlast durch Redstone, Mobs oder Plugins, bringt zusätzlicher Arbeitsspeicher keine messbare Verbesserung.

Welcher view-distance-Wert ist für kleine Communities sinnvoll?

Für 10–20 Spieler funktioniert view-distance 8 bis 10 mit simulation-distance 6 in der Regel gut und hält die Tick-Last überschaubar, ohne die Sichtweite spürbar einzuschränken.