Wie viel RAM braucht ein Minecraft Server?

Die kurze Antwort: Heap-Größen, die funktionieren

Das sind Heap-Größen, also der Wert, den du der JVM mit -Xmx gibst, nicht die Tarifgröße, die du kaufst. Sie gehen von view-distance 8 und simulation-distance 6 aus, einer vernünftigen Server-Voreinstellung und keiner für Einzelspieler. Nimm sie als Startwert, den du danach misst, denn Weltgröße und wie viel Karte die Spieler geladen halten, verschieben die Zahl stärker als alles andere.

Das Muster dahinter: Von 5 auf 25 Spieler auf Vanilla-Paper kommt etwa 1 GB dazu, während der Wechsel von einem 60-Mod-Pack auf ein 300-Mod-Pack bei gleicher Spielerzahl 5 GB mehr braucht. Mod-Anzahl und Chunk-Fußabdruck dominieren. Die Spielerzahl zählt nur, weil jeder Spieler eine Blase geladener Chunks mit sich herumträgt.

Alles über etwa 12 GB für einen Minecraft Server ist fast immer ein Leak, ein außer Kontrolle geratener Chunk-Loader oder ein Live-Map-Renderer, kein echter Bedarf. Landet deine Rechnung dort, hör auf und profile, statt zu kaufen.

• Vanilla oder Paper, 1 bis 10 Spieler, unter 10 Plugins: 1,5 bis 2 GB Heap
• Paper, 10 bis 25 Spieler, 15 bis 25 Plugins: 2,5 bis 3 GB
• Paper, 25 bis 60 Spieler, volles Plugin-Set, vorgenerierte Map: 4 bis 6 GB
• Leichtes Fabric- oder NeoForge-Pack (40 bis 80 QoL- und Performance-Mods), bis 10 Spieler: 3 bis 4 GB
• Mittelschweres Tech- oder Magic-Pack (150 bis 250 Mods), 5 bis 10 Spieler: 5 bis 6 GB
• Kitchen-Sink-Pack (300+ Mods, im Stil von All the Mods), 5 bis 15 Spieler: 8 bis 10 GB
• Alte Packs für 1.7.10 oder 1.12.2 auf Java 8: plane 20 bis 30 % mehr ein als bei derselben Mod-Anzahl auf einem modernen Pack, und behalte Metaspace extra im Blick

Deine Tarifgröße ist nicht dein -Xmx

Die JVM braucht Speicher außerhalb des Java-Heaps: Metaspace für geladene Klassen, Thread-Stacks für die Dutzenden Threads eines Minecraft Servers, den JIT-Code-Cache, die Verwaltung des Garbage Collectors und Direct Byte Buffers für Netzwerk und Welt-I/O. Auf einem modernen Modded-Server liegt dieser Overhead zwischen 400 MB und 1 GB, und nichts davon deckt -Xmx ab.

Ist dein Container auf 4 GB begrenzt und du setzt -Xmx4G, darf allein der Heap bis an die Grenze wachsen, bevor Speicher außerhalb des Heaps den Container darüber schiebt. Dann beendet der Kernel den Prozess. Du bekommst Exit-Code 137, keinen Java-Stacktrace, keinen OutOfMemoryError im Log und einen Server, der scheinbar einfach zugegangen ist. Das ist der häufigste falsche RAM-Notfall überhaupt.

Die Regel: Setz -Xmx auf die Container-Grenze minus etwa 20 %, mit mindestens 512 MB Puffer. Bei einem Container mit 4 GB liegt der Arbeits-Heap also bei etwa 3 bis 3,2 GB. Der Minecraft-Tarif bei Puranode hat 4 GB. Setz -Xms auf denselben Wert, denn ein fester Heap vermeidet Pausen durchs Vergrößern und lässt G1 seine Regionen einmal festlegen. Panels auf Basis von Pterodactyl liefern oft eine Startzeile, die die volle Container-Größe direkt an -Xmx weitergibt, und das ist genau die Falle von oben. Prüf deine, bevor du etwas annimmst.

Was den Heap wirklich frisst: Chunks, Entities und Force-Loading

