Gids
Hoeveel RAM heeft een Minecraft-server nodig?
Het meeste advies over geheugen voor een Minecraft-server is te laag om bruikbaar te zijn of zo hoog dat je er geld mee verspilt. Deze gids gebruikt de cijfers van de Minecraft Wiki en de documentatie van Paper, legt uit wat het geheugen echt vult en wat lag veroorzaakt, en sluit af met hoe je de heap instelt zodat Java je server niet zonder geheugen laat lopen. Hij gaat over Java Edition-servers: vanilla, Paper en modded.
Door het Evorxa-teamGepubliceerd
Het korte antwoord
Twee bronnen geven twee soorten getallen. De Minecraft Wiki vermeldt wat een vanilla-server nodig heeft met standaardinstellingen en een nieuw gegenereerde wereld. Het Paper-team geeft aan wat een Paper-server zou moeten krijgen om goed te draaien, ongeacht het aantal spelers.
| Bron | Opzet | Geheugen |
|---|---|---|
| Minecraft Wiki, minimum | vanilla, 1 tot 4 spelers | 1 GB |
| Minecraft Wiki, aanbevolen | vanilla, 5 tot 10 spelers | 2 GB |
| Minecraft Wiki, beste | vanilla, 10 of meer spelers | 4 GB |
| Paper-docs (Aikar's flags) | Paper, elk aantal spelers | 6 tot 10 GB heap |
De cijfers van de wiki zijn een ondergrens voor een verse wereld. Werelden groeien, spelers verspreiden zich en plugins voegen hun eigen data toe, dus een openbare server die maanden draait, heeft meer nodig. Een praktische manier om te kiezen:
- Kleine vanilla- of Paper-server voor vrienden: 4 GB servergeheugen dekt het cijfer van de wiki voor 10 of meer spelers, met ongeveer 2,5 tot 3 GB voor Java. Het Paper-team zou er meer aan geven als dat kan.
- Paper-server met plugins en een groeiende wereld: volg het advies van Paper en reken op een heap van 6 tot 10 GB, wat neerkomt op een server van 8 tot 12 GB.
- Modded server: gebruik het cijfer dat de maker van het modpack publiceert. Er is geen algemene regel, want één mod kan meer nodig hebben dan het hele vanilla-spel.
Paper waarschuwt ook voor de omgekeerde fout: boven een bepaald punt levert meer geheugen steeds minder op, en 32 GB RAM kopen voor een server is vooral geldverspilling.
Wat het geheugen vult
De wiki schat één spelerobject op ongeveer 50 tot 100 MB en voegt eraan toe dat de server per speler vaak veel meer moet toewijzen, omdat elke speler een stuk van de wereld om zich heen geladen houdt. Een groeiende wereld en hoge weergaveafstanden verhogen het geheugengebruik. Daarbovenop komen entities (mobs, items, minecarts), data van plugins en mods, en de eigen werkruimte van Java.
Java-geheugen gedraagt zich ook niet als een simpele teller. Minecraft maakt elke seconde een enorm aantal kortlevende objecten aan en gooit ze weer weg, en de garbage collector ruimt ze in cycli op. De documentatie van Paper noemt een allocatiesnelheid van minstens 800 MB per seconde op een server met 30 spelers. Bij een te kleine heap draait de collector constant, en die pauzes merk je als lag.
Lag komt meestal door de CPU, niet door het RAM
Het spel draait zijn wereldsimulatie in ticks, 20 per seconde. Dat geeft elke tick 50 milliseconden. Volgens de wiki doet de server het meeste van dit werk op één core en gebruikt hij andere cores alleen voor bijtaken, dus de snelheid van één core bepaalt hoeveel hij aankan voordat ticks langer dan 50 ms duren en de wereld vertraagt. Grote aantallen mobs en complexe redstone zijn de gebruikelijke oorzaken.
Daarom lost meer RAM zelden lag op bij een server die al genoeg heeft. Als /mspt hoog is terwijl het geheugen nog ruimte over heeft, heb je een snellere core of minder werk per tick nodig, niet meer gigabytes. Sommige plugins verplaatsen hun eigen werk naar andere cores; de wiki raadt aan de documentatie van een plugin te lezen voordat je hem installeert.
Weergaveafstand en simulatieafstand
Twee instellingen in server.properties bepalen hoeveel van de wereld elke speler bezighoudt. Beide worden gemeten in chunks, als straal rond de speler, beide staan standaard op 10 en beide accepteren 3 tot 32, zoals vermeld in de server.properties-referentie.
view-distance(weergaveafstand) bepaalt hoeveel wereldgegevens de server naar de speler stuurt. Dat kost vooral geheugen en bandbreedte.simulation-distance(simulatieafstand) bepaalt tot hoe ver van een speler levende entities nog worden bijgewerkt. Dat kost CPU bij elke tick.
Het gebied groeit met het kwadraat van de straal, dus de besparing is groter dan de getallen doen vermoeden: van 10 naar 6 gaan verkleint het gebied tot ongeveer een derde. Als je de simulatieafstand lager houdt dan de weergaveafstand, kunnen spelers ver kijken terwijl de server alleen het nabije gebied simuleert:
# server.properties (both default to 10, allowed range 3 to 32)
view-distance=8
simulation-distance=6Heapgrootte tegenover servergeheugen
De waarde -Xmx bepaalt de maximale grootte van de heap van Java. Het is niet het totale geheugen dat het proces gebruikt. Java heeft daarbovenop meer nodig voor zijn eigen structuren, threads en buffers, en het besturingssysteem heeft ook geheugen nodig. Als je de heap alles geeft wat de server heeft, kan de out-of-memory-killer van Linux het serverproces zonder waarschuwing stoppen.
De Paper-documentatie geeft de regel: zet -Xmx en -Xms ongeveer 1000 tot 1500 MB onder het geheugen dat je hebt. Met 8 GB gebruik je 6500 MB. Zet beide op dezelfde waarde: Paper legt uit dat je er toch van uit moet gaan dat de server de hele heap gebruikt, en geheugen dat onder -Xmx overblijft, wordt niet gebruikt.
| Servergeheugen | -Xms en -Xmx |
|---|---|
| 4 GB | 2500 tot 3000 MB |
| 8 GB | 6500 MB |
| 12 GB | 10500 tot 11000 MB |
| 16 GB | 14500 tot 15000 MB |
Als je -Xmx helemaal niet instelt, kiest Java een standaardwaarde op basis van het systeem, en in een container leest Java de geheugenlimiet van de container, zoals de referentie van het java-commando beschrijft. Die standaardwaarde is zelden wat je wilt voor een gameserver, dus stel hem altijd in.
Aikar's flags
Paper publiceert een set instellingen voor de garbage collector die bekendstaat als Aikar's flags, afgestemd op het allocatiepatroon van Minecraft. Ze gebruiken de G1-collector, geven die een grotere young generation zodat kortlevende objecten worden opgeruimd voordat ze worden gepromoveerd, reserveren vooraf geheugen met AlwaysPreTouch, en voorkomen met DisableExplicitGC dat plugins volledige collections afdwingen. Volgens de handleiding Aan de slag heeft Paper Java 25 of nieuwer nodig, dus controleer eerst de versie:
# 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 --noguiPas alleen de twee geheugenwaarden aan voor je server. De documentatie van Paper linkt ook naar een scriptgenerator die dit startscript voor je schrijft. Dezelfde pagina beschrijft -XX:+UseTransparentHugePages als experiment voor gevorderde gebruikers, alleen samen met AlwaysPreTouch, en zegt dat het Paper-team het effect ervan op Minecraft niet heeft gemeten. Laat het weg, tenzij je van plan bent het zelf te meten.
Als je geheugenproblemen vermoedt, zet dan logging van de garbage collection aan. Paper merkt op dat dit de prestaties niet schaadt en dat de logbestanden rond de 5 MB blijven:
# add to the java line (Java 11 and newer) to log garbage collection
-Xlog:gc*:logs/gc.log:time,uptime:filecount=5,filesize=1MMeet voordat je upgradet
Paper heeft commando's voor de twee getallen die ertoe doen, vermeld in de commandoreferentie:
/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 onder 20 en MSPT boven 50, geheugen in orde: de CPU is de beperking. Verlaag
simulation-distance, zoek zware farms of plugins op met/spark, of stap over op een snellere core. - Collections draaien constant, of het proces wordt gekild: de heap is te klein of staat te dicht bij het totale geheugen van de server. Herstel eerst die marge en voeg daarna geheugen toe.
- Allebei in orde, maar spelers melden lag: controleer het netwerkpad en de eigen verbinding van de speler voordat je de server aanpast.
Schrik niet als ps laat zien dat het Java-proces meer gebruikt dan -Xmx. Dat extra is het geheugen dat Java buiten de heap nodig heeft, en het is de reden voor de marge van 1000 tot 1500 MB. Met -Xms gelijk aan -Xmx en AlwaysPreTouch aan claimt het proces bij de start ook zijn volledige heap, dus een hoog getal direct na het opstarten is normaal en wijst niet op een lek. Kijk liever hoe het getal verandert over uren spelen.
Minecraft bij Evorxa
De Minecraft-hosting van Evorxa draait op VPS-plannen met gedeelde cores en VDS-plannen met toegewezen high-frequency cores; die tweede soort past bij de single-thread-belasting van Minecraft. Plannen beginnen bij $2.99 per maand, worden vooraf betaald per maand, voor zes maanden of per jaar, en geven je root- en SSH-toegang om de flags hierboven in te stellen. Servers draaien in één regio, Eygelshoven in Nederland, en een kaal Linux-image is meestal binnen ongeveer een minuut klaar.
Bronnen
De feiten in deze gids komen van deze pagina's.