Mennyi RAM kell egy Minecraft szerverhez?

Mi dönti el valójában, mennyi RAM kell

Két tényező dönti el, mennyi memóriát kíván egy Minecraft szerver. Minden más csak zaj mellettük.

• A játékosszám fokozatosan növeli a RAM-igényt. Minden csatlakozott játékos betölti a maga körüli chunkokat, így több játékos – és egy magasabb view-distance – azt jelenti, hogy egyszerre a világ nagyobb része van a memóriában. A 4 játékosról 20-ra váltás valódi növekedés, de kezelhető.
• A modok és pluginok jelentik a nagy tényezőt, méghozzá messze. A vanilla könnyű. Néhány Paper plugin egy kicsit hozzátesz. Egy modpack viszont teljesen más kategória: minden mod a saját kódját, tárgyait, blokkjait és világgenerálását tölti be a memóriába, még mielőtt egyetlen játékos is csatlakozna – ezért kérhet egy 200 modból álló CurseForge csomag ugyanannyi játékosnál a vanilla szerver többszörösét RAM-ban.

Ez az egész modell: a vanilla a játékosokkal skálázódik, a moddolt a modokkal. A világ mérete és kora is feljebb tolja a számot – egy szerteágazó, több éves térkép sok betöltött chunkkal többe kerül, mint egy friss –, de a játékosok és a modok azok, amikhez méretezel. Egy dolgot tarts a fejed hátsó zugában, ahogy olvasol tovább: a RAM csak egy a szerver erőforrásai közül, és egy ponton túl megszűnik az lenni, amelyik számít (erről bővebben itt: miért nem mindig a több RAM a megoldás).

Mennyi RAM kell egy Minecraft szerverhez, összeállítás szerint

Íme a méretezés, amely köré a csomagjainkat építjük – ugyanazok a számok, amiket egy barátnak is mondanánk. A „cél RAM” az, amit magának a szervernek adsz ki, nem a géped teljes memóriája, amelynek ezen felül tartalékra van szüksége (lásd: hogyan oszd ki).

Modpacket futtatsz, és nem vagy biztos benne, melyik sávba esel? A csomag mérete és a játékosszám is feljebb tol a táblázatban – a moddolt Minecraft szerver útmutató részletesen lebontja a loadereket és a csomagméreteket.

Hogyan add oda ezt a RAM-ot a szervernek

A szám ismerete a munka fele; a másik fele az, hogy ezt a memóriát valóban átadd a szervernek. Ez attól függően működik másképp, hogy hol fut a szerver.

Saját üzemeltetés: az -Xmx és -Xms kapcsolók

Amikor magad indítod el a szerver jar fájlját, két kapcsoló szabályozza a memóriáját. Az -Xmx állítja be a maximális heapet (a plafont), az -Xms pedig a kezdeti heapet. A Minecraft esetében a bevált, sokat tesztelt tanács az, hogy állítsd őket egyenlőre, így a JVM már az elején lefoglalja az összes memóriáját, ahelyett hogy terhelés alatt méretezné át:

java -Xms4G -Xmx4G -jar server.jar nogui

Ez a sor egy 4 GB-os szervert indít. Néhány dolog, amin sokan elcsúsznak:

• Használj 64 bites Javát. A 32 bites Java nem tud körülbelül 1,5 GB-nál többet megcímezni, így ha az -Xmx4G nem hajlandó elindulni, általában ez az oka. Minden jelenlegi Temurin vagy Java 25 build 64 bites.
• Soha ne add oda a szervernek az összes RAM-odat. Hagyj legalább 1-2 GB-ot az operációs rendszernek, és többet, ha ugyanazon a gépen a Minecraft klienst is futtatod – a játéknak a szerverén felül saját memóriára van szüksége.
• Utána hangold be az Aikar's flags kapcsolókkal. Ha az alapok működnek, a közösségi szabványnak számító „Aikar's flags” a Minecraft memóriamintázatához hangolja Java G1 szemétgyűjtőjét, egy csipetnyi RAM-ért cserébe észrevehetően egyenletesebb tickeket adva. Ez a szokásos következő lépés a puszta -Xmx/-Xms után. A teljes, saját üzemeltetésű végigvezetőt – jar, EULA, portátirányítás és minden más – a Hogyan készíts Minecraft szervert útmutatóban találod.

