Wie viel RAM braucht ein Minecraft-Server?

Die kurze Antwort

Zwei Quellen liefern zwei Arten von Zahlen. Das Minecraft Wiki listet, was ein Vanilla-Server mit Standardeinstellungen und einer neu generierten Welt braucht. Das Paper-Team empfiehlt, was ein Paper-Server bekommen sollte, um gut zu laufen, unabhängig von der Spielerzahl.

Die Werte aus dem Wiki sind eine Untergrenze für eine frische Welt. Welten wachsen, Spieler verteilen sich, und Plugins bringen ihre eigenen Daten mit, also braucht ein öffentlicher Server, der monatelang läuft, mehr. Eine praktische Entscheidungshilfe:

• Kleiner Vanilla- oder Paper-Server für Freunde: 4 GB Serverspeicher decken den Wert des Wikis für 10 oder mehr Spieler ab, wobei etwa 2,5 bis 3 GB an Java gehen. Das Paper-Team würde ihm mehr geben, wenn du kannst.
• Paper-Server mit Plugins und wachsender Welt: Folge der Empfehlung von Paper und plane einen Heap von 6 bis 10 GB ein, also einen Server mit 8 bis 12 GB.
• Gemoddeter Server: Nimm den Wert, den der Autor des Modpacks veröffentlicht. Es gibt keine allgemeine Regel, weil ein einzelner Mod mehr brauchen kann als das gesamte Vanilla-Spiel.

Paper warnt auch vor dem umgekehrten Fehler: Ab einem gewissen Punkt bringt mehr Speicher immer weniger, und 32 GB RAM für einen Server zu kaufen ist größtenteils verschwendetes Geld.

Was den Speicher füllt

Das Wiki beziffert ein einzelnes Spielerobjekt auf etwa 50 bis 100 MB und ergänzt, dass der Server pro Spieler oft deutlich mehr zuweisen muss, weil jeder Spieler einen Bereich der Welt um sich herum geladen hält. Eine wachsende Welt und hohe Sichtweiten erhöhen den Speicherverbrauch. Dazu kommen Entities (Mobs, Items, Loren), Daten von Plugins und Mods sowie der eigene Arbeitsbereich von Java.

Java-Speicher verhält sich außerdem nicht wie ein einfacher Zähler. Minecraft erzeugt und verwirft jede Sekunde eine riesige Zahl kurzlebiger Objekte, und der Garbage Collector räumt sie in Zyklen auf. Die Paper-Dokumentation nennt eine Allokationsrate von mindestens 800 MB pro Sekunde auf einem Server mit 30 Spielern. Ein zu kleiner Heap lässt den Collector ständig laufen, und diese Pausen zeigen sich als Lag.

Lag kommt meist von der CPU, nicht vom RAM

Das Spiel berechnet seine Weltsimulation in Ticks, 20 pro Sekunde. Damit hat jeder Tick 50 Millisekunden. Laut Wiki erledigt der Server den Großteil dieser Arbeit auf einem Kern und nutzt andere Kerne nur für Nebenaufgaben, also entscheidet die Geschwindigkeit eines einzelnen Kerns, wie viel er schafft, bevor Ticks länger als 50 ms dauern und die Welt langsamer wird. Große Mengen an Mobs und komplexe Redstone-Schaltungen sind die üblichen Ursachen.

Deshalb behebt mehr RAM selten Lag auf einem Server, der schon genug hat. Wenn /mspt hoch ist, während beim Speicher noch Luft ist, brauchst du einen schnelleren Kern oder weniger Arbeit pro Tick, nicht mehr Gigabytes. Manche Plugins verlagern ihre eigene Arbeit auf andere Kerne; das Wiki rät, die Dokumentation eines Plugins zu lesen, bevor du es installierst.

Sichtweite und Simulationsdistanz

Zwei Einstellungen in server.properties legen fest, wie viel der Welt jeder Spieler beschäftigt hält. Beide werden in Chunks als Radius um den Spieler gemessen, beide stehen standardmäßig auf 10, und beide akzeptieren 3 bis 32, wie in der server.properties-Referenz aufgeführt.

• view-distance legt fest, wie viele Weltdaten der Server an den Spieler sendet. Das kostet vor allem Speicher und Bandbreite.
• simulation-distance legt fest, bis zu welcher Entfernung vom Spieler lebende Entities noch aktualisiert werden. Das kostet bei jedem Tick CPU.

Die Fläche wächst mit dem Quadrat des Radius, deshalb ist die Ersparnis größer, als die Zahlen vermuten lassen: Von 10 auf 6 zu gehen verkleinert die Fläche auf ungefähr ein Drittel. Wenn du die Simulationsdistanz niedriger als die Sichtweite hältst, sehen Spieler weit, während der Server nur den nahen Bereich berechnet:

# server.properties (both default to 10, allowed range 3 to 32)
view-distance=8
simulation-distance=6

Heap-Größe im Vergleich zum Serverspeicher

Der Wert -Xmx legt die maximale Größe des Java-Heaps fest. Er ist nicht der gesamte Speicher, den der Prozess nutzt. Java braucht zusätzlich Speicher für eigene Strukturen, Threads und Puffer, und auch das Betriebssystem braucht Speicher. Wenn du dem Heap alles gibst, was der Server hat, kann der Out-of-Memory-Killer von Linux den Serverprozess ohne Vorwarnung beenden.

