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

Die Minecraft Server Performance entscheidet sich an drei Werten: den TPS, dem sinnvoll zugewiesenen RAM und dem Verhalten beim Laden von Chunks. Wer bei Rucklern einfach RAM nachschiebt, behebt in den meisten Fällen nichts. Ticks messen, Engpass zuordnen, Lag-Quelle abstellen: in dieser Reihenfolge kommst du zu einer Welt, die auch mit vollem Slot-Bestand flüssig tickt.

TPS messen und verstehen

Ein Minecraft-Server berechnet die Welt in Ticks. Der Zielwert sind 20 Ticks pro Sekunde, jeder Tick hat damit 50 Millisekunden Budget. Braucht ein Tick länger, sinken die TPS und die Welt läuft in Zeitlupe: Mobs stocken, Pflanzen wachsen langsamer, Redstone-Uhren driften auseinander.

TPS und MSPT sind nicht dasselbe

TPS zeigt nur, ob das Pensum überhaupt geschafft wird. MSPT (Millisekunden pro Tick) zeigt, wie viel Luft noch bleibt. Bei 20 TPS und 48 MSPT stehst du unmittelbar vor dem Einbruch, bei 20 TPS und 12 MSPT hast du echte Reserven. Beobachte deshalb immer MSPT.

MSPT (Durchschnitt)	Bedeutung	Sinnvolle Reaktion
unter 20	viel Reserve	View-Distance darf höher
20 bis 35	gesunde Auslastung	weiter beobachten
35 bis 50	knapp	Profiler mitlaufen lassen
über 50	TPS fallen unter 20	Ursache sofort eingrenzen

Messen statt raten

Die Konsole im Panel oder der Ingame-Chat mit Operator-Rechten reichen für die Basiswerte. Für die Ursachensuche brauchst du einen Profiler, der zeigt, welche Methode den Tick füllt.

/tps
/mspt
/spark tps
/spark health
/spark profiler start --timeout 120
/spark profiler stop

spark läuft als Plugin (Paper, Spigot) oder als Mod (Fabric, Forge) und liefert am Ende einen Report-Link mit Aufschlüsselung pro Thread. Das alte Timings2 ist in aktuellen Paper-Builds entfernt, der Profiler ersetzt es vollständig.

Wie viel Rechenleistung hinter deiner Welt steht, legt die Obergrenze fest: welche Hardware unter einer Instanz arbeitet, steht auf der Produktseite Minecraft Server mieten.

Warum Single-Core-Leistung die Minecraft Server Performance bestimmt

Die Spiellogik läuft in einem einzigen Thread, dem Main Thread. Mobs, Redstone, Blockupdates, Wachstum, Inventare: alles wird dort sequenziell abgearbeitet. Zwei Dinge zählen dafür, Takt und Instruktionen pro Takt. Eine CPU mit vielen schwachen Kernen tickt eine Welt langsamer als eine CPU mit weniger, aber schnelleren Kernen.

Große L3-Caches wirken hier stark, weil der Tick permanent auf dieselben Datenstrukturen zugreift. Ein Ryzen 9 7950X3D mit DDR5-ECC-RAM und NVMe-Datenträgern deckt genau dieses Profil ab: hoher Durchsatz pro Kern, kurze Speicherlatenz, schnelle Region-File-Zugriffe. Technische Details zur Plattform stehen unter Alle unsere Gameserver.

Was zusätzliche Kerne wirklich übernehmen

• Chunk-Generierung und Chunk-I/O, in modernen Versionen weitgehend ausgelagert
• Netzwerk-Threads für Spielerverbindungen und Paketkompression
• Garbage Collection der JVM
• Weltspeicherung und Backups im Hintergrund
• parallel laufende Instanzen, etwa ein Proxy plus mehrere Welten

Mehr Kerne bringen also mehr Instanzen und ruhigere Nebenprozesse, aber keine höheren TPS in einer überladenen Welt. Wer 40 Spieler auf einer Survival-Map mit riesigen Farmen hat, gewinnt durch schnellere Kerne und aufgeräumte Weltmechanik, nicht durch Kernanzahl.

RAM-Zuweisung je nach Serversoftware

RAM verhindert Abstürze und Stottern beim Laden, er erhöht aber keine Tickrate. Entscheidend ist, dass der Heap zur Software und zur Weltgröße passt. Zu wenig führt zu Dauer-GC, zu viel führt zu langen Pausen beim Aufräumen.

