I tre messaggi di lag più frequenti nel log di Minecraft non significano la stessa cosa: Can't keep up! Is the server overloaded? significa che il tuo server continua a girare, ma non riesce a stare al passo. A single server tick took 60.00 seconds significa che il freno di emergenza integrato lo ha terminato in modo forzato. Exception in server tick loop significa che un errore concreto di programma ha mandato in crisi il ciclo di gioco. Se tratti tutti e tre allo stesso modo, di solito ripari la cosa sbagliata.
Distinguere i tre messaggi
Minecraft calcola il mondo di gioco 20 volte al secondo. Ogni ciclo si chiama tick e può durare al massimo 50 millisecondi. Tutto il lag che percepisci è una deviazione da questo singolo numero.
| Messaggio di log | Cosa è successo davvero | Il server è ancora in esecuzione? |
|---|---|---|
Can't keep up! Is the server overloaded? Running 5074ms or 101 ticks behind |
I tick durano più di 50 ms, il server sta recuperando arretrato | Sì, ma è sensibilmente lento |
A single server tick took 60.00 seconds + Considering it to be crashed |
Un singolo tick ha superato max-tick-time; il Watchdog ha terminato il processo |
No, terminato forzatamente |
Exception in server tick loop |
Un errore è arrivato fino al ciclo principale | No, di solito con crash report |
Dispatched async TPS command (avviso Paper) |
La nostra misurazione TPS interroga il server dall'esterno | Sì, è normale |
L'ultima riga crea spesso confusione: Paper segnala ogni interrogazione esterna come avviso. È la nostra misurazione programmata delle prestazioni circa ogni cinque minuti, non un errore e non un intervento nel tuo gioco.
Il passaggio più importante: per i messaggi Watchdog leggi verso l'alto
Il kill del Watchdog è un sintomo, non una causa. Dice solo che qualcosa ha bloccato il thread del server più a lungo del consentito. Cosa lo ha bloccato si trova altrove.
Ci sono due casi, e portano a misure completamente diverse:
Caso 1 — il Watchdog è arrivato per primo. Prima della riga del Watchdog c'è normale attività di gioco. In quel caso il tempo del tick è davvero il messaggio: qualcosa ha congelato il server mentre era in esecuzione.
Caso 2 — il Watchdog è arrivato dopo. Prima della riga del Watchdog c'è già Stopping server o Preparing crash report. Allora il server era già morto o in fase di spegnimento, e il Watchdog ha solo eliminato uno spegnimento bloccato.
Questo secondo caso non è raro. In un caso di supporto del 22 agosto 2026, il thread del server è crashato alle 13:20:15, ha iniziato un regolare Stopping server e solo 60 secondi dopo è scattato il Watchdog. Chi in quel punto dichiara che la durata del tick sia la causa manda il gestore lontano dal vero messaggio di errore, che stava un minuto più in alto. Proprio per questo la nostra analisi della console valuta intenzionalmente il Watchdog per ultimo: se nello stesso tratto di log c'è una firma più specifica, ti mostriamo quella spiegazione e non “un tick era lento”.
Passo dopo passo fino alla causa
1. Controllare l'andamento TPS nel pannello
Apri il tuo server nel pannello. Sotto “Performance (ultime 24h)” vedi l'andamento TPS; viene misurato circa ogni cinque minuti finché il server è in esecuzione. La forma della curva dice già molto:
- Un calo netto a una certa ora → un evento. Confronta l'ora con il log: generazione del mondo, un backup, un giocatore in territorio inesplorato, un task di plugin.
- Valori bassi in modo continuo → sovraccarico strutturale. Qui non aiuta un riavvio, ma serve alleggerire il carico.
- Schema a dente di sega → tipico della pressione sulla memoria: il server lavora, la Garbage Collection interrompe, e il ciclo si ripete.
Se i valori restano bassi per una finestra più lunga, il pannello ti avvisa da solo con l'indicazione “TPS costantemente basso”.
2. Misurare MSPT: il solo TPS non basta
Inserisci nella console /spark tps. Il comando restituisce due numeri, e il secondo è il più importante:
- TPS — tick al secondo, massimo 20.
- MSPT — millisecondi per tick. Tutto fino a 50 ms è sano.
Perché MSPT? Bukkit, Spigot e Paper rallentano i processi del server per evitare un crash. Per questo l'indicatore può mostrare 20 TPS pieni, mentre in realtà il server sta già lavorando al limite. Un valore MSPT di 45 ms significa: sei a una mob farm di distanza dal lag visibile, anche se l'indicatore TPS sembra ancora perfetto.
Su Paper dalla 1.21 spark è già incluso, non devi installare nulla.
3. Profilare il responsabile
Non indovinare quale plugin sia colpevole: misuralo:
/spark profiler start --timeout 120
In questi due minuti ricrea la situazione che causa lag. Poi apri il link del risultato emesso dal server. Il report mostra, ordinato per quota di tempo, dove finisce il tempo dei tick: una mod specifica, un task di plugin, caricamento dei chunk, elaborazione delle entità o Garbage Collection.
Questo è il punto in cui questa guida si separa dal “compra più RAM”. Il profiler risponde alla domanda a cui una tabella di raccomandazioni non può rispondere: cosa sta davvero consumando tempo sul tuo server?
4. Alleggerire in modo mirato
Quello che mostra il profiler determina la misura da adottare:
| Il profiler mostra | Misura efficace |
|---|---|
| Caricamento dei chunk, generazione del mondo | Abbassare simulation-distance (default 10, minimo 3): incide più di view-distance, perché solo i chunk simulati consumano tempo di calcolo |
| Elaborazione delle entità | Limitare le mob farm, recintare gli animali invece di lasciarli liberi, ripulire gli accumuli di item |
| Redstone / tick dei blocchi | Costruire clock Redstone con observer invece di loop di repeater, disattivare i meccanismi sempre attivi |
| Un singolo plugin o una mod | Disattivarlo per prova e misurare di nuovo; cercare un'alternativa o una versione più aggiornata |
| Garbage Collection | Ora più RAM è la risposta giusta, non prima |
L'ultimo punto è importante: la RAM risolve solo un problema di memoria. Se un clock Redstone consuma il tempo dei tick, un piano più grande non rende il server più veloce. Il nostro calcolatore RAM per Minecraft ti calcola quanta memoria serve per il tuo numero di giocatori e la dimensione del modpack.
5. max-tick-time: l'eccezione, non la soluzione
Il valore si trova in server.properties e stabilisce da quale durata del tick interviene il Watchdog. Lo standard è 60000 millisecondi, cioè 60 secondi. Se il valore viene superato, il server termina sé stesso.
Molte guide in rete consigliano a questo punto di disattivare il Watchdog con -1. Non farlo come soluzione standard. Il Watchdog è l'unica istanza integrata che nota davvero un deadlock reale. Con -1, un server morto resta appeso alla porta per ore: i giocatori non riescono a entrare, niente nel log spiega perché e nessuno viene avvisato. Hai rimosso l'indicatore, non il problema.
C'è esattamente una buona ragione per aumentarlo: un'operazione nota richiede legittimamente molto tempo. Il caso classico è il primo avvio di un grande modpack, in cui generazione del mondo e inizializzazione delle mod passano insieme oltre un minuto in un tick. Allora un valore come 180000 (tre minuti) è accettabile, temporaneamente e con l'intenzione di riportarlo al valore precedente dopo il primo avvio riuscito.
Quando nel log c'è Exception in server tick loop
Questo messaggio è il più semplice dei tre, perché porta con sé la propria causa. Subito sotto, o poche righe dopo, trovi una riga Caused by:: lì c'è il vero errore, di solito con il nome della mod o del plugin responsabile.
Procedura:
- Cerca
Caused by:e annota il nome della classe. - Se contiene il nome di una mod o di un plugin, il responsabile è indicato.
- Se l'errore è comparso dopo una modifica (nuova mod, aggiornamento, nuovo mondo), annulla prima quella modifica.
- Se l'errore resta poco chiaro, invia l'intera sezione al supporto, con l'orario.
L'analisi della console del tuo server riconosce automaticamente queste righe e spiega ogni messaggio rilevato in testo chiaro, inclusa la frequenza. Se hai solo un pezzo di log da altrove, puoi incollarlo nel nostro analizzatore di crash report, anche senza avere un server da noi.
Cosa facciamo automaticamente per te
- Misurazione delle prestazioni senza intervento. Il TPS viene registrato circa ogni cinque minuti e mostrato nel pannello per 24 ore: non devi installare alcun plugin.
- Avviso in caso di debolezza persistente. Se le prestazioni restano basse per una finestra affidabile, vieni avvisato invece di doverlo notare da solo.
- Righe di log spiegate. I messaggi riconosciuti ricevono causa e soluzione in testo chiaro, nella tua lingua, e dove esiste una guida adatta trovi un link.
- Regola sintomo prima della causa. Se nello stesso tratto di log c'è un messaggio di errore più significativo del kill del Watchdog, ti mostriamo quello.
Troubleshooting: sintomo, controllo, soluzione
| Sintomo | Controllo | Soluzione probabile |
|---|---|---|
| Lag solo quando si esplorano nuove aree | Succede quando i giocatori entrano in territori inesplorati? | Generazione del mondo; abbassare simulation-distance, far pregenerare il mondo |
| Lag a orari fissi | Confrontare l'orario con i task programmati | Spostare temporalmente il backup o il piano di riavvio |
| Il server si ferma senza errore, il log termina di colpo | Alla fine c'è A single server tick took? |
Kill del Watchdog; leggere il minuto precedente |
| TPS mostra 20, ma scatta comunque | /spark tps: guardare MSPT |
Il limiter TPS nasconde il carico; decidere in base a MSPT |
| Dopo l'aggiunta di una mod | Rimuovere la mod e misurare di nuovo | Conflitto di mod o mod pesante |
| Dente di sega nell'andamento TPS | Controllare la Garbage Collection nel profiler | Pressione sulla memoria; aumentare la RAM |
| “Dispatched async TPS command” nel log | Solo questa riga, per il resto tutto normale | Nulla da fare: è la nostra misurazione |
FAQ
Da quale valore TPS i giocatori notano qualcosa?
Fino a circa 18 TPS nel gioco non si nota nulla. Sotto 15 diventa sensibilmente lento. Però non fidarti solo di questo: controlla anche MSPT, perché il limiter TPS può mostrare un numero sano mentre il server sta già lavorando al limite.
Più RAM aiuta contro il lag?
Solo se la memoria è davvero il collo di bottiglia. Se il profiler mostra la Garbage Collection come voce principale, sì. Se mostra un clock Redstone o una mob farm, più RAM non cambia nulla. Prima misura, poi acquista.
Devo disattivare il Watchdog?
No, non in modo permanente. -1 ti toglie l'unico rilevamento automatico di un vero congelamento. Un aumento temporaneo di max-tick-time per un'operazione nota e lenta, come il primo avvio di un modpack, è accettabile; poi va riportato indietro.
Perché il messaggio del Watchdog compare dopo “Stopping server”?
Perché il server era già in fase di spegnimento e si è bloccato lì. Il Watchdog ha quindi eliminato uno spegnimento bloccato, non ha abbattuto un server in esecuzione. La causa si trova prima di Stopping server.
Un riavvio aiuta?
Contro un arretrato acuto sì, contro la causa no. Se il lag torna poco dopo ogni riavvio, è strutturale: allora solo la misurazione porta avanti.
Qual è la differenza tra view-distance e simulation-distance?
view-distance determina quanto lontano vedono i giocatori; simulation-distance determina quanto lontano viene davvero calcolato il mondo. Entrambi sono di default a 10 chunk. Poiché solo i chunk simulati consumano tempo di calcolo, abbassare simulation-distance offre più sollievo con meno perdita visibile.
Se continua a laggare
Prima di contattare il supporto, raccogli tre cose: l'orario esatto dell'ultimo episodio, il link del tuo report spark profiler e l'indicazione di quali mod o plugin sono stati aggiunti di recente. Così si può controllare in modo mirato la sezione giusta del log, invece di fare un giro generico di ottimizzazione.
Le impostazioni generali valide per tutti i giochi, come piani di riavvio, scelta del piano e rete, le trovi nella guida Migliorare le prestazioni del gameserver. Come installare e rimuovere in modo pulito mod e plugin è spiegato in Installare mod e plugin per Minecraft.
Vuoi un server con misurazione TPS, spiegazione dei log e avvisi inclusi senza lavoro extra? Su Noleggiare un server Minecraft trovi i piani adatti.
Fonti e banco di prova
max-tick-time, tickrate e distanze: PaperMC — server.properties. Documenta il valore standard di 60000 millisecondi, la terminazione forzata al superamento, la disattivazione con-1e i valori standard 10 perview-distanceesimulation-distance.- spark è incluso in Paper: PaperMC — Profiling. Da Paper 1.21 non serve un download separato.
- MSPT prima di TPS: spark — TPS and MSPT. Spiega perché il limiter TPS può mostrare 20 pieni mentre il server in realtà gira più lentamente.
- Comandi del profiler: spark — Command Usage. Fonte per
/spark profiler start --timeout <sekunden>e/spark profiler stop.
Banco di prova: 24 agosto 2026. Valori standard e comandi possono cambiare con nuove versioni del server; in caso di dubbio controlla la documentazione del produttore linkata.