Hvor mye RAM trenger en Minecraft-server?

Hva som faktisk avgjør hvor mye RAM du trenger

To spaker avgjør hvor mye minne en Minecraft-server vil ha. Alt annet er støy ved siden av dem.

• Antall spillere legger på RAM gradvis. Hver tilkoblet spiller laster inn chunkene rundt seg, så flere spillere — og en høyere view-distance — betyr at mer av verdenen holdes i minnet samtidig. Å gå fra 4 til 20 spillere er en reell, men håndterbar økning.
• Mods og plugins er den store spaken, med god margin. Vanilla er lett. En håndfull Paper-plugins legger på litt. En modpack er en helt annen kategori: hver mod laster inn sin egen kode, sine gjenstander, blokker og verdensgenerering i minnet før en eneste spiller kobler seg til, og det er derfor en CurseForge-pakke med 200 mods kan trenge flere ganger så mye RAM som en vanilla-server med samme antall spillere.

Det er hele modellen: vanilla skalerer med spillere, modded skalerer med mods. Størrelsen og alderen på en verden dytter tallet opp også — et vidstrakt, årelangt kart med mange innlastede chunks koster mer enn et ferskt et — men det er spillere og mods du dimensjonerer etter. Ha én ting i bakhodet mens du leser videre: RAM er bare én av serverens ressurser, og etter et visst punkt slutter den å være den som betyr noe (mer om det i hvorfor mer RAM ikke alltid er løsningen).

Hvor mye RAM en Minecraft-server trenger, etter oppsett

Her er dimensjoneringen vi bygger planene rundt — de samme tallene vi ville gitt en venn. «RAM å sikte mot» er det du tildeler serveren selv, ikke PC-ens totale minne, som trenger slingringsmonn i tillegg (se hvordan du tildeler den).

Kjører du en modpack og er usikker på hvilket sjikt du havner i? Både pakkestørrelse og antall spillere dytter deg oppover i tabellen — guiden om moddede Minecraft-servere bryter ned loadere og pakkestørrelser i detalj.

Slik tildeler du serveren den RAM-en

Å vite tallet er halve jobben; den andre halvparten er å faktisk gi det minnet til serveren. Det fungerer forskjellig avhengig av hvor serveren kjører.

Selvhostet: flaggene -Xmx og -Xms

Når du starter server-jar-filen selv, styrer to flagg minnet dens. -Xmx setter den maksimale heapen (taket), og -Xms setter start-heapen. For Minecraft er det vanlige, velprøvde rådet å sette dem like, slik at JVM-en tar hele minnet sitt med én gang i stedet for å endre størrelse under belastning:

java -Xms4G -Xmx4G -jar server.jar nogui

Den linjen starter en server med 4 GB. Noen få ting folk snubler i:

• Bruk 64-bits Java. 32-bits Java kan ikke adressere mer enn omtrent 1,5 GB, så hvis -Xmx4G nekter å starte, er det som regel derfor. Enhver dagsaktuell Temurin- eller Java 25-utgave er 64-bits.
• Gi aldri serveren all RAM-en din. La minst 1-2 GB stå igjen til operativsystemet, og mer hvis du også kjører Minecraft-klienten på samme PC — spillet trenger sitt eget minne i tillegg til serverens.
• Finjuster deretter med Aikar's flags. Når det grunnleggende fungerer, finjusterer community-standarden «Aikar's flags» Javas G1-søppelsamler for Minecrafts minnemønster, og bytter en liten bit RAM mot merkbart jevnere ticks. De er det vanlige neste steget forbi bare -Xmx/-Xms. Hele selvhosting-gjennomgangen — jar, EULA, portviderekobling og alt — finner du i Slik lager du en Minecraft-server.

Hostet: velg en størrelse, oppgrader på stedet

På en administrert server er det ingen flagg å redigere. Du velger RAM med en glidebryter når du bestiller, og planen settes opp i den størrelsen — oppstartsflaggene (inkludert Aikar's flags) er allerede finjustert for deg.

Den virkelige fordelen viser seg når du vokser fra det første anslaget ditt: på Minecraft-hostingsiden drar du glidebryteren opp, og den ekstra RAM-en gjelder for den samme serveren med verden og innstillinger intakt — ingen reinstallering, ingen migrering, gjort på omtrent et minutt. Det er nettopp derfor tommelfingerregelen over er «start smått»: på en hostet plan koster det ikke annet enn et minutt å legge til RAM senere.

Tegn på at serveren din trenger mer RAM

Du trenger ikke å gjette på om serveren din sulter. Den forteller det selv, på noen få gjenkjennelige måter:

• Ticks henger etter. Konsollen skriver Can't keep up! Is the server overloaded? Running Xms behind, skipping Xs tick(s), og i spillet viser det seg som rubber-banding, mobs som fryser, og blokker som bruker et øyeblikk på å knuses.
• Lagringen av verdenen hakker. En kort frys med noen minutters mellomrom, som faller sammen med autolagringen, betyr ofte at serveren kjemper om minne.
• Den krasjer rett og slett. Det aller tydeligste signalet er en krasj hvis logg inneholder java.lang.OutOfMemoryError: Java heap space — serveren ba om mer minne enn -Xmx-taket tillot.

For å finne ut hvilket det er, viser det gratis profileringsverktøyet spark (kjør /spark health eller /spark profiler) tick-tider og minnebruk, og et hostet panel tegner live RAM-bruk i en graf. Hvis minnet ligger fastklemt nær taket, øk størrelsen. Hvis minnet har plass, men ticks fortsatt lagger, les neste del først.

Hvorfor mer RAM ikke alltid er løsningen

Dette er delen de fleste dimensjoneringsråd hopper over. Minecraft kjører hovedløkken i spillet — «ticken» som beveger mobs, får avlinger til å gro og prosesserer redstone — stort sett på en enkelt CPU-tråd. Minnet holder på verdenen; én kjerne står for tenkingen. Så snart serveren har nok RAM til å holde på alt, blir ikke den kjernen noe raskere av at du legger til mer.

To konsekvenser er verdt å ta innover seg:

• Hvis ticks lagger mens RAM-en har slingringsmonn, er flaskehalsen CPU-en, ikke minnet. Å kaste 32 GB på en server som er fastlåst på én kjerne, endrer ingenting. Dette er den desidert vanligste dimensjoneringsfeilen folk gjør.
• For mye RAM kan til og med skade. En svært stor heap gir Javas søppelsamler mer å feie gjennom på én gang, noe som kan bli til lengre pause-hakk — enda en grunn til at «start mindre»-regelen holder.

Det som faktisk utgjør en forskjell når CPU-en er grensen, er en høy klokkefrekvens. Det er derfor HytHost kjører Minecraft på høyfrekvente Ryzen- og Intel i9-CPU-er i stedet for mange trege kjerner — Minecraft bryr seg om hvor rask én kjerne er, ikke hvor mange det er. På programvaresiden kan du lette belastningen på den kjernen ved å senke view-distance og simulation-distance, forhåndsgenerere chunkene i verdenen din, kjøre Paper i stedet for vanilla, eller legge til ytelsesmods som Lithium i et modded oppsett. RAM får verdenen din lastet inn; CPU-en og programvarevalgene dine avgjør hvor jevnt den kjører.