Quanta RAM serve a un server Minecraft?

La risposta breve

Due fonti danno due tipi di numeri. La Minecraft Wiki elenca ciò di cui ha bisogno un server vanilla con le impostazioni predefinite e un mondo appena generato. Il team di Paper consiglia quanta memoria dovrebbe ricevere un server Paper per funzionare bene, qualunque sia il numero di giocatori.

I valori della wiki sono un minimo per un mondo nuovo. I mondi crescono, i giocatori si sparpagliano e i plugin aggiungono i propri dati, quindi un server pubblico che resta attivo per mesi ha bisogno di più memoria. Un modo pratico per decidere:

• Piccolo server vanilla o Paper per amici: 4 GB di memoria del server coprono il valore della wiki per 10 o più giocatori, di cui circa da 2,5 a 3 GB assegnati a Java. Il team di Paper gliene darebbe di più, se puoi.
• Server Paper con plugin e un mondo in crescita: segui il consiglio di Paper e prevedi un heap da 6 a 10 GB, cioè un server da 8 a 12 GB.
• Server modded: usa il valore pubblicato dall'autore del modpack. Non esiste una regola generale, perché una singola mod può richiedere più dell'intero gioco vanilla.

Paper mette in guardia anche dall'errore opposto: oltre un certo punto, più memoria porta rendimenti decrescenti, e comprare 32 GB di RAM per un server è soprattutto uno spreco di soldi.

Cosa riempie la memoria

La wiki indica circa da 50 a 100 MB per un singolo oggetto giocatore e aggiunge che spesso il server deve allocare molto di più per ogni giocatore, perché ognuno tiene caricata un'area del mondo intorno a sé. Mondi più grandi e distanze di visualizzazione elevate aumentano l'uso di memoria. A questo si aggiungono le entità (mob, oggetti, carrelli da miniera), i dati di plugin e mod e lo spazio di lavoro di Java stesso.

Inoltre la memoria di Java non si comporta come un semplice contatore. Minecraft crea e scarta ogni secondo un numero enorme di oggetti a vita breve, e il garbage collector li ripulisce a cicli. La documentazione di Paper cita un tasso di allocazione di almeno 800 MB al secondo su un server da 30 giocatori. Un heap troppo piccolo fa lavorare il collector di continuo, e quelle pause si vedono come lag.

Il lag di solito dipende dalla CPU, non dalla RAM

Il gioco esegue la simulazione del mondo in tick, 20 al secondo. Questo dà a ogni tick 50 millisecondi. Secondo la wiki, il server svolge la maggior parte di questo lavoro su un solo core e usa gli altri core solo per compiti secondari, quindi è la velocità di un singolo core a decidere quanto può gestire prima che i tick durino più di 50 ms e il mondo rallenti. Le cause abituali sono grandi quantità di mob e circuiti di redstone complessi.

Ecco perché aggiungere RAM raramente risolve il lag su un server che ne ha già abbastanza. Se /mspt è alto mentre la memoria ha ancora margine, ti serve un core più veloce o meno lavoro per tick, non più gigabyte. Alcuni plugin spostano il proprio lavoro su altri core; la wiki consiglia di leggere la documentazione di un plugin prima di installarlo.

Distanza di visualizzazione e distanza di simulazione

Due impostazioni in server.properties stabiliscono quanta parte del mondo ogni giocatore tiene impegnata. Entrambe si misurano in chunk, come raggio intorno al giocatore, entrambe hanno 10 come valore predefinito ed entrambe accettano valori da 3 a 32, come indicato nel riferimento di server.properties.

• view-distance è la quantità di dati del mondo che il server invia al giocatore. Costa soprattutto memoria e banda.
• simulation-distance è la distanza dal giocatore entro cui le entità viventi vengono ancora aggiornate. Costa CPU a ogni tick.

L'area cresce con il quadrato del raggio, quindi il risparmio è maggiore di quanto suggeriscano i numeri: passare da 10 a 6 riduce l'area a circa un terzo. Tenere la distanza di simulazione più bassa di quella di visualizzazione permette ai giocatori di vedere lontano mentre il server elabora solo l'area vicina:

# server.properties (both default to 10, allowed range 3 to 32)
view-distance=8
simulation-distance=6

Dimensione dell'heap e memoria del server

