Come ottimizzare il suo server Minecraft senza rompere le farm

Ridurre la simulation-distance non equivale a ridurre la view-distance. Una cambia l'area, centrata sul giocatore, che il server simula; l'altra controlla quanti dati del terreno vengono inviati ai giocatori. Un paesaggio lontano può restare visibile anche se una farm situata lì non si comporta più come il suo proprietario si aspetta.

Questa distinzione conta più della ricerca di una configurazione etichettata come “ottimizzata”. Un server più silenzioso non è un grande miglioramento se i villager smettono di rifornirsi o un punto AFK consolidato non funziona più. L'obiettivo è eliminare il lavoro di cui la sua community può fare a meno, per poi verificare che il gameplay che voleva conservare funzioni ancora.

Questo tutorial riguarda i server Minecraft Java Edition moderni. Le impostazioni di distanza valgono per Vanilla, Spigot e Paper; i comandi dei plugin e le impostazioni YAML sono indicati separatamente. Non è una ricetta universale per Bedrock, modpack o Folia. Verifichi la documentazione rispetto alla versione esatta del suo server: i riferimenti attuali possono descrivere release più recenti, e né i valori predefiniti né la struttura dei file restano fissi per sempre.

1. Misuri il problema mentre si verifica

Annoti la versione di Minecraft, il software del server e la build, il numero di giocatori e ciò che i giocatori stanno facendo quando si verifica il rallentamento. Una sala di scambio affollata e un gruppo che esplora terreno nuovo sono carichi di lavoro diversi. Fare il profiling di un server vuoto non spiegherà nessuno dei due; la documentazione di Paper richiede esplicitamente che il problema si stia verificando durante la raccolta dei dati.

Su Paper, spark è incluso a partire dalla versione 1.21. Su Spigot, installi prima un plugin spark standalone compatibile; i comandi seguenti non sono integrati in un server Vanilla non modificato.

Li esegua in gioco con i permessi necessari:

code

/spark tps
/spark profiler start --timeout 600

Il comando del profiler registra per dieci minuti e restituisce l'URL di un report. Salvi quel report insieme alla sua configurazione e alle note sul carico di lavoro.

Con il tick rate normale, Minecraft punta a 20 TPS, il che lascia 50 millisecondi per tick. L'MSPT descrive quanto durano i tick, quindi rivela pressioni che la sola lettura dei TPS può nascondere. Confronti l'MSPT mediano e quello al 95° percentile: il secondo aiuta a far emergere tick lenti ricorrenti, ma può non rilevare i picchi rari. Controlli anche il massimo, invece di considerare un buon percentile come prova che nulla si sia bloccato.

Per i problemi intermittenti, il tick monitor di spark può segnalare i tick che superano quel budget:

code

/spark tickmonitor --threshold-tick 50

Annoti cosa è successo nello stesso momento. Se i tempi dei tick restano buoni mentre arrivano le segnalazioni, indaghi sul frame rate del client o sulle condizioni di rete prima di sacrificare il gameplay del server.

2. Faccia un backup e individui quali impostazioni si applicano davvero

Prima di modificare, arresti il server in modo pulito e faccia il backup di mondi, file di configurazione e dati dei plugin. Conservi il backup fuori dalla directory del server attivo e verifichi di poterlo ripristinare. Una copia della configurazione rende comodo il rollback; un backup del mondo protegge il lavoro che c'è dietro.

Usi un editor di testo, mantenga l'indentazione YAML e cambi una sola cosa per esperimento. Poi avvii normalmente il server e controlli il log di avvio per verificare l'assenza di errori di configurazione. Non usi /reload né un hot-loader di plugin come scorciatoia: ricaricare i plugin può lasciare dipendenze e stato in condizioni incoerenti.

Per Vanilla, parta da server.properties. Per Spigot e Paper, ispezioni anche spigot.yml: le impostazioni di distanza per singolo mondo possono sovrascrivere il file delle proprietà.

Questo frammento mostra l'ereditarietà, non un preset di prestazioni:

yaml

world-settings:
  default:
    view-distance: default
    simulation-distance: default

Qui, default indica a queste opzioni di usare server.properties. Unisca le chiavi alla sezione esistente; non sostituisca l'intero file né aggiunga un secondo blocco world-settings. Controlli anche le sezioni dei mondi con nome, perché un valore specifico di un mondo può sovrascrivere l'impostazione condivisa.

Se sostituisce gli override numerici con l'ereditarietà, consideri la modifica a sé stante e registri una nuova baseline. Altrimenti potrebbe alterare diverse distanze effettive prima del suo primo test controllato.