Bérelt: válassz méretet, bővíts helyben

Egy menedzselt szerveren nincsenek szerkesztendő kapcsolók. A RAM-ot egy csúszkával választod ki a rendeléskor, és a csomag azon a méreten jön létre – az indítási kapcsolók (az Aikar's flags is köztük) már be vannak hangolva helyetted.

Az igazi előny akkor mutatkozik meg, amikor kinövöd az első becslésedet: a Minecraft tárhely oldalon feljebb tolod a csúszkát, és a plusz RAM ugyanarra a szerverre érvényes, a világ és a beállítások érintetlenül – nincs újratelepítés, nincs költöztetés, körülbelül egy perc alatt kész. Pontosan ezért szól a fenti ökölszabály úgy, hogy „indíts kicsiben”: egy bérelt csomagon a RAM későbbi bővítése csak egy percbe kerül.

Jelek, hogy a szervered több RAM-ot igényel

Nem kell találgatnod, hogy a szervered ki van-e éheztetve. Néhány felismerhető módon maga jelzi:

• A tickek lemaradnak. A konzol kiírja: Can't keep up! Is the server overloaded? Running Xms behind, skipping Xs tick(s), a játékban pedig ez rubber-bandingként, befagyó mobokként és lassan törő blokkokként jelentkezik.
• A világ mentése akadozik. Egy rövid befagyás néhány percenként, ami egybeesik az automatikus mentéssel, gyakran azt jelenti, hogy a szerver a memóriáért küzd.
• Egyenesen összeomlik. A legvilágosabb jel az az összeomlás, amelynek a naplója tartalmazza ezt: java.lang.OutOfMemoryError: Java heap space – a szerver több memóriát kért, mint amennyit az -Xmx plafonja engedett.

Hogy megtudd, melyikről van szó, az ingyenes spark profiler (futtasd a /spark health vagy a /spark profiler parancsot) megmutatja a tickidőket és a memóriahasználatot, egy bérelt panel pedig grafikonon ábrázolja az élő RAM-ot. Ha a memória a plafon közelébe szegezve marad, lépj feljebb egy méretet. Ha a memóriában van hely, de a tickek még mindig akadoznak, előbb olvasd el a következő szakaszt.

Miért nem mindig a több RAM a megoldás

Ez az a rész, amit a legtöbb méretezési tanács kihagy. A Minecraft a fő játékhurkot – azt a „ticket”, amely a mobokat mozgatja, a termést növeszti és a redstone-t feldolgozza – többnyire egyetlen CPU-szálon futtatja. A memória tartja a világot; egy mag végzi a gondolkodást. Amint a szervernek elég RAM-ja van mindent eltárolni, a több hozzáadása attól a magtól semmivel sem lesz gyorsabb.

Két következtetést érdemes belsővé tenni:

• Ha a tickek akadoznak, miközben a RAM-ban van tartalék, a szűk keresztmetszet a CPU, nem a memória. Ha 32 GB-ot zúdítasz egy egyetlen magon megrekedt szerverre, az semmit sem változtat. Ez az egyik legelterjedtebb méretezési hiba, amit az emberek elkövetnek.
• A túl sok RAM akár árthat is. Egy nagyon nagy heap egyszerre több takarítanivalót ad Java szemétgyűjtőjének, ami hosszabb szüneti akadozásokba fordulhat át – újabb ok arra, hogy a „kezdd kisebben” szabály érvényes.

Ami valóban számít, amikor a CPU a korlát, az a magas órajel. Ezért futtatja a HytHost a Minecraftot magas órajelű Ryzen és Intel i9 CPU-kon, nem pedig sok lassú magon – a Minecraftot az érdekli, milyen gyors egy mag, nem az, hogy hány van belőle. A szoftver oldaláról úgy könnyíthetsz annak a magnak a terhén, ha csökkented a view-distance és a simulation-distance értékét, előre legenerálod a világod chunkjait, vanilla helyett Papert futtatsz, vagy egy moddolt összeállításon teljesítménymodokat, például a Lithiumot adod hozzá. A RAM betölti a világodat; a CPU és a szoftveres döntéseid határozzák meg, milyen gördülékenyen fut.