Wie viel RAM benötigt ein Minecraft-Server?
Schätze den RAM-Bedarf für Minecraft-Server mit Java, Paper und Mods.
Du hostest einen Server für Freunde auf einem PC mit 8 GB RAM. In das Startskript -Xmx8G einzutragen, liegt nahe: 8 GB RAM sind da, also soll Java auch 8 GB nutzen. Dann fallen dir Windows, der Browser und – falls du auf demselben PC mitspielst – der Minecraft-Client ein. Noch bevor jemand beigetreten ist, fehlt dem System der nötige Spielraum zur Speicherverteilung. Das Problem liegt manchmal nicht am Server selbst, sondern an dieser einen Zeile.
Betrachte die Ergebnisse für „Empfohlener Java-Heap“ und „Erforderlicher Gesamtarbeitsspeicher“ im Rechner separat. Ersteren nutzt du für -Xmx. Letzterer gibt an, wie viel RAM auf dem PC oder dem gemieteten Server physisch vorhanden sein sollte. Ohne diese Unterscheidung würde ich niemals pauschal sagen: „8 GB reichen aus“. Die Spieleranzahl allein liefert diese Antwort nicht.
Zehn Spieler bedeuten nicht immer dieselbe Last
Am Spawn treffen vs. über die Karte verteilen
Gib bei der Spieleranzahl nicht die registrierten Accounts ein, sondern die Personen, die gleichzeitig online sind. Wenn zehn Spieler rund um den Spawn ihre Basis bauen, greifen sie auf dieselben Chunks zu. Sobald sie sich mit der Elytra in alle Himmelsrichtungen verteilen, ändert sich das Bild: Der Server muss einerseits neue Bereiche laden und andererseits Terrain generieren, das zuvor noch niemand gesehen hat. Zehn Spieler am Anfang des Abends erzeugen nicht dieselbe RAM-Last wie zehn Spieler am Ende.
Bei der Berechnung schaue ich mir das Spielverhalten der Gruppe an. Wenn sich alle in einem gemeinsamen Areal aufhalten, ist die Auswahl „Überwiegend im selben Bereich“ passend. Wenn sich in einer Survival-Welt jeder in seine eigene Basis zurückzieht, trifft „In verschiedenen Bereichen / weiß nicht“ eher zu. Findet zudem intensive Erkundung statt, aktiviere diese Option separat – der Rechner schlägt dann 25 Prozent auf die Chunk-Last auf. Die Spieleranzahl einfach pauschal auf zwanzig zu erhöhen, nur um auf der sicheren Seite zu sein, verschleiert lediglich, woher der eigentliche Unterschied rührt.
Prüfe außerdem Sichtweite und Simulationsweite in der Datei server.properties. Die Sichtweite bestimmt den Bereich, der an die Spieler gesendet wird; die Simulationsweite legt fest, in welchem Umkreis Mobs und Spielereignisse aktiv berechnet werden. Beim ersten Aufrufen des Formulars sind 8 und 6 Chunks voreingestellt. Bei Berechnungen für moderne Versionen ist der größere der beiden Werte ausschlaggebend. Erhöhst du bei einer Sichtweite von 8 die Simulationsweite von 6 auf 7 Chunks, bleibt der RAM-Bedarf möglicherweise unverändert – für die Tick-Last gilt das allerdings nicht. Im Profil „1.17 und älter“ ignoriert das Tool die Simulationsweite komplett.
Die Plugin-Anzahl nicht isoliert betrachten
Für Paper, Purpur und Spigot trägst du die Anzahl der Plugins und deren durchschnittliche Auslastung ein; bei Fabric, Forge und NeoForge ist stattdessen die Mod-Anzahl relevant. Bei Vanilla berücksichtigt der Rechner diese Eingaben gar nicht. Verstehe Optionen wie „Leicht / Mittel / Schwer“ nicht als exakt gemessenen RAM-Verbrauch einzelner Plugins: Zehn schlanke Permission-Plugins lassen sich keineswegs mit einem Plugin vergleichen, das im Hintergrund Karten rendert.
Wenn ich ein Modpack installiere, suche ich zuerst nach der Heap-Empfehlung der Entwickler für den Server. Falls vorhanden, trage diesen Wert unter „RAM-Empfehlung des Modpacks verwenden“ ein – das Tool unterschreitet diese Zahl nicht. Übernimm hier keinesfalls die Empfehlung für den Client; es handelt sich um zwei völlig unterschiedliche Spielprozesse. Lässt sich die Last des Packs schwer einschätzen, vergleiche die Ergebnisse für „Mittel“ und „Schwer“. Die Differenz hilft bei der Entscheidung über ein größeres Hosting-Paket mehr als die reine Mod-Anzahl.
Welche Werte gehören an welche Stelle im Rechner?
Wenn du einen neuen Server aufsetzt, wähle „RAM-Bedarf berechnen“; möchtest du prüfen, ob dein vorhandener PC ausreicht, nutze „Meinen Computer prüfen“. Die Serverberechnung ist bei beiden Wegen identisch. Was hierbei am leichtesten übersehen wird, sind die Standardwerte des Formulars: Es startet mit Paper und 10 vorkonfigurierten Plugins. Läuft dein Setup komplett ohne Plugins, setze die 10 auf 0 zurück. Passe anschließend Version, Sichtweite und gegebenenfalls Simulationsweite an deine tatsächliche Serverkonfiguration an. Wenn du komplexe Farmen, Redstone, eine Webkarte oder zusätzliche Welten planst, wechsle in die erweiterten Einstellungen. Aktiviere Optionen aber nicht einfach nur, weil das Häkchenfeld vorhanden ist.
Der Sicherheitspuffer ist standardmäßig auf 25 Prozent eingestellt. In den erweiterten Einstellungen lässt er sich zwischen 10 und 100 Prozent anpassen. Sobald du diese Einstellungen wieder schließt, werden zusätzliche Lastfaktoren aus der Berechnung entfernt und der Puffer wird wieder auf 25 Prozent zurückgesetzt. Wenn dir in einem Durchlauf 6 GiB und im nächsten 9 GiB angezeigt werden, prüfe zuerst, welche Schalter aktiv sind. Notiere dir neben dem Ergebnis am besten die gewählten Eingaben – so musst du bei Abweichungen nicht wieder ganz von vorn anfangen.
8 GB entsprechen rund 7,45 GiB. Wenn im Angebot deines Hosters GB angegeben sind, trage auch im Formular GB ein. Falls eine virtuelle Maschine oder ein Container nur auf einen Teil des physischen Arbeitsspeichers zugreifen kann, gib als Limit genau diesen Teil an. Man wiegt sich schnell in falscher Sicherheit nach dem Motto: „Ich habe 8 eingegeben und 8 erhalten“. Wurden auf beiden Seiten unterschiedliche Einheiten gewählt, gerät der Vergleich von Anfang an in Schieflage – insbesondere dann, wenn das Ergebnis knapp an einer halben GiB-Grenze liegt.
Die zwei RAM-Ergebnisse auf dem Bildschirm
Den Heap-Wert nicht mit der Gesamtkapazität der Maschine verwechseln
Der Java-Heap ist die Obergrenze des Speichers, den der Server für Java-Objekte nutzen darf. Der Gesamtarbeitsspeicher berücksichtigt darüber hinaus auch das Betriebssystem und den Speicher, den Java außerhalb des Heaps belegt. Der Rechner kalkuliert für diesen zusätzlichen Java-Overhead mindestens 1 GiB ein. Liegen 15 Prozent des Heaps darüber, wird dieser höhere Wert angesetzt und das Gesamtergebnis anschließend auf den nächsten halben GiB aufgerundet. Werden 3,5 GiB Heap ausgegeben, entspricht der generierte Startparameter -Xmx3584M genau diesem Wert. Verwechsle bei der Wahl eines Hosting-Pakets den -Xmx-Wert keinesfalls mit dem insgesamt benötigten RAM des Pakets.
Teste folgendes Setup: Paper mit 10 Spielern, moderne Version, 8 Chunks Sichtweite, 6 Chunks Simulationsweite, 10 Plugins bei mittlerer Auslastung. Sind die erweiterten Einstellungen und Chunky deaktiviert, ermittelt das Tool 3,5 GiB Heap und 6,5 GiB Gesamtspeicher. Auf einem Linux-System ohne Desktop-Oberfläche mit 8 GiB RAM geht diese Rechnung auf, solange keine weiteren ressourcenhungrigen Dienste laufen. Stelle dir nun Windows und den Minecraft-Client auf demselben PC vor: Weist man anderen Anwendungen 1 GiB und dem Client 4 GiB zu, steigt der Gesamtbedarf auf 13,5 GiB. Hier reicht die 8-GiB-Maschine nicht mehr aus – und zwar noch bevor wir Paper auch nur ein einziges Plugin hinzugefügt haben. Es sind die übrigen Prozesse, die den RAM aufzehren.
Die Systemprüfung kalkuliert für Headless-Linux einen Betriebssystem-Overhead von 2 GiB ein, für Linux mit Desktop-Umgebung 3 GiB sowie für Windows und macOS jeweils 4 GiB. Bei Containern wird der OS-Overhead des Hostsystems nicht eingerechnet. Laufen im Hintergrund weitere Dienste, musst du deren Speicherbedarf im Feld „Andere Anwendungen“ eintragen. Reicht die Kapazität der Maschine nicht aus, staucht der Rechner den Heap nicht automatisch zusammen – er weist das Speicherdefizit stattdessen transparent aus.
Der Wechsel von Vanilla zu Modpacks
Nehmen wir erneut 10 Spieler und Einstellungen von 8/6 Chunks: Bei Vanilla ergeben sich 3 GiB Heap und 6 GiB Gesamtspeicher. Ergänzt man Paper um 10 Plugins mit mittlerer Last, landet man bei 3,5 und 6,5 GiB. Ein Fabric-Setup mit 50 Mods mittlerer Last veranschlagt 5 und 8 GiB, während das entsprechende Forge-Szenario 6 und 9 GiB ausgibt. Ich würde diese Werte nicht pauschal so interpretieren, dass Fabric in jeder Situation leichtgewichtiger als Forge sei: Sobald sich die Mod-Zusammensetzung ändert, verschiebt sich auch der Vergleich. Die Zahlen zeigen lediglich, wie sich der Rechner bei identischen Eingabewerten verhält.
Bleiben die Spieler im Paper-Beispiel im selben Gebiet, siehst du 3 GiB Heap und 6 GiB Gesamtspeicher. Verteilen sie sich und erkunden neues Terrain, sind es 4 und 7 GiB – bei denselben 10 Spielern. Aus diesem Grund verlasse ich mich nicht allein auf Faustregeln wie „so viel RAM pro Spieler“. Kommen noch ressourcenintensive Farmen, eine Webkarte, Custom-Weltgenerierung und zwei zusätzliche aktive Welten hinzu, klettert dieselbe Konfiguration auf 6 GiB Heap und 9 GiB Gesamtarbeitsspeicher. Statt alle vier Optionen gleichzeitig zu aktivieren und das Ergebnis zu beobachten, empfiehlt es sich, sie einzeln auszuprobieren: Nur so siehst du genau, welcher Faktor die Berechnung in die Höhe treibt.
Chunky-Berechnung und Diagnose im laufenden Serverbetrieb
In Chunky wählst du zunächst den Weltnamen, das Zentrum, die Form und den Radius. Bei einem Quadrat beträgt die Fläche 4 × Radius², bei einem Kreis π × Radius². Da ein Chunk 16 × 16 Blöcke umfasst, teilt der Rechner die Fläche durch 256. Liegt das Zentrum bei 0, 0 und der quadratische Radius bei 3000 Blöcken, entspricht das 140.625 Chunks. Wurde die Hälfte bereits vorab generiert, verbleiben 70.313. Verdoppelt man den Radius auf 6000 Blöcke, sind es 562.500 Chunks: Ein Aufschlag von 3000 Blöcken verdoppelt den Arbeitsaufwand keineswegs, sondern vervierfacht die Fläche. Überprüfe die Zahl im Radius-Feld daher lieber noch einmal.
Aktiviert man Chunky, steigt die Heap-Empfehlung unseres Paper-Beispielservers auf 4 GiB und der Gesamtspeicher auf 7 GiB. Um Festplattenplatz und Dauer einzuschätzen, bietet sich ein kurzer Probelauf an: Trägt man 10.000 neu generierte Chunks, 256 MiB Speicherzuwachs und eine Dauer von 300 Sekunden ein, kalkuliert das Tool für die verbleibenden 140.625 Chunks rund 3,52 GiB Speicherplatz und eine Laufzeit von etwa 1,17 Stunden. Bei der Weltgenerierung bleibt die Geschwindigkeit nicht zwingend konstant. Backups oder Cache-Dateien von Webkarten sollten keinesfalls in diese Messung einfließen. Lies den Weltnamen und den Radius vor dem Absenden des Befehls noch einmal gründlich gegen: Eine Null zu viel schlägt sich drastisch in Zeit und Speicherplatz nieder.
Der Server läuft, die Spieler verteilen sich und die TPS brechen ein: Erhöhe jetzt nicht voreilig -Xmx. TPS beziffert die Spiel-Updates pro Sekunde (Ticks Per Second), während MSPT die Millisekunden pro Tick angibt. Mit /spark tps behältst du beide Werte im Blick. Erstellst du während Lastspitzen ein Spark-Profil, lässt sich präzise analysieren, ob die Zeit durch Weltgenerierung oder Plugins verloren geht. Den Druck auf die Garbage Collection kannst du direkt aus den GC-Daten ablesen. Stürzt ein Server mit einem OutOfMemory-Fehler (OOM) ab, sind das RAM-Limit und -Xmx die ersten Anlaufstellen. Wenn die TPS jedoch einbrechen, obwohl noch Speicher frei ist, werfe ich zuerst einen Blick auf die Profiler-Ausgabe – und denke erst danach über ein größeres RAM-Upgrade nach.