3. Separi la visibilità del terreno dalla simulazione

Entrambe le distanze si misurano in chunk attorno al giocatore, non in blocchi né come diametro.

view-distance controlla la quantità di dati del mondo inviati al client. Ridurla scambia la visibilità del terreno lontano con un minore lavoro legato al mantenimento di quella visuale.
simulation-distance controlla l'area di tick centrata sul giocatore. Ridurla può diminuire il lavoro di simulazione, ma cambia anche l'area in cui operano le farm e le entità vicine.

Una semplificazione della zona di visuale blu e della zona di simulazione ambra, più piccola, attorno allo stesso giocatore. Si applicano anche altre regole di caricamento e prossimità.

La view distance non è gratuita solo perché una parte del terreno si trova fuori dalla simulation distance. Allo stesso modo, ridurla non sostituisce la correzione di un plugin costoso. Scelga il primo esperimento in base al profilo e al compromesso di gameplay che è disposto ad accettare.

Provi una sola modifica di distanza

Supponga che il suo server.properties contenga:

properties

view-distance=10
simulation-distance=10

Se il profilo indica un lavoro di ticking sulle aree caricate, un esperimento possibile è lasciare invariata la view distance e ridurre un po' la simulation distance:

properties

view-distance=10
simulation-distance=8

Questi numeri sono puramente indicativi, non sono valori predefiniti universali né un preset di SharpHeberg testato. Se la sua view distance attuale è diversa, lasci il suo valore com'è. Riavvii in modo pulito, riproduca il carico di lavoro originale e raccolga un altro report prima di effettuare ulteriori riduzioni.

Se invece il profilo suggerisce che il problema sia mantenere o inviare terreno lontano, testi la view distance separatamente. Non riduca entrambe le impostazioni insieme per poi cercare di indovinare quale abbia aiutato.

La simulation distance non è un regolamento completo per le farm. I chunk ticket, che mantengono caricati i chunk per motivi specifici, e i requisiti di prossimità del giocatore differiscono tra meccaniche e versioni. “Caricato” non garantisce che spawn, crescita delle colture, entità e block entity si comportino tutti allo stesso modo. Verifichi i requisiti della sua farm specifica invece di presumere che una singola distanza ne garantisca il funzionamento.

Anche lo spawn e il despawn naturali hanno le proprie regole di distanza; il mob-spawn-range di Spigot e le impostazioni di despawn di Paper aggiungono ulteriori controlli. Se una farm smette di funzionare dopo l'esperimento, ripristini innanzitutto la distanza precedente. Non compensi subito modificando diverse impostazioni di spawn.

4. Su Spigot o Paper, ispezioni il lavoro sulle entità prima di ridurre i raggi

Se il profilo indica l'elaborazione delle entità, ispezioni l'area interessata. Cerchi oggetti caduti che si accumulano, recinti sovraffollati o una sala di scambio che compie lavoro inutile. Si coordini con i proprietari prima di modificare le costruzioni. Ridurre una fonte identificata di lavoro eccessivo è più facile da valutare che indebolire ovunque il comportamento delle entità.

Due opzioni di spigot.yml dal nome simile svolgono compiti diversi:

Impostazione	Unità	Cosa controlla
`entity-activation-range`	Blocchi	Quanto vicine ai giocatori devono essere le entità per eseguire il tick normalmente; fuori da questo raggio il comportamento viene limitato.
`entity-tracking-range`	Blocchi	A quale distanza le entità vengono inviate ai giocatori, influenzando quando diventano visibili.

Questi sono controlli sulle entità, non le distanze basate sui chunk viste sopra. Un tracking range più basso può far comparire i mob all'improvviso; non equivale a ridurre il carico di lavoro della loro IA.

Le modifiche all'activation range richiedono particolare cautela nelle iron farm e con i villager. La guida della community documenta farm rotte e problemi di rifornimento causati da modifiche troppo aggressive all'attivazione o ai villager inattivi. Lasci queste impostazioni invariate a meno che il profiling giustifichi il compromesso, quindi testi la categoria di entità interessata invece di copiare un preset completo.

La stessa cautela vale per nerf-spawner-mobs, la temporizzazione degli hopper e le modifiche all'unione degli oggetti: alterano il comportamento, non solo il consumo di risorse. Non applichi tagli generalizzati ai mob cap né installi un'eliminazione pianificata delle entità come prima risposta al lag.

5. Consideri le impostazioni di Paper come controlli specifici per versione

