Java JVM-Flags Optimierung fur Minecraft-Server: Der komplette Leitfaden

Java JVM-Flags Optimierung fur Minecraft-Server: Der komplette Leitfaden

Jeder Minecraft-Server lauft auf der Java Virtual Machine, und die Standard-JVM-Einstellungen sind nicht fur Spieleserver konzipiert. Sie sind fur allgemeine Anwendungen gebaut, die Durchsatz uber Latenz priorisieren. Fur einen Minecraft-Server ist Latenz alles. Eine Garbage-Collection-Pause von 200ms bedeutet einen sichtbaren Lag-Spike, den Spieler sofort spuren. Bei MineGuard haben wir JVM-Konfigurationen fur Hunderte von Servern optimiert, und in diesem Leitfaden teilen wir alles, was wir wissen.

Was JVM-Flags tatsachlich bewirken

Wenn du deinen Server mit java -jar server.jar startest, verwendet die JVM Standardeinstellungen fur Speicherverwaltung, Garbage Collection und Laufzeitoptimierungen. Diese Standards gehen von einer allgemeinen Arbeitslast aus. Minecraft ist nicht allgemein. Es erzeugt und verwirft Millionen kleiner Objekte pro Sekunde (Block-Updates, Entity-Ticks, Paket-Puffer) und braucht konsistentes Tick-Timing ohne Pausen uber 50ms.

JVM-Flags erlauben dir, diese Standards zu uberschreiben. Sie steuern, wie viel Speicher die JVM nutzt, welcher Garbage Collector lauft, wie aggressiv er sammelt, und Dutzende anderer Parameter. Die richtige Kombination kann GC-Pausen um 80% reduzieren und deine TPS auf soliden 20 stabilisieren.

Speicher-Grundlagen: -Xmx und -Xms

Die zwei wichtigsten Flags sind -Xmx (maximale Heap-Grosse) und -Xms (initiale Heap-Grosse). Setze sie immer auf den gleichen Wert:

-Xms8G -Xmx8G

Warum gleich? Wenn -Xms kleiner als -Xmx ist, startet die JVM mit weniger Speicher und vergrossert den Heap dynamisch. Bei jeder Vergrosserung muss die JVM pausieren, um neu zuzuweisen. Indem du sie gleich setzt, eliminierst du diese Resize-Pausen komplett. Die JVM weist allen Speicher beim Start zu und muss nie die Grosse andern.

Wie viel RAM brauchst du?

Hier ist eine praktische Richtlinie basierend auf Spielerzahl und Weltkomplexitat:

  • 1-20 Spieler: 2-4 GB
  • 20-50 Spieler: 4-6 GB
  • 50-100 Spieler: 6-8 GB
  • 100-200 Spieler: 8-12 GB
  • 200+ Spieler: 12-16 GB

Diese Zahlen gehen von Paper oder Purpur mit einer moderaten Plugin-Anzahl (15-30 Plugins) aus. Stark gemoddte Server (Forge/Fabric mit 100+ Mods) konnen 2-4 GB mehr benotigen.

Haufiger Fehler: zu viel RAM zuweisen. Wenn du 32 GB verfugbar hast, setze nicht -Xmx32G. Der Garbage Collector muss den gesamten Heap scannen. Ein grosserer Heap bedeutet langere GC-Pausen. Gib deinem Server, was er braucht, plus 20-30% Reserve, nicht mehr.

Garbage Collection: Das Herz der JVM-Optimierung

Garbage Collection (GC) ist der Prozess, Speicher zu finden und freizugeben, den dein Server nicht mehr nutzt. Die JVM macht das automatisch, aber die Art, wie sie es macht, ist enorm wichtig. Wahrend einer GC-Pause hort dein Server buchstablich auf, Ticks zu verarbeiten.

G1GC (Garbage First Garbage Collector)

G1GC ist der empfohlene Garbage Collector fur Minecraft-Server und das Fundament von Aikars Flags. Er teilt den Heap in Regionen auf und sammelt zuerst die mit dem meisten Mull (daher der Name). Dieser Ansatz bietet vorhersagbare Pausenzeiten.

