Server Minecraft che lagga? Trova la causa prima di intervenire

Prima di cambiare una sola impostazione, scopri quale dei tre lag hai: il ciclo di tick del server che resta indietro, la rete tra i giocatori e il server, oppure il computer di un giocatore che fatica a disegnare il gioco. Esegui /spark tps nella tua ora più affollata. Se le durate dei tick restano sotto i 50 ms, il server regge, e il lag che sentono i tuoi giocatori viene da un'altra parte.

La maggior parte delle «guide all'ottimizzazione» salta questo passaggio e ti consegna un elenco di impostazioni. Alcune aiutano, qualcuna peggiora il gioco, e nessuna risolve un problema che non hai trovato. Questa guida parte dalla diagnosi.

Tre tipi di lag (tick del server, rete, client)

Una piccola digressione da nerd sui numeri, perché spiega perché i TPS mentono. Il server punta a 20 tick al secondo, quindi ogni tick ha un budget di 50 ms. I TPS non possono mai superare 20, il che significa che un server che impiega 10 ms per tick e uno che ne impiega 48 mostrano entrambi 20,0 TPS. Il primo potrebbe reggere diverse volte il carico attuale, il secondo è a una farm di tramogge dal lag. L'MSPT (millisecondi per tick) mostra questo margine, quindi guarda l'MSPT, non i TPS.

Misura prima di cambiare qualsiasi cosa

1. Scegli l'ora giusta. Un lag che si verifica al picco non si misura alle cinque del mattino. Le quattro ore più affollate di tutta la nostra lista sono dalle 14:00 UTC alle 18:00 UTC nel tuo fuso orario, e la pagina pubblica delle statistiche della tua scheda mostra le tue ore più affollate.
2. Esegui /spark tps. Mostra i TPS degli ultimi 5 secondi fino agli ultimi 15 minuti e le durate dei tick come minimo, mediana, 95° percentile e massimo. Una mediana ben sotto i 50 ms con un 95° percentile sopra indica picchi, non un sovraccarico costante. Il /mspt di Paper ne dà la versione breve.
3. Esegui /spark health. Aggiunge uso della CPU, memoria e disco, così vedi a colpo d'occhio se alla macchina stessa manca qualcosa.
4. Leggi la console. L'avviso vanilla Can't keep up! Is the server overloaded? Running 2034ms or 40 ticks behind (la console del server lo scrive in inglese) significa che il server è rimasto indietro ed è saltato avanti per recuperare. Uno al giorno è rumore. Uno al minuto è un problema.
5. Annota i valori di partenza: ora, giocatori online, mediana e 95° percentile dell'MSPT, e dove si trovavano i giocatori (una zona nuova, una farm grande, un evento). Dopo ogni modifica confronterai con questi.

Su un server senza spark, il comando /tick query di vanilla (Java Edition 1.20.3 e successive, livello di permesso 3) riporta il tempo medio per tick e i suoi percentili.

Picco 16:00 UTC

0003060912151821

Orari in UTC

Più affollato alle 16:00 UTC con circa 17.845 giocatori, più tranquillo alle 01:00 UTC. L’ora più affollata ha 2,6 volte i giocatori di quella più tranquilla.

Misurato il 19 ott 2026, 22:55 UTCCome misuriamo

Leggere un profilo spark

Quando i numeri dicono che il server è lento, il profiler dice perché. La documentazione di PaperMC suggerisce:

/spark profiler start --timeout 600

Questo campiona ogni thread per dieci minuti e ti dà un link al rapporto. Due varianti aiutano con problemi specifici:

• /spark profiler start --only-ticks-over 100 registra solo i tick più lenti di 100 ms, il che isola i picchi di lag brevi dal rumore di fondo normale.
• /spark tickmonitor --threshold-tick 100 stampa una riga ogni volta che un tick dura più di 100 ms, così puoi collegare i picchi a ciò che succedeva in gioco.

Il profilo deve girare mentre il lag si verifica. Il profilo di un server tranquillo alle 05:00 non ti dice niente sul lag delle 18:00.

Nel viewer, apri il thread del server e segui verso il basso la percentuale più grande. Cerchi il ramo dove va il tempo:

• Il ticking delle entità, spesso con l'IA dei mob o la ricerca del percorso dei villager sotto, indica i mob (sezione successiva).
• Le block entity, con le tramogge in alto nell'elenco, indicano catene di tramogge e sistemi di stoccaggio.
• Il lavoro sui chunk (generazione, caricamento, salvataggio) indica giocatori che esplorano terreno nuovo.
• Il nome di un plugin nell'albero delle chiamate, o in alto nella ripartizione per plugin del viewer, indica quel plugin. Annota cosa stava facendo (un gestore di eventi, un'attività pianificata, una chiamata al database) prima di dargli la colpa, perché lo stesso plugin può andare bene con un'altra impostazione.