Paper ha livelli di configurazione aggiuntivi. Il suo layout documentato comprende config/paper-global.yml per le impostazioni globali e config/paper-world-defaults.yml per le impostazioni condivise dei mondi. Il paper-world.yml di un mondo può sovrascrivere questi valori predefiniti.

Individui quel file di override usando la documentazione della sua build. I layout delle directory di mondi e dimensioni variano; copiare un percorso da un tutorial più vecchio può portarla nel posto sbagliato. Copi solo le impostazioni che intende sovrascrivere, non l'intero file dei valori predefiniti.

Paper espone controlli per spawn, despawn, collisioni e comportamento degli hopper. Sono opzioni per un problema identificato, non una checklist da completare. Ad esempio, disattivare l'evento di movimento dell'hopper può rompere i plugin di protezione che ne dipendono. Un piccolo miglioramento dei tempi non giustificherebbe l'aggiramento silenzioso di una regola del server.

Il riferimento di spigot.yml citato è mantenuto da Paper e comprende comportamenti specifici di Paper. Non dia per scontato che ogni opzione annidata documentata esista o si comporti in modo identico su Spigot puro. Consulti la configurazione generata per la sua implementazione e versione prima di aggiungere una chiave.

6. Segua il profilo oltre le impostazioni di distanza

Indaghi sul lavoro dei plugin

Se il report indica un'attività di un plugin, salvi il report e controlli la configurazione, la compatibilità e le note di rilascio di quel plugin. Paper raccomanda esplicitamente di condividere un report spark pertinente con gli sviluppatori dei plugin quando si indagano problemi di prestazioni.

Riproduca il problema, se possibile, su una copia di prova con backup. Cambi una funzionalità o un plugin alla volta, rispettando le dipendenze, e poi ripeta la stessa attività. Eviti di disattivare plugin di protezione o di economia sul server attivo solo per vedere se i TPS salgono.

Anche la messa a punto di Java e della memoria deve basarsi su evidenze. Esamini il comportamento del garbage collector e i requisiti Java della build esatta del suo server prima di cambiare le opzioni di avvio. Una raccolta copiata di flag GC non è un passaggio di ottimizzazione universale.

Pregeneri solo quando il problema è la generazione

Quando il rallentamento coincide con l'esplorazione, confronti gli spostamenti nel terreno esistente con quelli verso terreno nuovo. Se il profiling indica la generazione dei chunk come collo di bottiglia, la pregenerazione sposta quel lavoro di generazione prima del normale gioco. Chunky offre strumenti a questo scopo.

Scelga l'area e le dimensioni desiderate, verifichi la capacità del disco e dei backup e pianifichi il lavoro fuori dagli orari di punta. Provi prima un'area limitata. La pregenerazione non elimina il costo di caricare o inviare i chunk esistenti, né quello di eseguire le farm al loro interno.

Le guide della community non concordano su quanto debba essere raccomandata in modo generalizzato la pregenerazione per i server moderni. La consideri una risposta a una pressione di generazione misurata, non una manutenzione obbligatoria per ogni installazione di Paper.

7. Verifichi il gameplay prima di mantenere la modifica

Ripeta il carico di lavoro originale con un numero e una distribuzione di giocatori comparabili. Conservi insieme i report spark prima e dopo, la differenza di configurazione e le note. Ripeta il confronto se le condizioni sono cambiate in modo sostanziale.

Poi testi il server nel modo in cui lo usano i giocatori:

Faccia funzionare le farm importanti dalle consuete posizioni AFK, includendo raccolta e trasporto.
Controlli gli scambi dei villager e il rifornimento nell'arco di un normale ciclo di lavoro.
Faccia funzionare smistatori a hopper e clock abbastanza a lungo da evidenziare oggetti persi o tempi alterati.
Controlli visibilità e comportamento dei mob durante gli spostamenti, e testi ogni mondo interessato.

Mantenga una modifica solo se il miglioramento misurato è utile e il compromesso sul gameplay è accettabile. Se il beneficio non è chiaro, ripristini il valore precedente. Non disattivi mai il salvataggio per far sembrare migliore un grafico delle prestazioni.

Se il collo di bottiglia rimanente sembra essere la capacità dell'hosting, usi il report per orientare quella discussione. Può consultare l'hosting Minecraft di SharpHeberg alla luce del suo carico di lavoro e dei suoi requisiti. Le scelte di hosting e le modifiche alla configurazione meritano lo stesso test: il server funziona meglio preservando il modo in cui gioca la sua community?

Letture correlate: Il costo reale di un server Minecraft ad alte prestazioni nel 2025. Consideri i prezzi di quell'articolo più vecchio come storici, non come tariffe attuali.