Warum G1GC gut fur Minecraft funktioniert:

  • Zielt auf eine maximale Pausenzeit (einstellbar uber MaxGCPauseMillis)
  • Arbeitet effizient mit Heaps von 2 bis 16 GB
  • Fuhrt die meiste Arbeit parallel aus, ohne den Server zu stoppen
  • Hervorragend fur Arbeitslasten mit vielen kurzlebigen Objekten (die Minecraft standig erzeugt)

ZGC (Z Garbage Collector)

ZGC ist ein Low-Latency-Collector fur Sub-Millisekunden-Pausen. Klingt perfekt? Nicht ganz. ZGC tauscht Pausenzeit gegen Durchsatz. Er nutzt mehr CPU fur diese winzigen Pausen, und auf Servern mit begrenzten CPU-Kernen kann dieser Overhead die TPS tatsachlich verschlechtern.

ZGC lohnt sich zum Testen, wenn:

  • Du 8+ CPU-Kerne fur den Server hast
  • Dein Heap 16 GB oder grosser ist
  • Du Java 21+ verwendest (ZGC hat sich in neueren Versionen stark verbessert)

Fur die meisten Server wird G1GC mit Aikars Tuning ZGC ubertreffen.

Shenandoah

Shenandoah ist ein weiterer Low-Pause-Collector, ahnlich in den Zielen wie ZGC, aber mit anderem Ansatz. Er ist in OpenJDK-Builds verfugbar (nicht Oracle JDK). Wie ZGC tauscht er CPU gegen Pausenzeit und funktioniert am besten auf Servern mit genugend Kernen.

Unsere Empfehlung: Starte mit G1GC. Wechsle nur zu ZGC oder Shenandoah, wenn du deinen Server mit Spark profiliert und bestatigt hast, dass GC-Pausen dein Engpass sind, und du CPU-Reserve hast.

Aikars Flags: Der Goldstandard

Aikars Flags sind ein Satz JVM-Flags, die speziell fur Minecraft-Server optimiert sind. Sie wurden auf Servern mit Tausenden von Spielern getestet und uber Jahre verfeinert. Hier erklaren wir, was jedes Flag macht:

Die wichtigsten Flags erklart

-XX:+UseG1GC

Aktiviert den G1 Garbage Collector anstelle des Standards.

-XX:+ParallelRefProcEnabled

Verarbeitet Referenz-Objekte (WeakReferences, SoftReferences) parallel statt seriell. Minecraft-Plugins erzeugen viele davon.

-XX:MaxGCPauseMillis=200

Weist G1GC an, eine maximale Pause von 200ms anzustreben. Der Collector passt sein Verhalten an, um unter diesem Ziel zu bleiben.

-XX:+UnlockExperimentalVMOptions

Aktiviert experimentelle Flags, die standardmassig nicht verfugbar sind. Erforderlich fur einige der folgenden Parameter.

-XX:+DisableExplicitGC

Verhindert, dass Plugins System.gc() manuell aufrufen. Einige schlecht geschriebene Plugins tun dies und verursachen unnotige volle GC-Pausen.

-XX:G1NewSizePercent=30
-XX:G1MaxNewSizePercent=40

Weist 30-40% des Heaps der jungen Generation zu (wo neue Objekte erstellt werden). Minecraft erzeugt Tonnen kurzlebiger Objekte, daher bedeutet eine grossere junge Generation weniger haufige GC-Durchlaufe.

-XX:G1HeapRegionSize=8M

Setzt die Grosse jeder G1-Region auf 8 MB. Grossere Regionen reduzieren den Overhead fur grosse Heaps, konnen aber Pausen fur kleine Heaps erhohen. 8M ist der optimale Wert fur 4-16 GB Server.

-XX:G1ReservePercent=20

Reserviert 20% des Heaps als Sicherheitspuffer. Dies verhindert die gefurchteten "to-space exhausted" vollen GC-Pausen, die auftreten, wenn dem Collector freie Regionen ausgehen.

-XX:G1MixedGCLiveThresholdPercent=90

Sammelt eine Region nur, wenn 90% oder mehr davon Mull ist. Dies reduziert die Menge lebender Daten, die wahrend der Sammlung kopiert werden mussen.

-XX:InitiatingHeapOccupancyPercent=15

Startet einen nebenläufigen GC-Zyklus bei 15% Heap-Belegung. Das ist aggressiv (Standard ist 45%), aber es bedeutet, dass der Collector fruh beginnt und mehr Zeit hat, ohne Pause fertig zu werden.

