Minecraft Server Performance verstehen: TPS, RAM und Single-Core-Leistung richtig einschätzen

Minecraft Server TPS ist die Kennzahl, die dir sagt, ob deine Welt in Echtzeit läuft: 20 Ticks pro Sekunde sind das Maximum, alles darunter bedeutet, dass die Simulation hinterherhinkt. Verantwortlich dafür sind Single-Core-Takt, Arbeitsspeicher, die eingesetzte Serversoftware und die Menge geladener Chunks. Wie du diese Werte misst, deutest und wieder in den grünen Bereich bringst, steht hier.

Was TPS und MSPT wirklich aussagen

Ein Tick ist ein kompletter Simulationsschritt der Welt: Mobs bewegen sich, Redstone schaltet, Wachstum wird berechnet, Spielerpositionen werden verarbeitet. Das Spiel plant 20 Ticks pro Sekunde ein, jeder Tick hat also ein Budget von 50 Millisekunden. Bleibt die Berechnung darunter, wartet der Server den Rest der Zeit ab.

Genau deshalb ist TPS allein irreführend. Ein Server mit 20,0 TPS kann trotzdem am Limit laufen, wenn jeder Tick 47 ms braucht. Die aussagekräftigere Zahl heißt MSPT (Milliseconds Per Tick). Sie zeigt die tatsächliche Reserve, bevor die Tickrate einbricht.

MSPT (Durchschnitt)	TPS	Bedeutung
unter 30 ms	20.0	Reserve vorhanden, Welt kann wachsen
30 bis 45 ms	20.0	Knapp, Spitzen führen zu Mikrorucklern
45 bis 50 ms	19.x	Grenzbereich, jede neue Farm kippt die Rate
über 50 ms	unter 20	Welt läuft in Zeitlupe, Redstone und Mobs verzögern

Unter 20 TPS wird die Spielzeit gedehnt: Öfen brauchen länger, Pflanzen wachsen langsamer, Hoppers takten träge. Spieler bemerken das oft zuerst an Mobs, die springen statt zu laufen. Die technischen Eckdaten der einzelnen Konfigurationen findest du auf der Seite Minecraft Server mieten.

Minecraft Server TPS richtig messen

Ohne Messwerte ist jede Optimierung Raten. Paper, Purpur und Spigot bringen die nötigen Befehle bereits mit, du brauchst dafür Konsolenzugriff oder OP-Rechte im Spiel.

Die Basisbefehle in der Konsole

> tps
[Server] TPS from last 1m, 5m, 15m: 19.98, 19.71, 19.34

> mspt
[Server] Server tick times (avg/min/max) from last 5s, 10s, 1m:
[Server] 5s:  34.2/21.7/61.4
[Server] 10s: 33.8/20.9/58.3
[Server] 1m:  36.5/19.4/112.7

Wichtig ist der Maximalwert. Ein Durchschnitt von 34 ms bei Spitzen von 112 ms deutet auf einen periodischen Auslöser hin: Autosave, Chunk-Generierung oder ein Plugin mit geplantem Task. Der Vanilla-Server ohne Plugin-Basis liefert nur /debug start und schreibt einen Report in den Ordner debug/.

Profiling mit spark

Für die Ursachensuche führt kaum ein Weg an spark vorbei. Das Plugin zerlegt die Tickzeit nach Methoden und zeigt dir, welcher Task den Hauptthread blockiert.

/spark profiler start --timeout 300
/spark healthreport
/spark tps
/spark profiler stop

Lass den Profiler laufen, während die Spitzenlast auftritt, also zur Primetime deiner Community. Der erzeugte Report läuft im Browser und listet Entity-Ticking, Chunk-I/O und Plugin-Tasks getrennt auf. Details zu den Flags dokumentiert die offizielle PaperMC-Dokumentation.

Single-Core-Takt schlägt Kernanzahl

Der Haupt-Tickloop von Minecraft läuft auf genau einem Thread. Egal wie viele Kerne die Maschine besitzt, die Weltsimulation wird von einem einzigen Kern abgearbeitet. Ein Prozessor mit 32 Kernen und niedrigem Takt liefert deshalb schlechtere Tickzeiten als eine CPU mit weniger Kernen und hohem Boost.

Moderne Serversoftware lagert zwar Teile aus: Paper verarbeitet Chunk-Ladevorgänge, Netzwerk-I/O und Weltspeicherung asynchron. Die eigentliche Logik, also Entities, Redstone, Block-Updates und Pathfinding, bleibt auf dem Mainthread. Zusätzliche Kerne helfen dort nur indirekt, indem sie Nebenaufgaben vom Hauptthread fernhalten.

