Minecraft Server Performance verstehen: TPS, RAM und Single-Core-Leistung im Detail

Minecraft Server TPS sind der ehrlichste Leistungswert, den du hast: 20 TPS heißt, jeder Tick bleibt unter 50 Millisekunden, alles darunter bedeutet, der Server hinkt der Spielwelt hinterher. Mehr Arbeitsspeicher löst das selten. Entscheidend sind Single-Core-Leistung, saubere Chunk-Ladung und eine Konfiguration, die zur eingesetzten Serversoftware passt.

TPS, MSPT und was beide wirklich messen

Ein Tick ist der Herzschlag der Spielwelt: Mobs bewegen sich, Redstone schaltet, Pflanzen wachsen, Tränke ticken. Der Server plant 20 Ticks pro Sekunde, also 50 Millisekunden pro Tick. Braucht ein Tick länger, wartet der nächste, und die TPS fallen.

Genau deshalb ist MSPT (Millisekunden pro Tick) der aussagekräftigere Wert. Ein Server mit 20,0 TPS und 46 MSPT steht kurz vor dem Einbruch, ein Server mit 20,0 TPS und 12 MSPT hat massig Reserve. TPS zeigen nur, wann es bereits zu spät ist.

• unter 25 MSPT: gesunde Reserve, auch für Spitzenlast
• 25 bis 40 MSPT: knapp, einzelne Spikes werden sichtbar
• über 50 MSPT: TPS sinken, Mobs stottern, Blöcke brechen verzögert

/tps
/mspt
/spark tps
/spark health --upload

Wichtig ist die Abgrenzung zum Client: niedrige FPS im Spiel sind ein Grafikproblem, hoher Ping ein Netzwerkproblem. Nur TPS und MSPT beschreiben, was auf der Servermaschine passiert. Wer diese drei Werte nicht trennt, optimiert regelmäßig an der falschen Stelle. Details zum Tick-System stehen im Source.

Wer TPS-Probleme von vornherein vermeiden will, braucht als Unterbau eine Maschine mit hoher Taktrate pro Kern und schnellem NVMe-Speicher. Die technischen Eckdaten dazu findest du auf der Seite Minecraft Server mieten.

Warum Minecraft Server TPS an der Single-Core-Leistung hängen

Der Spiellogik-Thread ist der Flaschenhals. Entitäten, Redstone, Blockupdates, Mob-KI und Inventarlogik laufen bei Vanilla, Spigot und Paper in einem einzigen Thread. Ein zweiter Kern kann diesem Thread nicht helfen, egal wie viele Kerne die Maschine besitzt.

Daraus folgt eine klare Priorität: Takt und IPC pro Kern schlagen Kernanzahl. Ein Ryzen 9 7950X3D punktet hier doppelt, weil der große L3-Cache viele zufällige Speicherzugriffe des Spiellogik-Threads abfängt, statt sie in den RAM zu schicken.

Was zusätzliche Kerne trotzdem übernehmen

• Garbage Collection der JVM in parallelen Threads
• Chunk-Generierung und Chunk-I/O (bei Paper ausgelagert)
• Netty-Netzwerkthreads für die Spielerverbindungen
• asynchrone Plugin-Aufgaben, Datenbankzugriffe, Backups

Projekte wie Folia verteilen die Weltlogik auf mehrere Regionen und damit auf mehrere Threads. Das lohnt sich erst bei sehr hohen Spielerzahlen und verlangt kompatible Plugins, für ein normales Community-Projekt bleibt Paper die pragmatischere Wahl.

RAM nach Serversoftware richtig dimensionieren

Zu wenig Heap zwingt die JVM in Dauer-Garbage-Collection, und jede lange GC-Pause erscheint im Spiel als Ruckler. Zu viel Heap ist ebenfalls ungesund: der G1GC muss größere Speicherbereiche durchsuchen, einzelne Pausen werden länger und fallen stärker auf.