Ein verbundener Spieler kostet für sich fast nichts. Speicher kostet die Chunk-Blase, die ihm folgt. Bei view-distance 10 hält ein Spieler (2 x 10 + 1) zum Quadrat, also 441 Chunks geladen. Bei 8 sind es 289, bei 6 sind es 169. Senkst du die Sichtweite von 10 auf 7, fällt etwa die Hälfte des chunkbedingten Heaps pro Spieler weg, und auf einem Survival-Server merken das die meisten Spieler nicht.

Seit 1.18 sind das zwei getrennte Regler. view-distance legt fest, wie weit Chunks gesendet und geladen gehalten werden, das kostet vor allem Speicher und Bandbreite. simulation-distance legt fest, wie weit Chunks tatsächlich ticken, das kostet vor allem CPU. view-distance 10 mit simulation-distance 5 ist ein guter Kompromiss.

Die echten Heap-Fresser sind in der Praxis Block-Entities in dichten Bauten, Mobfarmen, dauerhaft geladene Chunks von Chunk-Loader-Mods, Quarries, große AE2-Netzwerke und Create-Konstruktionen sowie Live-Map-Renderer wie Dynmap oder BlueMap während eines kompletten Renders. Dauerhaft geladene Chunks werden nie entladen. Deshalb kann ein Modded-Server mit 8 Spielern mehr Chunks im Speicher halten als ein Vanilla-Server mit 60. Welchen Loader du nutzt, entscheidet, wie viele Mods du mitschleppst, und unser Vergleich von Paper, Forge und Fabric (auf Englisch) hilft bei der Wahl.

Lies MSPT, bevor du irgendetwas kaufst

Minecraft läuft mit 20 Ticks pro Sekunde, jeder Tick hat also ein Budget von 50 ms. TPS ist ein nachlaufender Wert: Er fällt erst, wenn MSPT über 50 steigt. Ein Server mit 47 ms pro Tick meldet also gesunde 20 TPS und ist trotzdem nur eine Mobfarm von sichtbarem Lag (auf Englisch) entfernt. Beobachte MSPT, nicht TPS.

Auf Paper liefert /mspt Durchschnittswerte über 5, 10 und 60 Sekunden plus ein hohes Perzentil. Das Perzentil ist das, was Spieler spüren. 30 ms im Schnitt mit Spitzen von 120 ms ruckeln deutlich, gleichmäßige 40 ms nicht. Unter 35 ms im Schnitt ist entspannt, 35 bis 45 ist machbar, über 45 ist dein Budget aufgebraucht.

spark ist das Werkzeug, das dir das Warum zeigt. /spark health zeigt TPS, MSPT, CPU-Last und GC-Statistiken auf einem Bildschirm. /spark profiler start, einige Minuten unter echter Spielerlast laufen gelassen und dann gestoppt, liefert einen Aufrufbaum, der das Plugin, die Mod oder das Subsystem nennt, das die Tick-Zeit verbraucht. In aktuellen Paper-Builds ist spark bereits enthalten, und Timings ist veraltet und standardmäßig aus.

Nichts auf diesem Bildschirm wird durch mehr RAM besser. Tick-Zeit ist Arbeit in einem einzigen Thread auf einem CPU-Kern.

Vom Symptom zur Ursache: was dein Lag dir sagt

Fast jede Anfrage nach mehr RAM beschreibt ein Symptom, das RAM nicht lösen kann. Finde heraus, welches du hast, bevor du Geld ausgibst.

Nur zwei Einträge in der Liste unten löst mehr Speicher wirklich: den OutOfMemoryError und ein Live-Set, das auch nach der Garbage Collection hoch bleibt. Alles andere ist CPU-Zeit, Festplattendurchsatz, Netzwerkweg oder Konfiguration, und ein größerer Tarif ändert daran nichts außer deiner Rechnung. Die nützlichste Gewohnheit: Lass das Symptom auftreten, während spark profilet, und lies den Aufrufbaum, statt zu raten. Ein Profil über fünf Minuten unter echter Spielerlast beantwortet die Frage eindeutig. Ein Profil auf einem leeren Server beantwortet gar nichts.

