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

Minecraft Server TPS gibt an, wie viele Spielticks dein Server pro Sekunde abarbeitet: 20 ist das Maximum, alles darunter heißt, dass die Welt langsamer läuft als vorgesehen. Ob dieser Wert stabil bleibt, entscheidet zuerst die Single-Core-Leistung der CPU, erst danach die RAM-Zuweisung. Wie du beides misst, richtig dimensionierst und Lagquellen ausschaltest, steht Schritt für Schritt hier.

Was die Tickrate über den Zustand deiner Welt verrät

Die Server-Engine rechnet die Spielwelt in festen Intervallen durch: 20 Ticks pro Sekunde, also 50 Millisekunden Budget pro Tick. In diesem Fenster werden Mobs bewegt, Redstone ausgewertet, Chunks geladen, Wachstum berechnet und Pakete an die Clients geschickt. Braucht ein Durchlauf länger als 50 ms, kann der Server nicht aufholen und die Tickrate fällt.

Ein Teil der Tickrate entscheidet sich auf Hardwareebene, lange bevor du eine Konfigurationsdatei öffnest. Welche CPU-Generation, welcher Speichertyp und welcher Datenträger hinter einer Instanz stecken, siehst du auf der Seite Minecraft Server mieten.

MSPT ist der ehrlichere Wert

TPS wird bei 20 gedeckelt und verrät dir nichts über die Reserve. MSPT (Millisekunden pro Tick) zeigt dagegen, wie voll das Budget bereits ist. Ein Server mit 20 TPS und 46 ms MSPT steht kurz vor dem Einbruch, ein Server mit 20 TPS und 12 ms MSPT hat noch reichlich Luft für Spieler und Farmen.

Tickrate, Ping und Client-FPS trennen

• Niedrige TPS: alle Spieler erleben dasselbe Ruckeln, Mobs bewegen sich zeitlupenhaft, Öfen und Redstone werden langsam.
• Hoher Ping: nur einzelne Spieler betroffen, Blöcke springen zurück, Treffer registrieren verzögert.
• Wenig FPS im Client: die Welt läuft normal, nur die Bildausgabe stockt. Das ist ein Problem der Grafikeinstellungen, nicht des Servers.

Warum Single-Core-Leistung über die Tickrate entscheidet

Die Hauptschleife von Minecraft läuft in einem einzigen Thread. Ganz gleich, wie viele Kerne die Maschine hat: Entity-Ticks, Blockupdates und Redstone landen auf genau einem davon. Deshalb bringt eine CPU mit hohem Takt und großem Cache deutlich mehr als eine mit vielen langsamen Kernen. Ein Ryzen 9 7950X3D ist genau wegen dieser Kombination aus Taktrate und L3-Cache eine sinnvolle Basis.

Nebenaufgaben werden dagegen ausgelagert und profitieren sehr wohl von zusätzlichen Kernen. Dazu zählen Chunk-Generierung und Chunk-Ladevorgänge bei Paper, Netzwerkkompression, asynchrone Plugin-Tasks, Weltsicherungen und die Datenbankzugriffe von LuckPerms oder CoreProtect.

Software-Zweige und ihr Verhalten

Server-Software	Tick-Verhalten	Typischer Einsatz
Vanilla	Sehr wenig Optimierung, alles im Haupt-Thread	Kleine Freundesrunde, Referenzverhalten
Paper	Asynchrones Chunk-Handling, viele Tuning-Optionen	Plugin-Netzwerke, öffentliche Welten
Fabric mit Lithium/Krypton	Optimierte Algorithmen, weiterhin ein Haupt-Thread	Moderne Mod-Setups
Forge/NeoForge	Tick-Last stark abhängig vom Modpack	Große Technikpacks
Folia	Regionsbasiertes Threading, verteilt Welten auf Kerne	Sehr große, weit verstreute Spielerzahlen

Folia verteilt unabhängige Weltregionen auf mehrere Threads, verlangt aber Plugins, die dafür angepasst wurden. Für die meisten Communities bleibt Paper mit sauber gepflegter Konfiguration der pragmatischere Weg.

RAM richtig zuweisen: Software-Zweig und Plugin-Last

RAM steigert die Tickrate nicht, er verhindert nur, dass sie einbricht. Zu wenig Heap bedeutet ständige Garbage-Collection-Pausen und im Extremfall einen OutOfMemoryError. Zu viel Heap bedeutet längere Sammelläufe und damit ebenfalls sichtbare Aussetzer. Ziel ist der Bereich, in dem der Speicher nach jedem GC-Lauf wieder deutlich unter die Hälfte fällt.

