Minecraft Server Performance: Was TPS, RAM und CPU wirklich bedeuten

Die Minecraft Server TPS entscheidet darüber, ob sich eine Welt flüssig anfühlt oder ob Redstone-Schaltungen hängen, Mobs stottern und Spieler beim Bauen Verzögerungen spüren. Wer eine Minecraft-Welt betreibt, sollte verstehen, welche technischen Faktoren die Serverleistung wirklich bestimmen – nicht nur die reine Hardware, sondern auch Software-Konfiguration und Weltgröße.

Was ist die Minecraft Server TPS und wie wird sie gemessen?

TPS steht für „Ticks Per Second". Minecraft berechnet Spielwelt, Physik, Mob-KI und Redstone in festen Zeitschritten, sogenannten Ticks. Der Zielwert liegt bei 20 Ticks pro Sekunde – jeder Tick dauert also idealerweise 50 Millisekunden. Fällt die Minecraft Server TPS unter diesen Wert, verlangsamt sich das komplette Spielgeschehen: Pflanzenwachstum, Tränkebrauen, Mob-Spawns und Redstone-Timer laufen synchron langsamer.

Server-Software wie Paper oder Spigot zeigt die aktuelle TPS direkt über den Konsolenbefehl an:

/tps

Die Ausgabe liefert meist drei Werte für die letzten 1, 5 und 15 Minuten. Ein zweiter, oft aussagekräftigerer Wert ist die MSPT (Milliseconds Per Tick) – sie zeigt an, wie lange ein einzelner Tick tatsächlich braucht:

/mspt

Liegt die MSPT dauerhaft über 50 ms, sinkt die TPS zwangsläufig, weil der Server nicht mehr genug Ticks pro Sekunde schafft. Genau an diesem Punkt lohnt sich ein Blick auf CPU-Auslastung, RAM-Nutzung und geladene Chunks, statt vorschnell die Server-Software zu wechseln.

Wer eine neue Welt mit stabiler Performance aufsetzen will, findet die passende Grundlage über Minecraft Server mieten – als Ausgangspunkt für eigene Tests mit Plugins, Modpacks und unterschiedlichen Konfigurationen.

Single-Core-Leistung als Flaschenhals der Minecraft Server TPS

Minecraft ist im Kern kaum parallelisiert. Der Haupt-Thread berechnet Weltlogik, Redstone, Entities und Chunk-Ticks sequenziell – egal wie viele CPU-Kerne physisch verbaut sind. Das bedeutet: Nicht die Kernanzahl entscheidet über die TPS, sondern die Single-Core-Leistung, also die Taktfrequenz und die IPC (Instructions per Cycle) eines einzelnen Kerns.

Ein Prozessor mit hoher Basis- und Boost-Taktfrequenz, wie er in modernen Ryzen-Architekturen verbaut ist, verarbeitet den Haupt-Thread schneller und hält die Tick-Dauer niedriger. Zusätzliche Kerne helfen zwar bei Nebenaufgaben wie Chunk-Generierung, Netzwerk-I/O oder bestimmten asynchronen Plugin-Funktionen, ersetzen aber nicht die Leistung des einen Kerns, der die Haupt-Tick-Schleife trägt.

Was CPU-Last konkret verursacht

• Große Mengen an Entities (Mobs, Items, Vehikel) auf engem Raum
• Redstone-Schaltungen mit vielen Aktualisierungen pro Tick
• Farmen mit hoher Spawn- oder Wachstumsrate
• Plugins mit ineffizienten, blockierenden Schleifen im Haupt-Thread

Praktische Kontrolle über die Konsole

Der Befehl /timings report (bei Paper-basierten Servern) liefert eine detaillierte Aufschlüsselung, welche Plugins oder Systeme die meiste Zeit pro Tick beanspruchen. Das ist der direkte Weg, um Ursachen für sinkende Minecraft Server TPS zu identifizieren, statt nur Symptome zu behandeln.

RAM-Bedarf je nach Server-Software

