Wie viel RAM braucht ein Minecraft Server

"Wie viel RAM brauche ich?" ist die haeufigste Frage beim Minecraft Server Hosting. Die Standardantwort lautet "kommt drauf an" - technisch korrekt, aber voellig nutzlos. Schauen wir uns das Thema richtig an - mit echten Zahlen, Tabellen und konkreten Empfehlungen.

Grundanforderungen: Vanilla vs Mods

Ein Vanilla Minecraft Server auf 1.20+ verbraucht beim Start etwa 1-1.5 GB RAM. Das ist ohne einen einzigen Spieler - nur Welt laden, Spawn-Chunks und Kernsysteme.

Paper/Spigot optimieren den Speicherverbrauch und starten unter gleichen Bedingungen mit 800 MB - 1.2 GB. Der Unterschied ist im Leerlauf klein, waechst aber deutlich unter Last.

Forge mit 30-50 Mods startet bei 2-3 GB. Schwere Modpacks wie All the Mods 9 oder FTB Revelation brauchen problemlos 4-6 GB allein zum Hochfahren. Fabric liegt irgendwo dazwischen - der Grundverbrauch ist naeher an Paper, aber Mods wie Create oder Sodium treiben ihn spuerbar hoch.

Erste Regel: Rechne vom Startverbrauch aus, nicht von Null. Ein Server, der 2 GB zum Starten braucht, benoetigt bei 20 Spielern ganz andere Werte als einer, der mit 800 MB startet.

RAM pro Spieler

Eine universelle Formel gibt es nicht, aber es gibt gut getestete Naeherungswerte.

Fuer Paper/Spigot:

Jeder Spieler fuegt etwa 50-80 MB zum Verbrauch hinzu
Geladene Chunks sind der Hauptverbraucher, ca. 10-15 MB pro Chunk im Speicher
Standard view-distance=10 bedeutet 441 Chunks pro Spieler (21x21)
Bei view-distance=6 sind es nur 169 Chunks - fast 3x weniger

Fuer Forge/Fabric mit Mods:

Pro Spieler fallen 100 bis 300 MB an, je nach Modpack
Mods mit eigenen Dimensionen (RFTools Dimensions, Compact Machines) koennen den Verbrauch schlagartig erhoehen
Tile Entities von Tech-Mods (Applied Energistics, Mekanism) sind speicherhungrig

Empfehlungstabelle

Spieler	Paper/Spigot	Forge (leicht)	Forge (schwer)	Fabric + Mods
1-5	2-3 GB	4-5 GB	6-8 GB	3-4 GB
5-15	3-5 GB	5-7 GB	8-10 GB	4-6 GB
15-30	5-7 GB	7-10 GB	10-14 GB	6-8 GB
30-50	7-10 GB	10-14 GB	14-18 GB	8-12 GB
50-100	10-14 GB	-	-	12-16 GB
100+	14-20 GB	-	-	-

Forge mit schweren Modpacks skaliert schlecht ueber 30 Spieler hinaus. Das ist keine RAM-Beschraenkung - es ist Javas Single-Thread-Natur. Dazu spaeter mehr.

Diese Zahlen gelten fuer Standardkonfigurationen. Wenn du die view-distance auf 6 reduziert, Entity-Tracking jenseits von 48 Bloecken deaktiviert und Paper fuer aggressives Chunk-Unloading konfiguriert hast, kannst du diese Werte um 20-30% senken.

Warum mehr RAM nicht immer besser ist

Ein haeufiger Irrtum: "Ich kaufe 32 GB, weise alles zu, und der Server fliegt." In der Praxis schafft das ein schlimmeres Problem als Speichermangel - lange Garbage-Collection-Pausen.

Java verwendet einen Garbage Collector (GC) zur Bereinigung ungenutzten Speichers. Bei G1GC, dem Standard-Collector fuer Minecraft, scannt der GC periodisch den gesamten zugewiesenen Heap und entfernt Objekte, auf die nichts mehr verweist.

Je groesser der Heap, desto laenger dauert dieser Scan. Bei 32 GB kann eine Major GC 2-5 Sekunden dauern. Waehrend dieser Zeit friert der Server ein. TPS faellt auf Null. Spieler sehen Lag-Spikes. Alles steht still, bis der GC fertig ist.

Bei 8-12 GB bleiben GC-Pausen typischerweise bei 50-150 ms - Spieler merken das nicht einmal. Das ist die zentrale Erkenntnis: Genug Speicher ist besser als zu viel Speicher.

Faustregel: Weise 15-25% mehr zu als dein Server unter Spitzenlast tatsaechlich verbraucht. Nicht 2-3x mehr.

Aikars JVM-Flags erklaert