Richtwerte nach Software und Modumfang

Software	Typischer Heap	Bemerkung
Vanilla, kleine Runde	2 bis 3 GB	reicht bis etwa 10 Spieler
Paper oder Purpur, Community	4 bis 6 GB	mit Plugins und WorldEdit
Fabric mit Performance-Mods	4 bis 6 GB	Lithium, FerriteCore sparen spürbar
Forge-Modpack, 150 Mods	8 bis 10 GB	Techmods laden viele Rezepte
großes Kitchen-Sink-Pack	12 bis 16 GB	plus Reserve für Weltgeneration

Xms und Xmx gleich setzen

Ein fester Heap verhindert, dass die JVM ständig Speicher anfordert und freigibt. Diese Startzeile entspricht den verbreiteten Aikar-Flags für G1GC:

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:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 \
  -jar paper.jar nogui

Die Hintergründe zu diesen Flags dokumentiert das Paper-Projekt in seiner offiziellen Dokumentation zu JVM-Flags. Ab etwa 12 GB Heap lohnt ein Blick auf ZGC oder Shenandoah, weil G1 dann längere Pausen produziert.

Woran du eine echte RAM-Grenze erkennst

Typische Signale: der Heap-Graph in spark steigt sofort nach jedem GC wieder auf Anschlag, Full-GC-Einträge häufen sich im Log, und die Lag-Spitzen kommen in regelmäßigen Abständen statt bei bestimmten Aktionen. Tritt das nicht auf, ist mehr RAM verschwendet.

Chunk-Ladeverhalten, View- und Simulation-Distance

Jeder geladene Chunk kostet Tickzeit und Speicher. Die Anzahl wächst quadratisch mit der Distanz: von 8 auf 12 Chunks Sichtweite bedeutet grob die doppelte Fläche pro Spieler. Genau hier liegt der schnellste Hebel gegen hohe MSPT.

# server.properties
view-distance=8
simulation-distance=6
max-players=40
sync-chunk-writes=false
entity-broadcast-range-percentage=80

view-distance steuert, was der Client sieht, simulation-distance, was tatsächlich getickt wird. Mobs, Pflanzen und Redstone brauchen nur die Simulationsreichweite. Eine Kombination aus 8 und 6 wirkt auf Survival-Servern fast immer besser als 10 und 10.

Welt vorgenerieren statt live erzeugen

Neue Chunks zu generieren ist die teuerste Einzeloperation überhaupt. Entdeckt eine Gruppe frisches Terrain mit Elytren oder Booten, fällt die Tickrate hörbar ein. Chunky erledigt das vorab, am besten nachts oder direkt nach dem Weltstart.

/chunky world world
/chunky center 0 0
/chunky radius 4000
/chunky start
/chunky progress

Setze parallel eine Weltgrenze auf denselben Radius. Ohne Grenze läuft jeder Spieler irgendwann wieder in ungenerierte Bereiche, und die Vorgenerierung war umsonst.

Spawn-Chunks und dauerhaft geladene Bereiche

Die Spawn-Chunks bleiben permanent aktiv, auch ohne Spieler. Große Automatik-Farmen dort ticken rund um die Uhr mit. Verlege solche Anlagen oder reduziere den Bereich über die Paper-Konfiguration, wenn niemand die Dauerlast braucht.

# paper-world-defaults.yml
chunks:
  auto-save-interval: 6000
  max-auto-save-chunks-per-tick: 8
  delay-chunk-unloads-by: 10s
  prevent-moving-into-unloaded-chunks: true
entities:
  spawning:
    per-player-mob-spawns: true

Typische Lag-Ursachen und ihre Gegenmaßnahmen

Ein Profiler-Report ordnet fast jeden Fall einer dieser Gruppen zu. Gehe sie in dieser Reihenfolge durch, die Trefferquote ist hoch.

Entities und Farmen

Hunderte Kühe in einem Pen, gestapelte Items in Trichterketten, ein Iron-Farm-Cluster: Entities dominieren die Tickzeit auf gewachsenen Welten. spigot.yml begrenzt, wie weit entfernte Wesen überhaupt Logik ausführen.

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

Redstone, Trichter und Item-Transport

Laufende Taktgeber und lange Trichterketten erzeugen konstante Grundlast, die im Report als Block-Entity-Tick auftaucht. Alternativen mit Observern