Serversoftware	Typischer Heap-Bedarf	Bemerkung
Vanilla, kleine Runde	2 bis 3 GB	bis etwa 10 Spieler, geringe View-Distance
Paper mit Plugins	4 bis 6 GB	Survival-Community, 20 bis 40 Spieler
Fabric, leichte Mods	4 bis 6 GB	Performance-Mods wie Lithium sparen spürbar
Forge, mittleres Modpack	6 bis 8 GB	viele Blockentitäten und Maschinen
Großes Modpack	10 GB und mehr	Dimensionen und Chunk-Loader treiben den Bedarf

Setze -Xms und -Xmx immer identisch. Ein wachsender Heap erzeugt zusätzliche Umschichtungen, die genau während der Spitzenlast auftreten. Plane außerdem Reserve außerhalb des Heaps ein: Metaspace, Netty-Puffer und die Weltdateien im Dateisystem-Cache brauchen ebenfalls Platz.

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

DDR5-ECC-Speicher bringt keine höheren TPS, verhindert aber stille Bitfehler, die sich später als korrupte Regionsdatei oder als abgestürzter Tick zeigen. Für langlebige Welten zählt diese Stabilität mehr als jedes zusätzliche Gigabyte.

Chunk-Ladung, View-Distance und Simulation-Distance

View-Distance steuert, wie viele Chunks der Server an den Client sendet. Simulation-Distance steuert, in welchem Radius Entitäten, Redstone und Zufallsticks tatsächlich berechnet werden. Die zweite Zahl kostet Rechenzeit, die erste vor allem Bandbreite und Arbeitsspeicher.

Der Standardwert 10 ist für größere Runden zu hoch angesetzt. Jeder Spieler zieht bei View-Distance 10 rund 441 Chunks nach sich, bei 8 sind es 289. Bei 40 gleichzeitigen Spielern in verschiedenen Weltregionen ist das ein spürbarer Unterschied.

# server.properties
view-distance=8
simulation-distance=5
max-tick-time=60000
sync-chunk-writes=false
network-compression-threshold=256

Welt vorgenerieren statt live erzeugen

Das Erzeugen neuer Chunks ist die teuerste Einzeloperation im Spiel. Wenn Spieler mit Elytra oder Pferd in unerforschtes Gelände ziehen, entstehen genau dort Lag-Spikes. Eine Vorgenerierung mit Chunky verlagert diese Arbeit in eine ruhige Phase.

/chunky world world
/chunky radius 5000
/chunky start
/chunky progress

Setze zusätzlich eine Weltgrenze auf denselben Radius. Ohne Grenze wächst die Welt unbegrenzt weiter, die Region-Dateien füllen den Datenträger und jedes Backup dauert länger. Eine klare Grenze hält Speicherbedarf und Ladezeiten planbar.

Lag-Spikes selbst analysieren statt raten

Ohne Messung bleibt jede Optimierung Glückssache. Der Profiler spark liefert innerhalb weniger Minuten einen Report, der genau zeigt, welcher Plugin-Task, welche Entität oder welcher Weltbereich den Tick aufhält. Die Dokumentation dazu steht unter Source.

/spark profiler start --timeout 300
/spark profiler stop
/spark heapsummary
/spark tickmonitor --threshold 100

Was die Logdatei verrät

• „Can't keep up! Is the server overloaded?" weist meist auf langsame Datenträger-Zugriffe, Backups zur Laufzeit oder GC-Pausen hin.
• Watchdog-Crash nach 60 Sekunden bedeutet einen blockierten Spiellogik-Thread, fast immer ein Plugin mit synchronem Netzwerk- oder Datenbankzugriff.
• „Saving chunks for level" im Sekundentakt deutet auf zu häufiges Autosave oder eine sehr große geladene Weltfläche.

GC-Pausen bekommst du gezielt sichtbar, indem du die JVM protokollieren lässt. Häufen sich Pausen über 200 Millisekunden, stimmt die Heap-Größe oder die Anzahl der Entitäten nicht.

-Xlog:gc*:file=logs/gc.log:time,uptime:filecount=5,filesize=10M

Arbeite immer mit einer Änderung pro Durchlauf. Wer View-Distance, Mob-Caps und JVM-Flags gleichzeitig anfasst, weiß hinterher nicht, welche Maßnahme gewirkt hat. Auf Alle unsere Gameserver läuft dieselbe Methodik, unabhängig vom Spiel.