• Ständiges Rubber-Banding, rutschende Mobs, langsame Hopper und Redstone: Tick-Zeit. Mit spark profilen und MSPT prüfen.
• Flüssiges Spiel mit einem Hänger von 1 bis 3 Sekunden alle paar Minuten: Pausen der Garbage Collection, durch Druck auf den Heap oder schlechte GC-Flags.
• Crash-Log mit java.lang.OutOfMemoryError Java heap space: echter Speichermangel im Heap oder ein Leak. Das ist RAM.
• Prozess verschwindet mit Exit-Code 137 und ohne Java-Fehler: Der Container wurde wegen Speichermangels beendet. Dein -Xmx liegt zu nah an der Grenze.
• Langsames Laden der Chunks beim Erkunden oder Elytra-Fliegen: Chunk-Generierung und Festplatten-I/O. Map vorgenerieren.
• Lag nur, wenn ein bestimmter Spieler online ist: seine Basis profilen und nach Häufungen von Entities oder Block-Entities suchen.
• Lag seit einem Update ohne Config-Änderung: erst das Changelog der Mod oder des Plugins lesen, bevor du an die Hardware gehst.
• Ping-Spitzen bei 20 TPS und niedrigem MSPT: Netzwerkweg, nicht der Server.

Der eine Test, der zeigt, ob dir wirklich RAM fehlt

Heap-Grafiken führen ständig in die Irre. Ein Java-Heap soll wie ein Sägezahn aussehen: Er füllt sich, der Collector läuft, er fällt. 90 % Belegung sagen für sich allein nichts, denn die JVM hat keinen Grund, früher aufzuräumen.

Entscheidend ist das Live-Set, also wie viel Heap direkt nach einer vollständigen Garbage Collection noch belegt ist. Lös eine aus und lies den Boden des Sägezahns ab, nicht die Spitze.

Die Einordnung, als Anteil an -Xmx: Unter 50 % hast du Reserve, und mehr RAM ändert nichts. 50 bis 70 % ist gesund. 70 bis 85 % heißt, der Collector arbeitet härter als nötig, und ein großer neuer Bau könnte dich über die Kante schieben. Dauerhaft über 85 % nach einer vollständigen Collection heißt, dir fehlt wirklich Speicher, und an diesem Punkt ist mehr RAM der richtige Kauf.

Ein Check noch vor dem Kauf. Steigt das Live-Set über Tage stetig an und kehrt nie auf seinen früheren Boden zurück, ist das ein Leak und kein Kapazitätsproblem, und mehr RAM verlängert nur den Abstand zwischen den Abstürzen. Die Heap-Übersicht von spark zeigt, welche Klassen den Heap dominieren, und an den Paketnamen erkennst du das verantwortliche Plugin meist sofort.

Tuning, das mehr bringt als ein Upgrade

Geh diese Punkte durch, bevor du für irgendetwas zahlst. Auf einem typischen Paper-Server mit 4 GB senken sie das Live-Set regelmäßig um ein Drittel und MSPT um mehr als das.

Aikars Flags verdienen einen eigenen Hinweis. Sie sind ein weit verbreitetes G1-Tuning, das den Collector häufig kleine Collections fahren lässt statt selten große, und genau das will eine latenzempfindliche Spielschleife. Nimm die Standardwerte. Aikars ursprüngliche Beschreibung passt ab etwa 12 GB Heap ein paar G1-Einstellungen an, aber ein Server, der wirklich so viel braucht, ist selten. Kopier keine zufälligen Flag-Zeilen aus Forenbeiträgen, denn einige beliebte schalten Funktionen ab, auf die der Server angewiesen ist.

Es gibt außerdem eine harte Obergrenze. Setz -Xmx nie über etwa 31 GB. Ab etwa 32 GB verliert die JVM die komprimierten Objektzeiger, jede Referenz wächst von 4 auf 8 Byte, und ein Heap von 33 GB bietet dir weniger nutzbaren Platz als einer mit 31 GB.