Arbeitsspeicher beeinflusst die TPS indirekt, aber deutlich: Ist zu wenig RAM zugewiesen, greift die Java Virtual Machine häufiger zur Garbage Collection – ein Prozess, der kurzzeitig den Haupt-Thread pausiert und Tick-Spitzen (sogenannte „Lag Spikes") verursacht. Der tatsächliche Bedarf unterscheidet sich stark je nach eingesetzter Server-Software.

Server-Software	Typischer RAM-Bedarf	Besonderheit
Vanilla	2–4 GB (kleine Welt)	Keine Plugin-Optimierung, geringste Kontrolle über Performance
Spigot	3–6 GB	Plugin-Unterstützung, moderate Performance-Optimierung
Paper	3–6 GB	Optimierte Chunk- und Entity-Verarbeitung, konfigurierbare Limits
Forge / NeoForge	6–10 GB+	Mods erhöhen RAM-Bedarf stark, abhängig von Modpack-Größe
Fabric	4–8 GB	Leichter als Forge, aber Mod-abhängig

Wichtig ist dabei ein Detail, das oft übersehen wird: zu viel zugewiesener RAM kann ebenso problematisch sein wie zu wenig. Größere Heap-Größen verlängern die Garbage-Collection-Zyklen, was einzelne Ticks länger blockieren kann. Aus diesem Grund empfiehlt sich eine schrittweise Anpassung der Startparameter statt eines pauschalen Maximalwerts:

java -Xms4G -Xmx6G -jar paper.jar nogui

Der Wert für -Xms sollte dem realistischen Grundbedarf entsprechen, -Xmx dem Höchstwert bei Lastspitzen – nicht dem gesamten verfügbaren Arbeitsspeicher der Maschine.

Geladene Chunks als Performance-Faktor

Jeder geladene Chunk (16×16 Blöcke, volle Höhe) muss pro Tick verarbeitet werden: Blockaktualisierungen, Redstone, Pflanzenwachstum, Mob-Spawning und Licht-Berechnungen laufen dort kontinuierlich. Je mehr Chunks gleichzeitig geladen sind, desto mehr Arbeit fällt pro Tick an – unabhängig davon, ob sich Spieler dort aufhalten oder nicht.

View-Distance und Simulation-Distance

In der server.properties lassen sich zwei zentrale Werte direkt steuern:

view-distance=8
simulation-distance=6

Die View-Distance bestimmt, wie viele Chunks an Clients gesendet werden – das betrifft primär Netzwerk und Client-Performance. Die Simulation-Distance hingegen legt fest, wie viele Chunks aktiv Server-seitig simuliert werden, also Mob-KI, Redstone und Wachstum durchlaufen. Ein Server mit vielen gleichzeitigen Spielern in verschiedenen Gebieten summiert schnell hunderte aktiv simulierte Chunks – das drückt direkt auf die TPS.

Chunk-bezogene Optimierungsansätze

• Simulation-Distance reduzieren, wenn viele Spieler weit verteilt bauen
• Ungenutzte, weit entfernte Farmen oder Außenposten per Plugin entladen lassen
• Entity-Limits pro Chunk über Paper-Konfiguration begrenzen
• Automatische Weltbereinigung (Pregeneration statt Live-Generierung) nutzen

Paper-basierte Server bieten in paper-world-defaults.yml feingranulare Einstellungen, etwa für maximale Entity-Aktivierungsbereiche oder Mob-Spawn-Limits pro Chunk. Diese Stellschrauben wirken oft stärker auf die TPS als reine Hardware-Upgrades, weil sie die Menge an Berechnungen pro Tick direkt reduzieren.

Wer regelmäßig Modpacks, Plugins oder Weltgrößen testet, sollte vor größeren Änderungen immer eine Sicherung anlegen. Automatische Backups über das Panel schützen dabei zuverlässig vor fehlerhaften Konfigurationen oder inkompatiblen Plugin-Versionen. Weitere unterstützte Titel und technische Hintergründe finden sich im Fly-Serv Blog, ebenso wie eine Übersicht unter Alle unsere Gameserver.

Für tiefergehende technische Details zu Server-Ticks und Spielmechanik lohnt sich ein Blick in die offizielle Dokumentation: Source.

Die Minecraft Server TPS hängt selten an einem einzelnen Faktor. Single-Core-Leistung, passend dimensionierter RAM je nach Server-Software und die Anzahl aktiv simulierter Chunks wirken zusammen. Wer diese drei Stellschrauben versteht und gezielt anpasst, erkennt Performance-Probleme schneller und trifft fundiertere Entscheidungen bei Konfiguration und Weltgestaltung.

FAQ

Warum sinkt die TPS trotz wenig Spielern auf dem Server?

Meist liegt es an vielen geladenen Chunks mit aktiven Farmen, Redstone-Schaltungen oder Mob-Ansammlungen. Auch inaktive Bereiche können weiterhin simuliert werden, wenn die Simulation-Distance zu hoch eingestellt ist oder Plugins Chunks künstlich geladen halten.

Hilft mehr RAM automatisch gegen niedrige TPS?

Nicht zwingend. Zu wenig RAM verursacht häufige Garbage Collection und Tick-Spitzen, aber zu viel zugewiesener RAM kann längere Garbage-Collection-Zyklen auslösen. Entscheidend ist eine an die Server-Software und Weltgröße angepasste Größe von -Xms und -Xmx.

Wie finde ich heraus, welches Plugin die TPS am stärksten belastet?

Bei Paper-basierten Servern liefert der Befehl /timings report eine detaillierte Aufschlüsselung der Tick-Zeit pro Plugin und System. So lässt sich der genaue Verursacher identifizieren, statt Plugins pauschal zu deaktivieren.