Was bei der Hardware zählt

• Taktrate und IPC: Ein Ryzen 9 7950X3D bearbeitet denselben Tick deutlich schneller als ältere Serverchips mit vielen langsamen Kernen.
• Cache: Große L3-Caches reduzieren Speicherzugriffe bei dichten Entity-Clustern spürbar.
• Speicherlatenz: DDR5 ECC hält die Zugriffszeiten niedrig und schützt gleichzeitig vor Bitfehlern in langlebigen Welten.
• Datenträger: SSD NVMe verhindert, dass das Nachladen von Regionsdateien den Tick blockiert.
• Dediziert oder geteilt: Ein Kern, den sich mehrere Instanzen teilen, erzeugt unregelmäßige MSPT-Spitzen ohne erkennbares Muster im Profiler.

Wer parallel mehrere Welten betreibt, sollte die Instanzen auf getrennte Kerne verteilen. Auch andere Titel aus unserem Katalog reagieren ähnlich auf Single-Core-Leistung, ein Überblick steht unter Alle unsere Gameserver.

Wie viel Arbeitsspeicher welche Software braucht

RAM steigert keine Tickrate. Er verhindert nur, dass der Garbage Collector den Hauptthread anhält, weil der Heap voll ist. Zu wenig Speicher erzeugt lange GC-Pausen, zu viel Speicher erzeugt seltenere, dafür längere Pausen. Beides zeigt sich im Profiler als regelmäßiger MSPT-Ausschlag.

Software	Spielerzahl	Heap (Xmx)	Anmerkung
Vanilla	bis 10	3 bis 4 GB	Kein Async-Chunkloading, Sichtweite reduzieren
Paper / Purpur	10 bis 30	4 bis 6 GB	Beste Tickzeiten pro Gigabyte
Fabric, leichte Mods	10 bis 20	4 bis 6 GB	Lithium und FerriteCore senken den Bedarf
Forge-Modpack, mittel	5 bis 15	6 bis 8 GB	Weltgenerierung ist der Hauptfresser
Großes Modpack (300+ Mods)	5 bis 15	10 bis 14 GB	Chunk-Pregeneration dringend empfohlen
Proxy (Velocity, BungeeCord)	beliebig	1 bis 2 GB	Reine Paketweiterleitung, kaum Heap-Bedarf

Startparameter und Garbage Collection

Setze Xms und Xmx auf denselben Wert, damit die JVM den Heap nicht ständig neu dimensioniert. Reserviere außerdem etwa ein bis zwei Gigabyte für das Betriebssystem und die JVM selbst, die Heap-Angabe ist nicht der Gesamtverbrauch.

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

Bei Heaps ab etwa 12 GB lohnt ein Wechsel auf ZGC oder Shenandoah, weil G1 dort längere Pausen produziert. Prüfe die Wirkung immer über /spark healthreport, der die GC-Pausen in Millisekunden ausweist.

Typische Lag-Ursachen und ihre Gegenmittel

Fast jeder Tickeinbruch lässt sich einer von sechs Ursachen zuordnen. Die folgende Übersicht ordnet Symptom, Auslöser und Gegenmaßnahme einander zu.

Symptom	Ursache	Gegenmaßnahme
Dauerhaft 15 bis 18 TPS	Zu viele geladene Entities, meist Mob- oder Item-Farmen	Entity-Limits pro Chunk, Merge-Radius für Items erhöhen
Spitzen alle paar Minuten	Autosave schreibt zu viele Chunks pro Tick	max-auto-save-chunks-per-tick senken
Einbruch beim Elytra-Flug	Chunk-Generierung am Weltrand	Welt mit Chunky vorgenerieren, Weltgrenze setzen
Ruckeln nur bei vielen Spielern	Sichtweite und Simulationsdistanz zu hoch	view-distance und simulation-distance trennen
Konstant hohe MSPT ohne Aktivität	Plugin mit Task auf dem Hauptthread	spark-Profiler auswerten, Plugin ersetzen
Hänger beim Betreten des Nether	Portal-Suche über große Radien	Portal-Verlinkung prüfen, Nether-Weltgrenze verkleinern

Entity-Ticking als Hauptverdächtiger

Redstone-Uhren, Hopper-Ketten und riesige Tierfarmen erzeugen den größten Anteil an Rechenaufwand pro Tick. Ein einzelner Chunk mit hunderten Items kann eine ganze Welt ausbremsen. Der spark-Report zeigt solche Hotspots samt Koordinaten, danach reicht meist ein Gespräch mit dem Bauherrn oder ein Cap pro Farm.