• Welt mit Chunky bis zu einer festen Grenze vorgenerieren. Live-Chunk-Generierung ist die größte einzelne Quelle für Tick-Spitzen.
• Eine Weltgrenze setzen und durchsetzen. Eine unbegrenzte Map lässt Region-Dateien und Erkundungskosten endlos wachsen.
• Erst simulation-distance senken, dann view-distance. Optisch kostet das die Spieler fast nichts.
• Mob-Spawn-Limits in der bukkit.yml senken (monsters steht standardmäßig auf 70 pro Welt) und entity-activation-range in der spigot.yml enger fassen.
• Live-Map-Renders planen, statt sie dauerhaft laufen zu lassen. Ein kompletter Render von Dynmap oder BlueMap ist eine vorübergehende Spitze, kein Dauerzustand.
• Auf Modded-Servern dauerhaft geladene Chunks mit /forceload query prüfen und jeden Chunk-Loader im Einsatz kontrollieren.
• -Xms gleich -Xmx setzen, damit sich der Heap im Betrieb nie in der Größe ändert.
• Geplante Neustarts nur als Notlösung für ein Leak, das du nicht beheben kannst, nie als eigentliche Lösung.

Wann sich ein Upgrade lohnt, und wann nicht

Rüste auf, wenn alle drei Punkte gleichzeitig zutreffen, nicht wenn einer davon zutrifft.

Erstens: Das Live-Set nach einer vollständigen Collection liegt im normalen Spielbetrieb über 85 % von -Xmx. Zweitens: Im Health-Report von spark zeigt sich GC-Aktivität als häufige Collections der alten Generation statt als günstige junge. Drittens: Du hast die Map bereits vorgeneriert, Sicht- und Simulationsweite gesenkt und per Profil bestätigt, dass kein einzelnes Plugin und keine einzelne Mod verantwortlich ist.

Trifft alles zu, geh eine sinnvolle Stufe hoch, statt zu verdoppeln. Ein Plugin-Server, dem 3 GB nicht mehr reichen, landet meist bei 4. Ein Modpack, dem 6 GB nicht mehr reichen, will meist 8 und nur sehr selten mehr als 10.

Sei auch bei der Richtung ehrlich. Von 6 GB auf 12 GB zu gehen ändert auf einem Server mit MSPT 60 nichts, denn du hast Kapazität für ein Problem gekauft, das eigentlich Geschwindigkeit ist.

Zur Technik: Viele Hoster verkaufen gestaffelte Tarife, bei denen du die Größe selbst änderst. Bei Puranode gibt es für Minecraft einen Tarif mit 4 GB, und mehr RAM stellen wir auf Anfrage per E-Mail am selben Tag um. So oder so: Frag nach der Container-Grenze und halte -Xmx darunter.

Wann du gar nicht für Hosting zahlen solltest

Für zwei bis vier Leute, die an ein paar Abenden pro Woche eine Vanilla- oder leicht gemoddete Welt spielen, reicht ein freier Desktop-PC oder ein dauerhaft laufender Laptop völlig. Ein Heap von 2 GB läuft auf fast jedem Rechner der letzten zehn Jahre, und die ehrliche Antwort lautet: Du brauchst keinen Hoster.

Die echten Kosten des Selbsthostens (auf Englisch) sind nicht CPU oder RAM. Es sind deine Upload-Bandbreite, die deinen Freunden 300 ms und Rubber-Banding beschert, sobald jemand im Haushalt anfängt zu streamen, die Portweiterleitung, die deine Heim-IP offenlegt und Zugriff auf einen Router braucht, den du vielleicht nicht hast, und ein Rechner, der wach sein muss, wann immer jemand spielen will. Tunnel-Dienste oder ein privates Mesh-Netzwerk lösen die Hälfte mit der Portweiterleitung, nicht die mit der Bandbreite.

Bezahltes Hosting lohnt sich, wenn die Spieler über mehrere Länder verteilt sind, wenn die Welt laufen soll, während du schläfst, wenn du Backups willst, die ohne Nachdenken laufen, oder wenn ein Modpack 8 GB will, die du zu Hause lieber nicht abstellst. Unterhalb dieser Schwelle ist gekaufter RAM, den du nicht nutzt, einfach RAM, den du nicht nutzt.