Gegenmaßnahmen, die messbar wirken

Entitäten sind bei den meisten Welten die Hauptlast. Mob-Farmen, Tierzuchten und liegende Items summieren sich, und jede davon wird pro Tick angefasst. Aktivierungsradien und Mob-Limits senken diese Last, ohne das Gameplay spürbar zu beschneiden.

# spigot.yml
entity-activation-range:
  animals: 16
  monsters: 24
  misc: 8
merge-radius:
  item: 3.5
  exp: 4.0
ticks-per:
  hopper-transfer: 8
  hopper-check: 8

Trichter-Ketten sind der zweite große Verursacher. Jeder Trichter prüft mehrfach pro Sekunde seinen Inhalt und den Block darüber. In Sortieranlagen mit hunderten Trichtern ist eine höhere hopper-check-Rate oft die wirksamste Einzeländerung überhaupt.

Reihenfolge der Maßnahmen

1. Messen mit spark, Verursacher identifizieren
2. Simulation-Distance und View-Distance auf realistische Werte setzen
3. Entitäten begrenzen, verwaiste Farmen und Chunk-Loader entfernen
4. Heap korrekt dimensionieren, -Xms gleich -Xmx
5. Welt vorgenerieren und Weltgrenze setzen
6. Plugins ohne Nutzen entfernen, Backups außerhalb der Stoßzeiten planen

Backups gehören nicht in die Prime Time: das Lesen tausender Region-Dateien belastet die I/O-Warteschlange und erzeugt genau dann Spikes, wenn die meisten Spieler online sind. Automatische Sicherungen im NexusPanel lassen sich zeitlich verschieben, ebenso geplante Neustarts.

Ein geplanter Neustart alle 6 bis 12 Stunden räumt fragmentierten Heap und verwaiste Entitäten auf. Das ersetzt keine Analyse, verschafft aber Luft, bis die eigentliche Ursache gefunden ist. Weitere Praxisleitfäden sammelt der Nexus Games Blog.

Fazit

Erhöhe bei Rucklern niemals als Erstes den Arbeitsspeicher. Miss zuerst MSPT, starte einen spark-Profiler und suche den Verursacher: in neun von zehn Fällen sind es Entitäten, Trichter oder eine zu hohe Simulation-Distance. Der Heap sollte zur Serversoftware passen, nicht maximal groß sein. Und plane Backups sowie Neustarts außerhalb der Stoßzeiten, sonst erzeugst du die Spikes, die du eigentlich beseitigen willst.

FAQ

Warum ruckelt es bei mir, obwohl der Server 20 TPS anzeigt?

Dann liegt das Problem nicht in der Weltlogik. Prüfe zuerst deinen Ping mit F3 im Spiel: steigt er über 100 Millisekunden, ist die Verbindung die Ursache. Zeigt F3 dagegen niedrige FPS, limitiert deine Grafikkarte oder eine zu hohe Render-Distance im Client. Ein Ressourcenpack mit hochauflösenden Texturen oder Shader kosten ebenfalls Bildrate, ohne den Server zu belasten.

Helfen regelmäßige Neustarts wirklich gegen Lag?

Sie helfen gegen die Symptome. Nach vielen Stunden Laufzeit ist der Heap fragmentiert, Plugins halten Objekte im Speicher und geladene Chunks summieren sich. Ein Neustart alle 6 bis 12 Stunden setzt das zurück und hält die Tickzeiten stabil. Verschlechtern sich die Werte aber schon nach einer Stunde deutlich, liegt ein Speicherleck oder eine überlastete Farm vor, und der Neustart kaschiert nur die Ursache.

Beeinflussen Datapacks und Proxy-Netzwerke die Tickrate?

Datapacks mit häufig laufenden Funktionen können den Spiellogik-Thread deutlich belasten, besonders wenn sie pro Tick über viele Entitäten iterieren. Prüfe das mit /spark profiler, dort tauchen Funktionsaufrufe namentlich auf. Ein Proxy wie Velocity oder BungeeCord selbst verursacht dagegen kaum Tick-Last, weil er nur Pakete weiterleitet; er beeinflusst hauptsächlich die Latenz und die Übergabezeit zwischen zwei Welten.