Setup	Übliche Zuweisung	Hinweis
Vanilla oder Paper, kleine Runde	2 bis 3 GB	Reicht für eine überschaubare Welt ohne große Farmen
Paper mit 20 bis 40 Plugins	4 bis 6 GB	CoreProtect und Dynmap sind die größten Speicherfresser
Fabric mit Performance-Mods	4 bis 6 GB	Lithium und Starlight senken zusätzlich die Tick-Zeit
Mittleres Forge-Modpack	6 bis 8 GB	Chunkladende Maschinen treiben den Bedarf schnell hoch
Großes Technikpack, 200+ Mods	10 GB und mehr	Weltgröße und Dimensionen bestimmen den Rest

Startparameter, die tatsächlich etwas bewirken

Setze -Xms und -Xmx auf denselben Wert, damit die JVM den Heap nicht ständig neu dimensioniert. Lass außerdem Reserve für alles außerhalb des Heaps: Metaspace, Netzwerkpuffer und das Betriebssystem. Wer den gesamten verfügbaren Speicher zuweist, provoziert Swapping und damit Ticks im dreistelligen Millisekundenbereich.

java -Xms6G -Xmx6G --add-modules=jdk.incubator.vector \
  -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:G1HeapWastePercent=5 \
  -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 \
  -jar paper.jar nogui

Diese Flag-Sammlung ist der De-facto-Standard für G1GC unter Paper und in der offiziellen PaperMC-Dokumentation beschrieben. Im NexusPanel trägst du die Werte in den Startparametern der Instanz ein, danach genügt ein Neustart über die Konsole.

Minecraft Server TPS messen und Lagquellen eingrenzen

Ohne Messung ist jede Optimierung Raten. Der eingebaute Befehl /tps liefert Durchschnittswerte über eine, fünf und fünfzehn Minuten, sagt aber nicht, welcher Codepfad die Zeit verbraucht. Dafür ist spark das Werkzeug der Wahl: Es läuft als Plugin oder Mod und erzeugt einen Report mit Aufrufbaum.

/spark tps
/spark healthreport
/spark profiler start --timeout 120
/spark profiler stop
/spark profiler open

Einen Report lesen

1. Sortiere nach Anteil an der Tick-Zeit und suche den größten zusammenhängenden Block.
2. Steht dort ein Plugin-Paketname, hast du den Verursacher direkt.
3. Dominieren EntityTracker oder ServerEntity, sind zu viele Entities in geladenen Chunks aktiv.
4. Zeigt der Baum viel ChunkMap oder PoiManager, ist die Sichtweite oder die Zahl der Dorfbewohner das Problem.
5. Hohe Werte in writeChunk deuten auf einen langsamen Datenträger oder synchrone Speichervorgänge hin.

Führe die Messung immer zur Stoßzeit durch, nicht auf einer leeren Welt. Ein Report über zwei Minuten mit realer Spielerlast sagt mehr als eine Stunde Leerlauf.

Lags abstellen: Konfiguration Schritt für Schritt

1. Sicht- und Simulationsdistanz trennen

Die Simulationsdistanz bestimmt, in welchem Radius Mobs, Redstone und Wachstum berechnet werden, die Sichtweite nur, wie weit Chunks an Clients gesendet werden. Eine hohe Sichtweite bei niedriger Simulationsdistanz sieht gut aus und kostet den Haupt-Thread wenig.

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

2. Entities und Trichter begrenzen

# config/paper-world-defaults.yml
entities:
  spawning:
    despawn-ranges:
      monster:
        hard: 96
        soft: 32
  collisions:
    max-entity-collisions: 2
chunks:
  max-auto-save-chunks-per-tick: 8
ticks-per:
  hopper-transfer: 8
  hopper-check: 8

Trichterketten sind auf Survival-Welten regelmäßig der zweitgrößte Tick-Fresser nach Mob-Farmen. Setze zusätzlich spigot.yml mit sinnvollen entity-activation-range-Werten und begrenze gestapelte Items pro Chunk.

3. Plugins entschlacken