Netzwerk oder Simulation unterscheiden

Hoher Ping bei 20 TPS ist ein Routing- oder Verbindungsthema, kein Leistungsproblem der Maschine. Umgekehrt bringt eine 1 Gbit/s-Anbindung nichts, wenn der Hauptthread 80 ms pro Tick braucht. Trenne die beiden Ebenen immer, bevor du an Parametern drehst. Weitere Praxisartikel dazu sammelt der Nexus Games Blog.

Stellschrauben für stabile Tickraten

Die wirksamsten Änderungen liegen in drei Dateien: server.properties, spigot.yml und config/paper-world-defaults.yml. Ändere immer nur einen Wert und beobachte MSPT über mindestens eine Stunde Spielbetrieb.

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

Die Sichtweite bestimmt, wie viele Chunks der Client sieht, die Simulationsdistanz, wie weit Mobs und Redstone tatsächlich rechnen. Eine Sichtweite von 8 bei Simulationsdistanz 6 wirkt für Spieler großzügig und halbiert dennoch die Last gegenüber dem Standard.

# config/paper-world-defaults.yml (Auszug)
entities:
  spawning:
    despawn-ranges:
      monster:
        hard: 96
    per-player-mob-spawns: true
chunks:
  max-auto-save-chunks-per-tick: 8
  prevent-moving-into-unloaded-chunks: true
item-merge-radius: 3.5
experience-merge-radius: 4.0

Ergänzend lohnt sich eine Vorgenerierung der Welt. Chunky erzeugt die Regionsdateien einmalig im Voraus, statt sie während des Spiels unter Zeitdruck zu berechnen.

/chunky world world
/chunky radius 4000
/chunky start
/chunky progress

Führe die Vorgenerierung außerhalb der Stoßzeiten aus, weil sie den Datenträger und einen Kern voll auslastet. Danach setzt du die Weltgrenze auf denselben Radius, damit Spieler nicht doch wieder in ungenerierte Bereiche laufen.

Fazit

Wirf nicht zuerst Arbeitsspeicher auf das Problem, sondern miss MSPT und lass spark laufen. In neun von zehn Fällen sind zu hohe Simulationsdistanz, überfüllte Entity-Chunks oder ein blockierendes Plugin die Ursache, nicht ein zu kleiner Heap. Priorisiere bei der Hardware hohen Single-Core-Takt und NVMe-Speicher, dimensioniere den Heap knapp über dem realen Bedarf und generiere die Welt vor. Diese Reihenfolge spart mehr Tickzeit als jede Flag-Sammlung.

FAQ

Warum ist mein Ping hoch, obwohl die TPS bei 20 liegen?

Ping und Tickrate messen zwei verschiedene Dinge. Die Tickrate beschreibt, wie schnell die Weltsimulation rechnet, der Ping die Laufzeit der Pakete zwischen Client und Maschine. Bei stabilen 20 TPS und hoher Latenz liegt die Ursache im Netzwerkpfad: WLAN statt Kabel, ein überlastetes Heimnetz, eine ungünstige Route oder ein VPN. Prüfe die Verbindung mit einem Traceroute und schließe den Client testweise per Kabel an.

Was bedeutet die Meldung "Can't keep up! Is the server overloaded?" in der Konsole?

Diese Warnung erscheint, wenn ein Tick deutlich länger als 50 Millisekunden gebraucht hat und die Simulation Ticks überspringen muss. Einmalig nach dem Start oder während einer Weltsicherung ist das harmlos. Erscheint sie im laufenden Betrieb regelmäßig, blockiert etwas den Hauptthread: Chunk-Generierung, ein synchrones Plugin oder ein langsamer Datenträger. Starte ein Profiling während der Meldung, dann siehst du den Verursacher direkt.

Wie viele Spieler verträgt eine Welt bei stabilen 20 TPS?

Eine feste Zahl gibt es nicht, weil die Last vom Verhalten abhängt. Zwanzig Spieler auf einem gemeinsamen Spawnbereich erzeugen weniger Chunk-Last als fünf Spieler, die gleichzeitig in verschiedene Richtungen neue Gebiete erkunden. Als Orientierung: Paper mit Sichtweite 8 und vorgenerierter Welt trägt auf schneller Hardware 30 bis 50 Spieler, ein großes Forge-Modpack oft nur 10 bis 15.