Quanta RAM necessita un servidor de Minecraft?

Què determina de debò quanta RAM necessites

Dues palanques decideixen quanta memòria vol un servidor de Minecraft. Tota la resta és soroll al seu costat.

• El nombre de jugadors afegeix RAM de mica en mica. Cada jugador connectat carrega els chunks del seu voltant, així que més jugadors —i una view-distance més alta— signifiquen tenir més món a la memòria alhora. Passar de 4 jugadors a 20 és un augment real, però assumible.
• Els mods i els plugins són la gran palanca, i amb molta diferència. Vanilla és lleuger. Un grapat de plugins de Paper hi afegeix una mica. Un modpack ja és una categoria completament diferent: cada mod carrega a la memòria el seu propi codi, els seus objectes, els seus blocs i la seva generació de món abans que s'hi connecti ni un sol jugador, i per això un pack de CurseForge de 200 mods pot necessitar diverses vegades la RAM d'un servidor vanilla per al mateix nombre de jugadors.

Aquest és tot el model: vanilla escala amb els jugadors, amb mods escala amb els mods. La mida i l'antiguitat d'un món també fan pujar una mica la xifra —un mapa immens i de fa anys, amb molts chunks carregats, costa més que un de nou—, però els jugadors i els mods són el que fas servir per dimensionar. Tingues una cosa present a mesura que continuïs llegint: la RAM és només un dels recursos del servidor i, passat un cert punt, deixa de ser el que importa (n'hi ha més a per què més RAM no sempre és la solució).

Quanta RAM necessita un servidor de Minecraft, segons la configuració

Aquestes són les mides sobre les quals construïm els plans: els mateixos números que li donaríem a un amic. La «RAM recomanada» és el que has d'assignar al servidor mateix, no el total del teu PC, que necessita marge a sobre (consulta com assignar-la).

Fas servir un modpack i no saps ben bé a quina franja caus? Tant la mida del pack com el nombre de jugadors et fan pujar per la taula: la guia del servidor de Minecraft amb mods desglossa els loaders i les mides dels packs amb detall.

Com donar aquesta RAM al teu servidor

Saber la xifra és la meitat de la feina; l'altra meitat és donar de debò aquesta memòria al servidor. Funciona de manera diferent segons on s'executi el servidor.

Auto-allotjat: els flags -Xmx i -Xms

Quan ets tu qui engega el jar del servidor, dos flags controlen la seva memòria. -Xmx fixa el heap màxim (el sostre) i -Xms fixa el heap inicial. Per a Minecraft, el consell habitual i ben provat és posar-los iguals, de manera que la JVM agafi tota la seva memòria d'entrada en comptes de redimensionar-la sota càrrega:

java -Xms4G -Xmx4G -jar server.jar nogui

Aquesta línia engega un servidor amb 4 GB. Unes quantes coses on la gent ensopega:

• Fes servir Java de 64 bits. El Java de 32 bits no pot adreçar més d'uns 1,5 GB, així que si -Xmx4G es nega a arrencar, normalment és per això. Qualsevol build actual de Temurin o de Java 25 és de 64 bits.
• No donis mai tota la teva RAM al servidor. Deixa com a mínim 1-2 GB per al sistema operatiu, i més si també executes el client de Minecraft al mateix PC: el joc necessita la seva pròpia memòria a més de la del servidor.
• Després, afina-ho amb els flags d'Aikar. Un cop funciona el bàsic, els «flags d'Aikar», l'estàndard de la comunitat, tornen a ajustar el recol·lector d'escombraries G1 de Java per al patró de memòria de Minecraft, i canvien una engruna de RAM per uns ticks notablement més estables. Són el pas següent habitual després d'un -Xmx/-Xms pelat. El tutorial complet d'auto-allotjament —jar, EULA, redirecció de ports i tot— és a Com fer un servidor de Minecraft.

Gestionat: tria una mida i amplia-la sense reinstal·lar

En un servidor gestionat no hi ha cap flag per editar. Tries la RAM amb un control lliscant quan fas la comanda, i el pla es proveeix amb aquesta mida: els flags d'arrencada (inclosos els d'Aikar) ja venen afinats per tu.

L'avantatge de debò es veu quan superes la teva primera estimació: a la pàgina d'allotjament de Minecraft puges el control lliscant i la RAM addicional s'aplica al mateix servidor, amb el món i la configuració intactes: sense reinstal·lar res, sense migracions, fet en aproximadament un minut. És exactament per això que la regla pràctica de més amunt és «comença petit»: en un pla gestionat, afegir RAM més endavant no costa res més que un minut.

Senyals que el teu servidor necessita més RAM

No has d'endevinar si el teu servidor està escanyat. T'ho diu ell mateix, de maneres força reconeixibles:

• Els ticks es queden enrere. La consola imprimeix Can't keep up! Is the server overloaded? Running Xms behind, skipping Xs tick(s), i dins del joc això es tradueix en rubber-banding, mobs que es queden congelats i blocs que triguen una estona a trencar-se.
• Desar el món va a batzegades. Una petita congelació cada pocs minuts, que coincideix amb el desat automàtic, sovint vol dir que el servidor lluita per la memòria.
• Peta directament. El senyal més clar de tots és una fallada el registre de la qual conté java.lang.OutOfMemoryError: Java heap space: el servidor ha demanat més memòria de la que li permetia el seu sostre -Xmx.

Per veure de quin cas es tracta, el perfilador gratuït spark (executa /spark health o /spark profiler) mostra els temps dels ticks i l'ús de memòria, i un panell gestionat dibuixa la RAM en directe en una gràfica. Si la memòria es queda clavada a prop del sostre, apuja la mida. Si la memòria té marge però els ticks continuen anant lents, llegeix abans la secció següent.

Per què més RAM no sempre és la solució

Aquesta és la part que la majoria de consells sobre mides es deixen. Minecraft executa el bucle principal del joc —el «tick» que mou els mobs, fa créixer els conreus i processa la redstone— majoritàriament en un sol fil de CPU. La memòria conté el món; un sol nucli fa tota la feina de càlcul. Un cop el servidor té prou RAM per contenir-ho tot, afegir-ne més no fa que aquell nucli vagi més ràpid.

Val la pena interioritzar dues conseqüències:

• Si els ticks van lents mentre la RAM té marge, el coll d'ampolla és la CPU, no la memòria. Posar 32 GB a un servidor encallat en un sol nucli no canvia res. Aquest és, de llarg, l'error de dimensionament més comú que comet la gent.
• Massa RAM fins i tot pot perjudicar. Un heap molt gran li dóna al recol·lector d'escombraries de Java més coses per escombrar de cop, cosa que es pot convertir en batzegades de pausa més llargues: una raó més per la qual es manté la regla de «comença més petit».

El que de debò marca la diferència quan el límit és la CPU és una freqüència de rellotge alta. Per això HytHost fa funcionar Minecraft en CPU Ryzen i Intel i9 d'alta freqüència en comptes de molts nuclis lents: a Minecraft li importa la rapidesa d'un sol nucli, no pas quants n'hi ha. Pel que fa al programari, pots alleugerir la càrrega d'aquell nucli abaixant view-distance i simulation-distance, pregenerant els chunks del teu món, executant Paper en comptes de vanilla, o afegint mods de rendiment com Lithium en una configuració amb mods. La RAM et carrega el món; la CPU i les teves decisions de programari decideixen com de fluid va.