• Entferne Plugins mit doppelter Funktion, etwa zwei Systeme für Landschutz oder zwei Chat-Manager.
• Ersetze Plugins, die jeden Tick über alle Spieler iterieren, durch ereignisbasierte Alternativen.
• Halte Dynmap-Renderings auf Nebenzeiten und begrenze die Auflösung.
• Lege Datenbanken auf lokale Speicher statt auf entfernte Endpunkte mit hoher Latenz.

4. Welt vorgenerieren

Chunk-Generierung ist der teuerste Vorgang überhaupt. Ein Werkzeug wie Chunky erzeugt den Weltradius vorab, sodass erkundende Spieler später nur noch fertige Chunks laden. Kombiniere das mit einer harten Weltgrenze, damit die Region nicht endlos wächst.

chunky radius 5000
chunky start
chunky progress

Datenträger, Netzwerk und Sicherungen als zweite Lagebene

Wenn der Profiler bei writeChunk oder Weltsicherungen ausschlägt, liegt das Problem beim Speicher, nicht bei der CPU. SSD NVMe verkürzt diese Schreibvorgänge auf einen Bruchteil der Zeit klassischer Datenträger, was besonders bei großen Modpack-Welten mit vielen Dimensionen spürbar ist. DDR5 ECC hält zusätzlich die Speicherlatenz niedrig und fängt Bitfehler ab.

Netzwerkseitig stehen 1 Gbit/s bereit, und der Anti-DDoS-Schutz ist dauerhaft aktiv, ohne dass du etwas aktivieren musst. Wichtig für die Wahrnehmung: Paketverlust und hohe Latenz fühlen sich für Spieler wie Lag an, obwohl die Tickrate stabil bei 20 liegt. Prüfe deshalb immer beide Ebenen getrennt.

Automatische Sicherungen legst du auf Zeiten mit wenig Aktivität, weil das Kopieren der Weltordner kurzfristig I/O bindet. Über das NexusPanel steuerst du Zeitplan, Konsole und WebFTP an einer Stelle. Dieselbe Logik gilt übrigens für andere Sandbox-Titel, die du unter Alle unsere Gameserver findest.

Wer mehrere Instanzen parallel betreibt, sollte die Tickrate jeder Welt einzeln protokollieren statt eine Gesamtstatistik zu betrachten. Weitere Anleitungen zu Konfiguration und Administration sammeln wir im Nexus Games Blog.

Fazit

Miss zuerst, ändere danach. Starte spark, lies MSPT unter realer Last und suche den größten Block im Aufrufbaum. In neun von zehn Fällen liegt die Ursache bei Sichtweite, Entity-Masse oder einem einzelnen Plugin, nicht beim Speicher. Der häufigste Fehler ist, blind mehr RAM zuzuweisen: Das verlängert die GC-Pausen und verdeckt das eigentliche Problem. Priorisiere Taktrate und Cache der CPU, dann bleibt die Tickrate stabil.

FAQ

Was bedeutet die Konsolenmeldung "Can't keep up! Is the server overloaded?"

Diese Warnung erscheint, wenn ein Tick deutlich länger als 50 Millisekunden gedauert hat und der Server die verlorene Zeit überspringt. Einzelne Meldungen nach einem Neustart oder während einer Weltsicherung sind normal. Häuft sich die Zeile im laufenden Betrieb, liegt eine dauerhafte Überlast vor: Prüfe Entity-Zahlen, Chunk-Ladeaktivität und die Schreibgeschwindigkeit des Datenträgers.

Wie viele Spieler verträgt eine Welt mit 4 GB zugewiesenem Speicher?

Bei Paper ohne schwere Plugins und mit Sichtweite 8 sind ungefähr 20 bis 30 gleichzeitige Spieler realistisch, sofern sie sich nicht alle in derselben Region aufhalten. Entscheidend ist weniger die Spielerzahl als die Zahl geladener Chunks und aktiver Entities. Zehn Spieler mit je einer laufenden Mob-Farm belasten den Haupt-Thread stärker als dreißig Spieler an einem gemeinsamen Spawn.

Bringt eine neuere Java-Version eine bessere Tickrate?

Ja, in messbarem Umfang. Aktuelle Minecraft-Versionen setzen Java 21 voraus, und der darin enthaltene G1GC arbeitet mit kürzeren Pausen als ältere Laufzeitumgebungen. Zusätzlich nutzt Paper die Vector-API, die erst ab Java 21 sauber verfügbar ist. Wechsle die Laufzeitumgebung in den Startparametern deiner Instanz, starte neu und beobachte MSPT über mindestens eine volle Spielsitzung.