Anche la garbage collection viene registrata da spark. Pause frequenti di centinaia di millisecondi indicano pressione sulla memoria, che /spark gc mostra nel tempo. Fai un profilo anche una volta quando il server sta bene, così sai com'è la normalità sulla tua configurazione.

I soliti sospetti (entità, generazione dei chunk, redstone, plugin, garbage collection)

Entità

Farm di mob, sale di scambio con i villager, mucchi di oggetti a terra, sistemi di vagonetti e decorazioni con supporti per armature fanno tutti tick. Su Paper, /paper entity list mostra le entità che fanno tick per tipo, e un filtro come /paper entity list minecraft:villager restringe la ricerca per trovare dove si accumulano. /paper mobcaps mostra quanto sono pieni i limiti dei mob, e /paper chunkinfo quanti chunk sono caricati e fanno tick. Le soluzioni sono limiti, non divieti: un tetto di entità per chunk, regole per le farm su cui i tuoi giocatori sono d'accordo, e due parole con chi ha costruito la sala da 400 villager.

Generazione dei chunk

Generare un chunk nuovo è una delle cose più costose che un server faccia, e i giocatori con le elitre possono chiederne decine al minuto. Pregenera il mondo una volta, con un plugin come Chunky (/chunky radius 5000, poi /chunky start), nelle ore tranquille, e imposta un bordo del mondo corrispondente con /worldborder set 10000. Il bordo prende un diametro, il raggio di Chunky ne è la metà, quindi i due numeri descrivono lo stesso quadrato. Dopo, esplorare carica solo chunk dal disco, che costa molto meno.

Redstone e tramogge

Orologi di redstone veloci e lunghe catene di tramogge si sommano. Paper offre due leve in config/paper-world-defaults.yml. misc.redstone-implementation: ALTERNATE_CURRENT sostituisce l'implementazione della polvere di redstone con una più veloce. hopper.disable-move-event: true rende le tramogge più leggere, ma rompe i plugin che si basano su quell'evento, come alcuni plugin di protezione e di filtro per tramogge, quindi prova prima. hopper.cooldown-when-full è già attivo di default.

Plugin

Un plugin pesante compare per nome nel profilo. I casi comuni sono scoreboard, ologrammi o liste dei giocatori che si ricostruiscono a ogni tick, richieste al database o al web fatte sul thread principale, renderer di mappe che macinano un mondo grande e controlli anti-cheat sotto carico. La soluzione di solito è prima la configurazione (intervalli di aggiornamento, limiti di rendering), poi un aggiornamento, poi una sostituzione.

Garbage collection

Se spark mostra pause di raccolta lunghe o frequenti, controlla la memoria prima di tutto: -Xmx è troppo piccolo per il mondo e i plugin, e -Xms è impostato allo stesso valore? I flag consigliati da PaperMC sono una base solida. Più memoria aiuta solo quando il problema è la raccolta, e su un host condiviso, allocarla tutta toglie risorse al sistema operativo.

Correzioni che funzionano

Una volta nota la causa, queste sono le modifiche che di solito ripagano, più o meno nell'ordine in cui le proveremmo:

La modifica a simulation-distance è più grande di quanto sembri. Intorno a ogni giocatore il server fa tick di circa un quadrato di chunk, quindi passare da 10 a 6 lo riduce da circa 21 per 21 chunk a 13 per 13, da circa 441 chunk a circa 169, mentre i giocatori continuano a vedere lontano quanto permette view-distance.

Alcuni consigli diffusi non servono. I plugin che cancellano tutti gli oggetti a terra ogni pochi minuti curano un sintomo e infastidiscono i giocatori. I plugin di «ottimizzazione» che promettono più TPS senza dire cosa cambiano meritano un profilo prima e dopo. E riavviare ogni due ore nasconde i problemi invece di trovarli.

Il lag di rete visto da fuori

Un dettaglio sorprende molti proprietari. Il ping di stato che usano le liste di server riceve risposta dai thread di rete del server, non dal ciclo di tick, quindi un server può avere un lag pesante in gioco e rispondere comunque al nostro pinger in pochi millisecondi. Il lag di tick non lo vediamo da fuori, ed è esattamente per questo che esiste spark. Dietro Velocity, il pinger parla sempre e solo con il proxy.

Quello che il nostro pinger può vedere è la rete. La pagina pubblica delle statistiche della tua scheda (/server/your-server/stats) mostra tre cose da leggere:

• Il tempo di risposta, cioè quanto ci ha messo il server a rispondere al nostro pinger, con la sua mediana, il suo intervallo abituale e un grafico. Il livello dipende soprattutto dalla distanza dal nostro pinger, nell'Europa occidentale, quindi un server negli Stati Uniti non mostrerà lì 10 ms, a meno che una rete di protezione non risponda da un punto di presenza vicino. Guarda la forma nel tempo, non il valore.
• I picchi sopra l'intervallo abituale. Se le risposte salgono molto sopra l'intervallo abituale solo nelle tue ore più affollate, la macchina o il suo collegamento di rete è saturo in quei momenti. Se l'intervallo è ampio a tutte le ore, sospetta il percorso o la rete dell'host.
• Il registro delle interruzioni. Le pause brevi sono riavvii o crash. Quelle lunghe meritano un'occhiata alla pagina di stato del tuo host e ai tuoi crash report.

Dal lato dei giocatori, chiedi ai giocatori colpiti un traceroute verso il tuo indirizzo (tracert su Windows, traceroute su macOS e Linux) e la loro regione. Se tutti in un paese hanno lag e nessun altro, è il percorso, e spostarsi o aggiungere una rete di protezione con un punto di presenza vicino può aiutare più di qualsiasi impostazione. I giocatori che non riescono proprio a connettersi hanno altri problemi, che la nostra guida agli errori di connessione tratta.

Quando riavviare, e quando no

I riavvii non sono gratis. Tutti quelli online vengono espulsi, e un giocatore espulso a metà combattimento una domenica sera se lo ricorda. I nostri dati sulle interruzioni mostrano come i proprietari le pianificano davvero.

Nei 30 giorni fino al 16 ottobre 2026, 90 schede della nostra lista erano giocabili almeno il 90% del tempo. 58 di queste hanno avuto almeno un'interruzione, che contiamo come tre o più ping di fila senza risposta giocabile, e insieme ne hanno avute 515. Misurata dal primo ping mancato all'ultimo, metà delle interruzioni era finita in meno di cinque minuti, e il decimo più lungo ha superato le due ore. 375 su 515 (73%) sono durate 15 minuti o meno, la durata di un riavvio o di un crash seguito da reboot.

Quando sono iniziate queste interruzioni brevi? Un'ora si distingue: le 04:00 UTC, con 39 delle 375, il segno tipico dei riavvii notturni programmati. Fuori da quell'ora si distribuiscono in modo abbastanza uniforme nella giornata. 64 delle 375 (17%) sono iniziate tra le 14:00 e le 18:00 UTC, le quattro ore più affollate della nostra lista, cioè più o meno la quota che ci si aspetterebbe se gli orari dei riavvii fossero scelti a caso.

19%Interruzioni brevi iniziate nelle quattro ore più affollate dell'intera lista, ultimi 30 giorni

Misurato il 19 ott 2026, 21:52 UTCCome misuriamo

In tempo reale, per gli ultimi 30 giorni: 472 interruzioni su 83 schede al 90% o più, con una mediana di 5 minuti minuti, e una quota pari a 70% di 15 minuti o meno. L'ora di inizio più comune per quelle brevi è 04:00 UTC nel tuo fuso orario, e l'ora più tranquilla dell'intera lista è 01:00 UTC.

Cosa ricavarne:

1. Riavvia nella tua ora più tranquilla, non a un numero tondo. La heatmap sulla pagina delle statistiche la mostra, e quando i server Minecraft sono più affollati mostra come cambia da regione a regione. Se i tuoi giocatori sono sparsi su più fusi orari, scegli il punto più basso della tua curva, non la mezzanotte.
2. Annuncialo con un conto alla rovescia in chat, e tienilo breve.
3. Riavvia per un motivo. Aggiornamenti, una perdita di memoria che stai inseguendo, una modifica alla configurazione che lo richiede. Un riavvio quotidiano che non risolve niente costa comunque un'espulsione al giorno.
4. Trova la perdita invece di nasconderla. Se la memoria sale fino al riavvio, /spark heapsummary mostra cosa la sta riempiendo.

I riavvii non risolvono il lag di tick. Una farm che costa 30 ms per tick costa 30 ms per tick anche cinque minuti dopo un riavvio. Il nostro report sull'uptime ha i dati completi sulle interruzioni di tutta la lista.

Quando potenziare l'hardware

Potenzia quando lo dice il profilo. I segnali:

• L'MSPT al picco resta sopra circa 40 ms dopo che hai affrontato i sospetti qui sopra.
• Il profilo mostra tempo distribuito sul normale lavoro vanilla (entità, chunk, aggiornamenti dei blocchi) senza un singolo colpevole rimasto.
• Su un VPS, top mostra il CPU steal (il valore st) che sale nelle ore di punta, il che significa che i tuoi vicini usano core che stai pagando.

Poi compra prima la velocità del singolo core, perché il ciclo di tick gira su un core. Più RAM risolve solo i problemi di memoria. Oltre questo, la risposta è dividere il carico: più server dietro un proxy Velocity, oppure Folia per un mondo molto grande, due strade trattate nella nostra guida al software dei server. Scegliere l'hosting ha le domande da fare prima di pagare la nuova macchina.