Aikar (ein Paper-Entwickler) hat einen Satz JVM-Flags zusammengestellt, die speziell fuer Minecraft Server optimiert sind. Das ist keine Magie - es ist die Abstimmung von G1GC-Parametern auf Minecrafts spezifische Lastmuster.

Fuer Server mit 8 GB oder weniger:

java -Xms8G -Xmx8G \
  -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 \
  -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 \
  -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -jar server.jar

Fuer Server mit 12 GB oder mehr:

java -Xms12G -Xmx12G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC \
  -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=40 \
  -XX:G1MaxNewSizePercent=50 \
  -XX:G1HeapRegionSize=16M \
  -XX:G1ReservePercent=15 \
  -XX:G1MixedGCCountTarget=4 \
  -XX:InitiatingHeapOccupancyPercent=20 \
  -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 \
  -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -jar server.jar

Was die wichtigsten Flags bewirken:

-Xms und -Xmx gleich gesetzt - weist den gesamten Speicher sofort zu. Die JVM verschwendet keine Ressourcen fuer Heap-Groessenaenderungen
G1NewSizePercent=40 - vergroessert die Young Generation. Minecraft erzeugt massenhaft kurzlebige Objekte (Pakete, Tick-Daten, Koordinaten), und eine groessere Young Gen sammelt diese guenstig ein
G1HeapRegionSize=16M - groessere Regionen fuer groessere Heaps. Reduziert den Verwaltungsaufwand
MaxGCPauseMillis=200 - Ziel-Pausenzeit. Der GC versucht, diese einzuhalten, aber es ist keine Garantie
InitiatingHeapOccupancyPercent=20 - startet die Hintergrund-Sammlung frueh, um Notfall-GCs zu vermeiden
AlwaysPreTouch - weist den gesamten Speicher beim Start physisch zu. Eliminiert Latenz durch erstmalige Seitenzugriffe

Wichtig: -Xms und -Xmx muessen gleich sein. Wenn du -Xms2G -Xmx8G setzt, aendert die JVM staendig die Heap-Groesse, was zusaetzliche Latenz verursacht.

Paper vs Forge vs Fabric: Speicherverbrauch

Paper/Spigot/Purpur

Die speichereffizienteste Option. Paper optimiert Chunks, Entities und Tile Entities aggressiv. Wichtige Einstellungen, die den RAM beeinflussen:

paper.yml > max-auto-save-chunks-per-tick - begrenzt gleichzeitige Chunk-Speicherungen
spigot.yml > view-distance - der groesste einzelne Hebel fuer Speicherkontrolle
paper.yml > delay-chunk-unloads-by - wie schnell ungenutzte Chunks entladen werden

Mit richtiger Konfiguration bedient Paper 30 Spieler komfortabel in 6 GB.

Forge

Forge-Server verbrauchen mehr Speicher wegen der Mods. Jeder Mod fuegt eigene Klassen, Registries und Tile Entities hinzu. Konkrete Beispiele:

Applied Energistics 2 mit grossem ME-Netzwerk - bis zu 500 MB zusaetzlich
Mekanism mit vollstaendiger Verarbeitungskette - 200-400 MB
Eigene Dimensionen (RFTools) - bis zu 1 GB pro Dimension
Dynmap/BlueMap - 500 MB-2 GB je nach gerendertem Bereich

Fabric

Fabric selbst ist leichtgewichtig - im Grunde ist es ein Mod-Loader. Der Verbrauch haengt komplett von den installierten Mods ab. Lithium und Starlight reduzieren den Verbrauch. Create und Tech-Mods erhoehen ihn. Im Durchschnitt ist Fabric 15-25% effizienter als Forge bei vergleichbarem Mod-Umfang.

Swap und der OOM-Killer

Swap

Swap ist Festplattenspeicher, den das System als "Reserve-Speicher" nutzt. Fuer einen Minecraft Server ist Swap eine Katastrophe. Wenn die JVM anfaengt, Swap zu nutzen, faellt die Leistung um den Faktor 100-1000 im Vergleich zu RAM.

Empfehlungen:

Verlass dich nie auf Swap als Speicherquelle fuer deinen Server
Behalte Swap fuer Systemprozesse, aber konfiguriere die Swappiness:

# Aktuellen Wert pruefen
cat /proc/sys/vm/swappiness

# Niedrige Swappiness setzen (RAM bevorzugen statt Swap)
sudo sysctl vm.swappiness=10

# Ueber Neustarts hinweg speichern
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf

Mit swappiness=10 nutzt das System Swap nur als letzten Ausweg. Das haelt den Java-Prozess im physischen RAM statt auf die Festplatte auszulagern.

OOM-Killer

Wenn dem System der Speicher komplett ausgeht, startet der Linux-Kernel den OOM-Killer, der den Prozess mit dem hoechsten RAM-Verbrauch beendet. Das ist normalerweise dein Minecraft Server.

Anzeichen fuer OOM-Killer-Aktivitaet:

# Pruefen ob ein Prozess gekillt wurde
dmesg | grep -i "out of memory"
dmesg | grep -i "oom-kill"

# Aktuellen OOM-Score des Prozesses anzeigen
cat /proc/$(pidof java)/oom_score

Schutz vor OOM:

Weise dem Server nicht mehr als 80% des verfuegbaren RAM zu
Lass 1-2 GB fuer das Betriebssystem, Disk-Cache und andere Prozesse
Bei einem VPS mit 8 GB - weise dem Server maximal 6 GB zu

Beispiel: VPS mit 16 GB RAM. System und Basisdienste verbrauchen ~1 GB. Disk-Cache braucht ~1-2 GB. Das laesst 12-13 GB fuer Minecraft.

RAM-Monitoring mit spark

spark ist ein Profiler fuer Minecraft Server, der detaillierte Echtzeit-Speichernutzung anzeigt. Installiere es als Plugin (Paper) oder Mod (Forge/Fabric).

Grundlegende Befehle:

/spark health         - allgemeine Server-Info
/spark heapdump       - vollstaendiger Heap-Dump zur Analyse
/spark heapsummary    - kurze Speichernutzungs-Zusammenfassung
/spark gc             - Garbage-Collector-Statistiken

Worauf du achten solltest:

GC-Haeufigkeit: Wenn Minor GC alle 2-3 Sekunden laeuft, ist alles normal. Wenn Major GC haeufiger als einmal pro Minute stattfindet, fehlt Speicher oder die Young Gen ist zu klein.

GC-Pausendauer: Minor GC sollte 10-50 ms dauern. Major GC sollte 100-300 ms dauern. Wenn Major GC ueber 500 ms liegt, ist der Heap zu gross oder die GC-Einstellungen muessen angepasst werden.

Heap-Nutzung nach GC: Wenn nach einer Major GC mehr als 80% des Heaps belegt sind, fehlt tatsaechlich Speicher. Zeit zum Hochskalieren oder Optimieren.

Top-Verbraucher: heapsummary zeigt welche Objekte am meisten Platz einnehmen. Meist sind es Chunks, Entity, TileEntity oder Plugin-/Mod-Daten.

Automatisches Monitoring:

/spark health --memory

Dieser Befehl zeigt aktuellen Verbrauch, Sitzungs-Peak und Durchschnitt. Notiere die Werte bei Spitzen-Spielerzahlen - das ist dein tatsaechlicher Richtwert fuer die RAM-Zuweisung.

Wann du mehr CPU brauchst statt RAM

Das ist ein haeufiger Fehler: Der Server laggt, der Admin fuegt RAM hinzu, nichts aendert sich. Weil das Problem die ganze Zeit die CPU war.

Der Minecraft Server ist im Haupttick-Loop single-threaded. Ein Tick = 50 ms (20 TPS). Wenn ein Tick nicht in 50 ms abgeschlossen werden kann, sinken die TPS. RAM ist in diesem Szenario irrelevant.

Symptome eines CPU-Engpasses:

TPS unter 20, aber RAM-Nutzung bei 50-60%
spark Profiler zeigt die meiste Zeit in entityTick, chunkTick oder pluginTick
Mehr RAM verbessert die TPS nicht

Symptome von RAM-Mangel:

Haeufige und lange GC-Pausen
TPS faellt periodisch fuer ein bis zwei Sekunden auf 0-5, erholt sich dann
spark gc zeigt Major GC alle 10-30 Sekunden
Server crasht mit OutOfMemoryError

Was tun, wenn die CPU der Engpass ist:

Wechsle zu einem Hoster mit schnellerem Single-Core-Prozessor (Taktfrequenz ist wichtiger als Kernanzahl)
Reduziere die view-distance (senkt sowohl CPU- als auch RAM-Last)
Optimiere Plugins/Mods - einige sind extrem schwer im Tick-Loop
Nutze Paper/Purpur statt Spigot - viele Operationen wurden in asynchrone Threads ausgelagert

Praktische Tipps

Fang klein an. Setze 4 GB, beobachte mit spark eine Woche lang. Erhoehe in 2-GB-Schritten wenn noetig
-Xms = -Xmx. Immer. Ohne Ausnahme
Vergiss das OS nicht. Die JVM ist nicht der einzige Prozess auf der Maschine
View-distance ist der staerkste Hebel. Reduktion von 10 auf 7 spart bis zu 40% RAM
Pregeneriere die Welt. Echtzeit-Chunk-Generierung ist teuer - sowohl fuer CPU als auch RAM
Starte taeglich neu. Java-Server neigen zu Speicherlecks durch Plugins. Ein taeglicher Neustart um 5 Uhr morgens bei minimaler Spielerzahl ist Standardpraxis
Ueberwache statt zu raten. spark ist kostenlos. Nutze es