Hoeveel RAM heeft een Minecraft-server nodig?

Wat werkelijk bepaalt hoeveel RAM je nodig hebt

Twee knoppen bepalen hoeveel geheugen een Minecraft-server nodig heeft. Al het andere valt daarbij in het niet.

• Het aantal spelers voegt geleidelijk RAM toe. Elke verbonden speler laadt de chunks om zich heen, dus meer spelers — en een hogere view-distance — betekenen dat er meer van de wereld tegelijk in het geheugen staat. Van 4 naar 20 spelers gaan is een reële toename, maar een beheersbare.
• Mods en plugins zijn met afstand de grote knop. Vanilla is licht. Een handvol Paper-plugins voegt iets toe. Een modpack is een compleet andere categorie: elke mod laadt zijn eigen code, items, blokken en wereldgeneratie in het geheugen voordat er ook maar één speler binnenkomt, en daarom kan een CurseForge-pack met 200 mods een veelvoud van de RAM van een vanilla-server nodig hebben bij hetzelfde aantal spelers.

Dat is het hele model: vanilla schaalt met spelers, modded schaalt met mods. De grootte en leeftijd van een wereld duwen het getal ook omhoog — een uitgestrekte, jaren oude kaart met veel geladen chunks kost meer dan een verse — maar spelers en mods zijn waar je de grootte op afstemt. Houd één ding in je achterhoofd terwijl je verder leest: RAM is slechts één van de bronnen van de server, en voorbij een bepaald punt is het niet langer de bron die telt (meer daarover in waarom meer RAM niet altijd de oplossing is).

Hoeveel RAM een Minecraft-server nodig heeft, per opstelling

Dit is de indeling waar we onze plannen op baseren — dezelfde getallen die we een vriend zouden geven. "Aanbevolen RAM" is wat je aan de server zelf toewijst, niet het totaal van je pc, dat daarbovenop speelruimte nodig heeft (zie hoe je het toewijst).

Draai je een modpack en weet je niet zeker in welke band je valt? Zowel de grootte van de pack als het aantal spelers duwt je omhoog in de tabel — de gids voor een modded Minecraft-server ontleedt de loaders en packgroottes in detail.

Hoe je je server die RAM geeft

Het getal kennen is het halve werk; de andere helft is dat geheugen ook echt aan de server geven. Dat gaat anders naargelang waar de server draait.

Self-hosted: de vlaggen -Xmx en -Xms

Wanneer je de server-jar zelf start, sturen twee vlaggen het geheugen aan. -Xmx stelt de maximale heap in (het plafond) en -Xms stelt de start-heap in. Voor Minecraft luidt het gangbare, goed beproefde advies om ze gelijk te zetten, zodat de JVM al zijn geheugen meteen opeist in plaats van het onder belasting te vergroten:

java -Xms4G -Xmx4G -jar server.jar nogui

Die regel start een server met 4 GB. Een paar dingen waar mensen over struikelen:

• Gebruik 64-bits Java. 32-bits Java kan niet meer dan ongeveer 1,5 GB adresseren, dus als -Xmx4G weigert te starten, is dat meestal de reden. Elke actuele Temurin- of Java 25-build is 64-bits.
• Geef de server nooit al je RAM. Laat minstens 1-2 GB over voor het besturingssysteem, en meer als je op dezelfde pc ook de Minecraft-client draait — het spel heeft bovenop dat van de server zijn eigen geheugen nodig.
• Verfijn daarna met Aikar's flags. Zodra de basis werkt, herconfigureren de community-standaard "Aikar's flags" de G1-garbagecollector van Java voor het geheugenpatroon van Minecraft — je ruilt een klein beetje RAM in voor merkbaar stabielere ticks. Het is de standaard volgende stap voorbij een kale -Xmx/-Xms. De volledige self-host-uitleg — jar, EULA, port forwarding en al — staat in Hoe maak je een Minecraft-server.

Gehost: kies een grootte, upgrade ter plekke

Op een beheerde server zijn er geen vlaggen om te bewerken. Je kiest de RAM met een schuifregelaar bij het bestellen, en het plan wordt op die grootte geprovisioneerd — de opstartvlaggen (Aikar's inbegrepen) zijn al voor je afgesteld.

Het echte voordeel blijkt wanneer je eerste inschatting te krap wordt: op de Minecraft-hostingpagina schuif je de regelaar omhoog en de extra RAM geldt voor dezelfde server, met wereld en instellingen intact — geen herinstallatie, geen migratie, klaar in ongeveer een minuut. Precies daarom luidt de vuistregel hierboven "begin klein": op een gehost plan kost later RAM toevoegen niets meer dan een minuut.

Tekenen dat je server meer RAM nodig heeft

Je hoeft niet te raden of je server verhongert. Hij laat het je weten, op een paar herkenbare manieren:

• Ticks raken achterop. De console meldt Can't keep up! Is the server overloaded? Running Xms behind, skipping Xs tick(s), en in het spel merk je dat als rubberbanding, bevriezende mobs en blokken die een moment nodig hebben om te breken.
• Het opslaan van de wereld hapert. Een korte bevriezing om de paar minuten, gelijklopend met de autosave, betekent vaak dat de server om geheugen vecht.
• Hij crasht regelrecht. Het duidelijkste signaal van allemaal is een crash met een log dat java.lang.OutOfMemoryError: Java heap space bevat — de server vroeg om meer geheugen dan zijn -Xmx-plafond toestond.

Om te zien welke van de twee het is, toont de gratis profiler spark (voer /spark health of /spark profiler uit) de tick-tijden en het geheugengebruik, en een gehost paneel tekent de live RAM in een grafiek. Zit het geheugen vastgepind tegen het plafond, ga dan een maat omhoog. Heeft het geheugen ruimte maar haperen de ticks toch, lees dan eerst het volgende gedeelte.

Waarom meer RAM niet altijd de oplossing is

Dit is het deel dat de meeste maatadviezen weglaten. Minecraft draait de hoofd-gameloop — de "tick" die mobs verplaatst, gewassen laat groeien en redstone verwerkt — grotendeels op één CPU-thread. Het geheugen houdt de wereld vast; één core doet het denkwerk. Zodra de server genoeg RAM heeft om alles vast te houden, maakt meer toevoegen die core geen greintje sneller.

Twee gevolgen zijn de moeite waard om je eigen te maken:

• Haperen de ticks terwijl de RAM speelruimte heeft, dan is de bottleneck de CPU, niet het geheugen. 32 GB smijten naar een server die op één core vastzit, verandert niets. Dit is veruit de meest gemaakte maatfout.
• Te veel RAM kan zelfs schaden. Een heel grote heap geeft de garbagecollector van Java meer om in één keer op te ruimen, wat kan omslaan in langere pauzehaperingen — nog een reden waarom de regel "begin kleiner" opgaat.

Wat echt het verschil maakt wanneer de CPU de beperkende factor is, is een hoge kloksnelheid. Daarom draait HytHost Minecraft op Ryzen- en Intel i9-CPU's met hoge kloksnelheid in plaats van veel trage cores — Minecraft geeft om hoe snel één core is, niet om hoeveel het er zijn. Aan de softwarekant kun je de belasting van die core verlichten door view-distance en simulation-distance te verlagen, de chunks van je wereld vooraf te genereren, Paper in plaats van vanilla te draaien, of performancemods zoals Lithium toe te voegen op een modded opstelling. RAM zorgt dat je wereld geladen wordt; de CPU en je softwarekeuzes bepalen hoe soepel hij draait.