Il valore di -Xmx imposta la dimensione massima dell'heap di Java. Non è la memoria totale usata dal processo. Java ha bisogno di altra memoria oltre a questa per le proprie strutture, i thread e i buffer, e anche il sistema operativo ha bisogno di memoria. Se dai all'heap tutta la memoria del server, l'out-of-memory killer di Linux può fermare il processo del server senza preavviso.

La documentazione di Paper dà la regola: imposta -Xmx e -Xms circa da 1000 a 1500 MB sotto la memoria che hai. Con 8 GB, usa 6500 MB. Imposta entrambi sullo stesso valore: Paper spiega che bisogna aspettarsi che il server usi comunque tutto l'heap, e la memoria lasciata sotto -Xmx resta inutilizzata.

Se non imposti affatto -Xmx, Java sceglie un valore predefinito in base al sistema e, in un container, legge il limite di memoria del container, come descrive il riferimento del comando java. Il valore predefinito raramente è quello che vuoi per un server di gioco, quindi impostalo sempre.

I flag di Aikar

Paper pubblica un insieme di impostazioni del garbage collector note come flag di Aikar, ottimizzate per il modo in cui Minecraft alloca la memoria. Usano il collector G1, gli danno una young generation più grande così che gli oggetti a vita breve vengano ripuliti prima di essere promossi, riservano la memoria in anticipo con AlwaysPreTouch e impediscono ai plugin di forzare raccolte complete con DisableExplicitGC. Paper richiede Java 25 o successivo, secondo la sua guida introduttiva, quindi controlla prima la versione:

# 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 --nogui

Cambia solo i due valori di memoria in base al tuo server. La documentazione di Paper rimanda anche a un generatore che scrive per te questo script di avvio. La stessa pagina descrive -XX:+UseTransparentHugePages come un esperimento per utenti esperti, da usare solo insieme ad AlwaysPreTouch, e dice che il team di Paper non ne ha misurato l'effetto su Minecraft. Lascialo fuori, a meno che tu non intenda misurarlo da solo.

Se sospetti problemi di memoria, attiva il logging del garbage collector. Paper fa notare che non pesa sulle prestazioni e che i file di log restano intorno ai 5 MB:

# add to the java line (Java 11 and newer) to log garbage collection
-Xlog:gc*:logs/gc.log:time,uptime:filecount=5,filesize=1M

Misura prima di fare l'upgrade

Paper ha comandi per i due numeri che contano, elencati nel suo riferimento dei comandi:

/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 sotto 20 e MSPT sopra 50, memoria a posto: il limite è la CPU. Abbassa simulation-distance, trova farm o plugin pesanti con /spark, oppure passa a un core più veloce.
• Garbage collection continue, o processo terminato: l'heap è troppo piccolo o impostato troppo vicino alla memoria totale del server. Correggi prima il margine, poi aggiungi memoria.
• Entrambi a posto ma i giocatori segnalano lag: controlla il percorso di rete e la connessione del giocatore prima di modificare il server.

Non allarmarti se ps mostra che il processo Java usa più di -Xmx. Quella quota in più è la memoria di cui Java ha bisogno fuori dall'heap, ed è il motivo del margine da 1000 a 1500 MB. Con -Xms uguale a -Xmx e AlwaysPreTouch attivo, il processo occupa inoltre tutto l'heap all'avvio, quindi un valore alto subito dopo il boot è previsto e non indica un leak. Osserva piuttosto come cambia il valore nel corso di ore di gioco.

Minecraft su Evorxa

L'hosting Minecraft di Evorxa gira su piani VPS con core condivisi e piani VDS con core dedicati ad alta frequenza; il secondo tipo si adatta al carico single-thread di Minecraft. I piani partono da $2.99 al mese, sono prepagati su base mensile, semestrale o annuale, e ti danno accesso root e SSH per impostare i flag descritti sopra. I server girano in una sola regione, Eygelshoven nei Paesi Bassi, e un'immagine Linux pulita di solito è pronta in circa un minuto.

Fonti

I fatti di questa guida provengono da queste pagine.

1. Minecraft Wiki: requisiti del server
2. Minecraft Wiki: server.properties
3. Documentazione Paper: flag di Aikar
4. Documentazione Paper: guida introduttiva
5. Documentazione Paper: comandi
6. Oracle: il comando java