-XX:SurvivorRatio=32

Verkleinert den Survivor-Space. Bei Minecraft-Arbeitslasten sterben Objekte entweder sofort oder leben lange (wie geladene Chunks). Weniger Bedarf, Objekte zwischen Sammlungen zu halten.

-XX:+PerfDisableSharedMem

Deaktiviert das Schreiben von GC-Statistiken in eine Shared-Memory-Datei. Das vermeidet gelegentliche Latenz-Spikes durch Dateisystemoperationen.

-XX:MaxTenuringThreshold=1

Befordert Objekte nach nur 1 GC-Zyklus in die alte Generation. Kombiniert mit der grossen jungen Generation passt das gut zum Allokationsmuster von Minecraft.

GraalVM: Die alternative Laufzeitumgebung

GraalVM ist eine alternative JDK-Distribution mit einem fortschrittlichen JIT-Compiler. Fur Minecraft-Server kann GraalVM 5-15% bessere Leistung bieten im Vergleich zu Standard-OpenJDK, besonders bei rechenintensiven Szenarien wie Weltgenerierung und Redstone-Verarbeitung.

Vorteile von GraalVM:

  • Aggressivere JIT-Optimierung
  • Besseres Method-Inlining
  • Verbesserte Escape-Analyse (reduziert Heap-Allokationen)
  • Verfugbar als Drop-in-Ersatz fur OpenJDK

Um GraalVM zu verwenden, lade es von der offiziellen Website herunter und ersetze deine Java-Installation. Alle Aikar-Flags funktionieren mit GraalVM. Du kannst auch GraalVM-spezifische Flags hinzufugen:

-XX:+UseJVMCICompiler
-XX:+EagerJVMCI

Hinweis: GraalVM Community Edition ist kostenlos. Enterprise Edition bietet zusatzliche Optimierungen, erfordert aber eine Lizenz.

Large Pages

Large Pages (auch Huge Pages genannt) erlauben der JVM, 2 MB Speicherseiten statt der Standard-4-KB-Seiten zu verwenden. Das reduziert TLB-Misses (Translation Lookaside Buffer) und verbessert die Speicherzugriffsleistung um 5-10%.

Um Large Pages zu aktivieren:

  1. OS konfigurieren (Linux): echo "vm.nr_hugepages=4096" >> /etc/sysctl.conf && sysctl -p
  2. JVM-Flag hinzufugen: -XX:+UseLargePages

Die Anzahl benotigter Huge Pages entspricht deiner Heap-Grosse geteilt durch 2 MB. Fur einen 8 GB Heap: 8192 / 2 = 4096 Seiten.

Large Pages erfordern Root-Konfiguration und sind am nutzlichsten auf dedizierten Servern. Wenn du auf Shared Hosting bist, uberspringe diesen Schritt.

String-Deduplizierung

Java-Strings mit identischem Inhalt konnen dedupliziert werden, um Speicher zu sparen. Das ist besonders nutzlich fur Minecraft, weil viele identische Strings im Speicher existieren (Item-Namen, Block-Typen, Chat-Nachrichten).

-XX:+UseStringDeduplication

Dieses Flag hat minimalen CPU-Overhead und kann den Speicherverbrauch um 5-10% reduzieren. Es funktioniert nur mit G1GC, den Aikars Flags verwenden.

Fertige Flag-Sets zum Kopieren

Hier sind einsatzbereite Flag-Sets fur verschiedene Servergrossen. Kopiere den gesamten Block und verwende ihn als Startbefehl.

Kleiner Server (2 GB RAM, 1-20 Spieler)

java -Xms2G -Xmx2G -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=4M -XX:G1ReservePercent=20 -XX:G1MixedGCLiveThresholdPercent=90 -XX:InitiatingHeapOccupancyPercent=15 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 -XX:+UseStringDeduplication -jar server.jar --nogui

Hinweis: G1HeapRegionSize ist auf 4M fur den 2 GB Server gesetzt (kleinerer Heap profitiert von kleineren Regionen).

Mittlerer Server (4 GB RAM, 20-50 Spieler)

java -Xms4G -Xmx4G -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:G1MixedGCLiveThresholdPercent=90 -XX:InitiatingHeapOccupancyPercent=15 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 -XX:+UseStringDeduplication -jar server.jar --nogui