Die Paper-Dokumentation nennt die Regel: Setze -Xmx und -Xms etwa 1000 bis 1500 MB unter den Speicher, den du hast. Bei 8 GB nimmst du 6500 MB. Setze beide auf denselben Wert: Paper erklärt, dass man ohnehin damit rechnen sollte, dass der Server den ganzen Heap nutzt, und Speicher, der unterhalb von -Xmx frei bleibt, wird nicht genutzt.

Wenn du -Xmx gar nicht setzt, wählt Java einen Standardwert abhängig vom System, und in einem Container liest es das Speicherlimit des Containers aus, wie die Referenz des java-Befehls beschreibt. Der Standardwert ist für einen Gameserver selten das, was du willst, also setz ihn immer.

Aikar's Flags

Paper veröffentlicht eine Reihe von Garbage-Collector-Einstellungen, bekannt als Aikar's Flags, abgestimmt auf das Allokationsmuster von Minecraft. Sie nutzen den G1-Collector, geben ihm eine größere Young Generation, damit kurzlebige Objekte aufgeräumt werden, bevor sie in die Old Generation übergehen, reservieren mit AlwaysPreTouch vorab Speicher und hindern Plugins mit DisableExplicitGC daran, vollständige Collections zu erzwingen. Laut seinem Einstiegsleitfaden braucht Paper Java 25 oder neuer, also prüf zuerst die Version:

# Paper needs Java 25 or newer
java -version

# 8 GB server: heap 6500 MB, Aikar's flags (Paper docs)
java -Xms6500M -Xmx6500M -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 \
  -Dusing.aikars.flags=https://mcflags.emc.gs -Daikars.new.flags=true \
  -jar paper.jar --nogui

Pass nur die beiden Speicherwerte an deinen Server an. Die Paper-Dokumentation verlinkt außerdem einen Skriptgenerator, der dir dieses Startskript schreibt. Dieselbe Seite beschreibt -XX:+UseTransparentHugePages als Experiment für fortgeschrittene Nutzer, nur zusammen mit AlwaysPreTouch, und sagt, dass das Paper-Team die Wirkung auf Minecraft nicht gemessen hat. Lass es weg, es sei denn, du willst es selbst messen.

Wenn du Speicherprobleme vermutest, schalte das Garbage-Collection-Logging ein. Paper merkt an, dass es die Performance nicht beeinträchtigt und die Logdateien bei etwa 5 MB bleiben:

# add to the java line (Java 11 and newer) to log garbage collection
-Xlog:gc*:logs/gc.log:time,uptime:filecount=5,filesize=1M

Erst messen, dann aufrüsten

Paper hat Befehle für die beiden Zahlen, auf die es ankommt, aufgeführt in seiner Befehlsreferenz:

/tps     # ticks per second over 1, 5 and 15 minutes (target 20.0)
/mspt    # milliseconds per tick over 5, 10 and 60 seconds (keep under 50)
/spark   # Paper's built-in profiler, which supersedes both

# total and available memory on the server, in MB
free -m

# resident memory of the Java process, in KB
ps -o pid,rss,args -C java

• TPS unter 20 und MSPT über 50, Speicher in Ordnung: Die CPU ist die Grenze. Senke simulation-distance, finde schwere Farmen oder Plugins mit /spark oder wechsle auf einen schnelleren Kern.
• Collections laufen ständig, oder der Prozess wird beendet: Der Heap ist zu klein oder zu nah am Gesamtspeicher des Servers gesetzt. Behebe zuerst den Abstand, dann füg Speicher hinzu.
• Beides in Ordnung, aber Spieler melden Lag: Prüf den Netzwerkpfad und die eigene Verbindung des Spielers, bevor du am Server etwas änderst.

Keine Sorge, wenn ps zeigt, dass der Java-Prozess mehr als -Xmx nutzt. Dieses Mehr ist der Speicher, den Java außerhalb des Heaps braucht, und genau der Grund für den Abstand von 1000 bis 1500 MB. Mit -Xms gleich -Xmx und aktivem AlwaysPreTouch belegt der Prozess außerdem schon beim Start seinen vollen Heap, also ist eine hohe Zahl direkt nach dem Booten normal und kein Zeichen für ein Leck. Beobachte stattdessen, wie sich die Zahl über Stunden Spielzeit verändert.

Minecraft bei Evorxa

Das Minecraft-Hosting von Evorxa läuft auf VPS-Tarifen mit geteilten Kernen und VDS-Tarifen mit dedizierten High-Frequency-Kernen; die zweite Art passt zur Single-Thread-Last von Minecraft. Tarife beginnen bei $2.99 im Monat, werden monatlich, für sechs Monate oder jährlich im Voraus bezahlt und geben dir Root- und SSH-Zugriff, um die Flags oben zu setzen. Die Server laufen in einer Region, Eygelshoven in den Niederlanden, und ein schlichtes Linux-Image ist meist in etwa einer Minute bereit.

Quellen

Die Fakten in dieser Anleitung stammen von diesen Seiten.

1. Minecraft Wiki: Serveranforderungen
2. Minecraft Wiki: server.properties
3. Paper-Dokumentation: Aikar's Flags
4. Paper-Dokumentation: Erste Schritte
5. Paper-Dokumentation: Befehle
6. Oracle: der java-Befehl