Grosser Server (8 GB RAM, 50-100 Spieler)

java -Xms8G -Xmx8G -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=40 -XX:G1MaxNewSizePercent=50 -XX:G1HeapRegionSize=16M -XX:G1ReservePercent=20 -XX:G1MixedGCLiveThresholdPercent=90 -XX:InitiatingHeapOccupancyPercent=15 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 -XX:+UseStringDeduplication -XX:+UseLargePages -jar server.jar --nogui

Hinweis: G1NewSizePercent auf 40 und G1MaxNewSizePercent auf 50 erhoht fur grosseren Heap. UseLargePages hinzugefugt (erfordert OS-Konfiguration).

Enterprise-Server (16 GB RAM, 200+ Spieler)

java -Xms16G -Xmx16G -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=40 -XX:G1MaxNewSizePercent=50 -XX:G1HeapRegionSize=16M -XX:G1ReservePercent=20 -XX:G1MixedGCLiveThresholdPercent=90 -XX:InitiatingHeapOccupancyPercent=15 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 -XX:+UseStringDeduplication -XX:+UseLargePages -jar server.jar --nogui

Fur 16 GB Server kannst du auch ZGC als Alternative testen:

java -Xms16G -Xmx16G -XX:+UseZGC -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -XX:+UseLargePages -jar server.jar --nogui

ZGC braucht weniger Tuning-Flags, weil er sich selbst anpasst. Teste beide Konfigurationen und vergleiche mit dem Spark-Profiler.

Haufige Fehler

Fehler 1: Zu viel RAM. Ein 32 GB Heap auf einem Server mit 20 Spielern gibt dir langere GC-Pausen, nicht bessere Leistung. Der Garbage Collector muss den gesamten Heap scannen. Halte es kompakt.

Fehler 2: Falscher Garbage Collector. CMS (Concurrent Mark Sweep) war jahrelang die erste Wahl, wurde aber in Java 14 entfernt. Wenn dein Startskript noch -XX:+UseConcMarkSweepGC referenziert, aktualisiere es sofort. G1GC ist die richtige Wahl.

Fehler 3: Unterschiedliche -Xms und -Xmx. -Xms512M -Xmx8G zu setzen bedeutet, dass die JVM den Heap Dutzende Male vergrossern muss, wahrend dein Server ladt, was Ruckler und Pausen in den ersten Minuten verursacht.

Fehler 4: Java 8 verwenden. Java 8 ist veraltet. Jede neue Java-Version bringt GC-Verbesserungen, Sicherheitspatches und Performance-Optimierungen. Verwende mindestens Java 21 LTS. Java 21 hat G1GC und ZGC im Vergleich zu alteren Versionen erheblich verbessert.

Fehler 5: GC-Logs ignorieren. Fuge -Xlog:gc*:file=gc.log:time zu deinen Flags hinzu. Das erstellt eine Log-Datei, die dir genau zeigt, was der Garbage Collector macht. Nutze Tools wie GCViewer oder GCEasy zur Analyse.

Uber die JVM hinaus: Netzwerk-Performance zahlt auch

Du kannst deine JVM perfekt tunen, aber wenn dein Server unter einer DDoS-Attacke oder Bot-Flood steht, spielt das alles keine Rolle. Server-Performance und Netzwerk-Performance sind zwei Seiten derselben Munze.

Bei MineGuard kummern wir uns um die Netzwerk-Seite. Unser Filter arbeitet auf Paket-Ebene, verifiziert Verbindungen und blockiert bosartigen Traffic, bevor er deinen Server erreicht. Der Overhead? Weniger als 1ms zusatzliche Latenz. Deine Spieler werden unseren Schutz nicht bemerken, aber sie werden das Fehlen von Lag-Spikes bemerken, die durch Bot-Floods verursacht werden.

Optimiere deine JVM-Flags fur die innere Performance. Die ausseren Bedrohungen uberlasse uns. Zusammen ergibt das einen Server, der stabile 20 TPS halt, egal was kommt.


Schützen Sie Ihren Server vor DDoS-Angriffen

Kostenloser Schutz mit 5-Minuten-Einrichtung. 1 TB Traffic inklusive.

Kostenlos testen


Weitere Artikel