Il messaggio «A single server tick took 60.00 seconds» significa che il Watchdog ha rilevato tick medi troppo lunghi e ha terminato il processo con System.exit(1). Prima di fare qualsiasi altra cosa, esegui questi passaggi nei primi 5–10 minuti:
Azioni immediate:
- Salva subito
latest.loge l’eventuale crash report dalla cartellalogs/. - Apri
server.propertiese aumenta temporaneamentemax-tick-timeper guadagnare tempo di diagnosi. - Annota l’orario esatto del crash, le attività in corso (worldgen, backup, molti giocatori) e la lista delle mod attive.
- Riavvia il server in modalità diagnostica con il minor numero di mod possibile per isolare il responsabile.
Checklist minima (primi 10 minuti):
latest.logecrash-reports/salvati- Lista mod/plugin esportata (versioni incluse)
- Uptime del server al momento del crash
- Backup recente verificato e disponibile
- Argomenti JVM annotati (visibili nel pannello o nello script di avvio)
Punti chiave
Disabilitare il Watchdog con max-tick-time=-1 non risolve il problema sottostante: la diagnosi tramite timings e stacktrace è l’unico modo per eliminare gli errori max tick time in modo definitivo.
| Punto | Dettagli |
|---|---|
| Salva i log prima di tutto | latest.log e crash report sono le prove primarie: senza di essi la diagnosi è cieca. |
| Aumenta max-tick-time solo temporaneamente | Portare il valore a 120000 dà margine per diagnosticare, non è una soluzione permanente. |
| Usa /timings per isolare la causa | Il report di Paper mostra quale mod o handler consuma più tick time: è il punto di partenza. |
| Evita -1 in produzione | Disabilitare il Watchdog lascia il mondo esposto a corruzione se il thread principale si blocca. |
| AtomSync per server modati | Storage NVMe, backup automatici e supporto italiano riducono i fattori infrastrutturali che amplificano i crash da Watchdog. |
Indice
- Che cos’è max-tick-time e come funziona il Watchdog
- Quali sono le cause più comuni degli errori max tick time?
- Come diagnosticare passo dopo passo: log, timings, jstack e heap
- Soluzioni pratiche: dall’intervento immediato a quello avanzato
- Valori raccomandati e cosa evitare sui server modati
- Perché i limiti artificiali a volte peggiorano la situazione
- Checklist da inviare al supporto prima di aprire un ticket
- La prospettiva di chi gestisce hosting ogni giorno
- Un hosting stabile per server modati fa la differenza
- Fonti
- Domande frequenti
Che cos’è max-tick-time e come funziona il Watchdog
Il parametro max-tick-time in server.properties definisce il numero massimo di millisecondi che un singolo tick del server può impiegare prima che il Watchdog intervenga. Il valore di default documentato è 60000 (60 secondi); impostare -1 disabilita completamente il Watchdog.
Se uno di questi supera la soglia impostata, il Watchdog lancia un’eccezione e chiude il server. Ma c’è un dettaglio che molti ignorano: il Watchdog non si attiva solo su un singolo tick estremo. Secondo il bug tracker ufficiale Mojang (MC-121586), il meccanismo può arrestare il server anche quando la media dei tick rimane troppo alta per un periodo prolungato. Con un valore di max-tick-time standard, la soglia critica per tick medio sostenuto è relativamente bassa.
Riga di log tipica al momento del crash:
A single server tick took 60.00 seconds (should be max 0.05)Il server chiamaSystem.exit(1)e scrive lo stacktrace completo nel crash report. Quella riga è il punto di partenza di ogni diagnosi.
In server.properties trovi due configurazioni comuni:
max-tick-time=60000 # default: Watchdog attivo, soglia 60 s
max-tick-time=-1 # Watchdog disabilitato (sconsigliato in produzione)
Impostare -1 impedisce lo spegnimento automatico, ma non risolve il lag sottostante. Il mondo rimane congelato finché il thread principale non si sblocca, con rischio di corruzione dei dati.
Quali sono le cause più comuni degli errori max tick time?
Gli errori di sincronizzazione legati al tick time hanno quasi sempre un’origine identificabile. Ecco le categorie principali, in ordine di frequenza su server modati:
- Mod con loop sincroni: mod che eseguono calcoli pesanti sul thread principale (pathfinding personalizzato, generazione procedurale, simulazioni fisiche) sono la causa numero uno sui server modati.
- Accumulo di entità e tile entities: centinaia di mob, item frame, fornaci attive o macchine di mod industriali in un’area ristretta saturano il tick. Un singolo chunk con 500+ entità può bastare.
- Generazione di chunk (chunkgen): esplorare nuovi territori su server modati con biomi complessi è tra le operazioni più pesanti. Il thread principale si blocca durante la generazione sincrona.
- I/O su disco lento: salvataggio del mondo su HDD meccanico, snapshot simultanei o antivirus che scansionano la cartella del server durante il gioco.
- GC pause della JVM: garbage collection mal configurata può fermare tutti i thread per centinaia di millisecondi. Con heap grandi e GC di default, le pause sono frequenti.
- Backup pianificati in orario di gioco: plugin di backup che comprimono la cartella del mondo mentre il server è attivo bloccano l’I/O e il thread principale.
- CPU saturata o condivisa: su hosting con risorse condivise, un picco di un altro tenant può rubare cicli CPU al tuo server nel momento peggiore.
Come distinguere un singolo tick anomalo da un degrado progressivo: se il crash avviene sempre allo stesso orario (backup notturno, worldgen al login di un giocatore), la causa è puntuale. Se il server degrada lentamente nel corso di ore, stai probabilmente accumulando entità o leak di memoria.
Un consiglio: prima di toccare qualsiasi configurazione, cerca nel log la riga immediatamente precedente al crash. Spesso contiene il nome del plugin o della mod responsabile, risparmiandoti ore di diagnosi.
Come diagnosticare passo dopo passo: log, timings, jstack e heap
1. Leggere il log e lo stacktrace
Apri logs/latest.log e cerca la stringa A single server tick took. Le righe successive mostrano lo stacktrace del thread principale al momento del freeze. Cerca il frame più in alto che non appartiene al codice vanilla di Minecraft: quello è quasi sempre il colpevole. Salva l’intero blocco, dalla riga del timeout fino alla fine dello stacktrace.
2. Usare /timings su Paper/Spigot
Esegui /timings on prima di replicare il problema, poi /timings paste per ottenere un URL condivisibile. Il report di timings mostra quanto tempo ogni plugin, entità e handler consuma per tick. Quando apri un ticket di supporto, allega sempre l’URL del paste, non uno screenshot.
Cosa cercare nel report timings: la colonna «% of tick» rivela immediatamente se un singolo plugin sta consumando la maggior parte del tempo disponibile. Un valore sopra il 20% per un singolo handler è un segnale inequivocabile.
3. Raccogliere un thread dump con jstack
Se il server è ancora in esecuzione ma lento, ottieni il PID del processo Java (visibile nel pannello o con ps aux | grep java) ed esegui:
jstack <PID> > threaddump.txt
Apri il file e cerca il thread Server thread. Se è in stato BLOCKED o WAITING con uno stacktrace che punta a una mod specifica, hai trovato il problema. Ripeti il comando tre volte a distanza di 5 secondi per confermare che il blocco sia persistente.
4. Heap dump e analisi GC
Per sospetti di memory leak o GC pause eccessive, aggiungi -XX:+HeapDumpOnOutOfMemoryError agli argomenti JVM. Per analisi GC, abilita il logging con -Xlog:gc*:file=gc.log e analizza il file con VisualVM o con jcmd <PID> GC.heap_info. Questo passaggio è necessario solo se il server degrada progressivamente nel tempo, non per crash singoli e isolati.
Soluzioni pratiche: dall’intervento immediato a quello avanzato
L’ordine conta. Parti sempre dal meno invasivo.
- Salva i log e aumenta temporaneamente max-tick-time a 120000. Questo ti dà margine per diagnosticare senza ulteriori crash. Non è una soluzione, è un cerotto.
- Identifica e rimuovi o aggiorna la mod sospetta. Lo stacktrace e i timings ti indicano il nome. Rimuovi la mod, riavvia, verifica se il problema scompare.
- Ottimizza spigot.yml e paper.yml. Riduci
mob-spawn-range, abbassaentity-activation-range, impostamerge-radiusper gli item. Su Paper, abilitause-faster-eigencraft-redstone: truese hai circuiti complessi. - Abbassa la view-distance. Passare da 10 a 6–8 chunk riduce drasticamente il carico di chunkgen e il numero di entità attive. Su server modati con biomi complessi, è spesso la modifica con il miglior rapporto sforzo/risultato.
- Sposta i backup in orari non di gioco. Pianifica i backup alle 4:00 o 5:00, quando il server è vuoto. Usa plugin che supportano backup incrementali invece di copiare l’intera cartella ogni volta.
- Tuning JVM per GC. Per server con 6+ GB di heap, sostituisci il GC di default con G1GC o ZGC. Un set di flag collaudato per Minecraft:
Guide tecniche sull’ottimizzazione dei server Minecraft confermano che il tuning GC riduce le pause sul thread principale in modo misurabile.-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions - Passa a storage NVMe. Su HDD meccanico, il salvataggio del mondo durante il gioco può bloccare l’I/O per secondi; considera anche di migliorare le prestazioni con gaming kontrolerji se usi periferiche per il tuo ambiente di gioco. NVMe riduce i tempi di scrittura di un ordine di grandezza.
- Imposta max-tick-time=-1 solo come ultima risorsa temporanea, durante sessioni di worldgen controllate o test di mod, mai in produzione con giocatori attivi. Il rischio di corruzione del mondo è reale.
Valori raccomandati e cosa evitare sui server modati
Per un server modato standard, mantieni max-tick-time=60000. Se le mod che usi includono worldgen pesante (tipo Biomes O’ Plenty, Terralith o pack di modpack complessi), considera 120000 durante le prime sessioni di esplorazione, poi riportalo al default.
Nota pratica: molti provider espongono un campo dedicato nel pannello per modificare max-tick-time senza accedere manualmente a
server.properties. Utile per emergenze rapide, ma non sostituisce la diagnosi.
Parametri JVM consigliati come punto di partenza per server modati con 8 GB di RAM:
-Xms4G -Xmx8G -XX:+UseG1GC -XX:+ParallelRefProcEnabled
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions
-XX:+DisableExplicitGC -XX:G1NewSizePercent=30
Cosa evitare:
- Limitare le entità in modo aggressivo (es. cap a 50 mob totali) senza aver profilato prima: alcune mod dipendono da entità specifiche per funzionare correttamente e un cap brutale introduce bug difficili da tracciare.
- Applicare patch di ottimizzazione non testate (fork non ufficiali, patch sperimentali) direttamente in produzione senza un ambiente di test separato.
- Aumentare la RAM oltre la capacità fisica del nodo: swap su disco è peggio di un heap piccolo.
Su server vanilla, max-tick-time raramente va toccato. Su server modati, invece, aggiustamenti temporanei sono parte normale della gestione, come confermano anche guide dedicate a server.properties.
Perché i limiti artificiali a volte peggiorano la situazione
Aikar, sviluppatore storico di Paper/Spigot, ha argomentato chiaramente contro l’uso meccanico di max-tick-time come strumento di stabilità. La sua analisi tecnica mostra come i limiter grossolani mascherino i problemi invece di risolverli, creando una falsa sensazione di stabilità.
Il punto centrale è questo: se una mod esegue un loop sincrono che dura 80 ms ogni tick, alzare max-tick-time a 120.000 non cambia nulla al comportamento della mod. Il server continuerà a essere lento, i giocatori continueranno a vedere lag, e il Watchdog si attiverà comunque in condizioni di carico elevato. L’unica differenza è che ci vorrà più tempo prima che il server si spenga, lasciando potenzialmente il mondo in uno stato inconsistente più a lungo.
Lo stesso vale per i limiter in spigot.yml e paper.yml: limitare l’elaborazione delle entità senza capire quali entità causano il problema può rompere meccaniche di mod che dipendono da aggiornamenti frequenti. Gli sviluppatori Paper raccomandano /timings e analisi reali come strumento primario, non i cap arbitrari.
Un consiglio: se usi /timings e non riesci a interpretare il report, condividilo su Discord o nel forum di Paper prima di toccare qualsiasi configurazione. Un occhio esperto ci mette meno di un minuto a identificare il collo di bottiglia.
Il monitoraggio continuo tramite JMX (il MBean net.minecraft.server espone averageTickTime) è la strategia più efficace per intercettare il degrado prima che diventi un crash. Configura un alert quando averageTickTime supera i 100 ms e avrai un preavviso di minuti, non di secondi.
Checklist da inviare al supporto prima di aprire un ticket
Quando contatti il supporto tecnico, fornisci subito questi elementi per evitare scambi inutili:
logs/latest.logcompleto (non solo le ultime righe)- Crash report dalla cartella
crash-reports/(file.txtcon timestamp) - URL del paste
/timings(eseguito prima del crash se possibile) - Lista completa di mod e plugin con versioni (file
modlist.txto export dal launcher) - Argomenti JVM usati all’avvio (visibili nel pannello o nello script
start.sh) - Orario esatto del crash e fuso orario
- Attività in corso al momento del crash (quanti giocatori, cosa stavano facendo)
- Snapshot del pannello di hosting con utilizzo CPU e RAM al momento dell’evento
- Versione di Minecraft, versione di Paper/Spigot/Forge/Fabric
- Eventuali modifiche recenti (mod aggiunte, aggiornamenti, cambi di configurazione)
Template rapido per il ticket:
Per una guida completa su come strutturare una richiesta di supporto tecnico per server di gioco, puoi consultare la procedura dettagliata sul blog di AtomSync.
La prospettiva di chi gestisce hosting ogni giorno
Gestire errori di tick time su server modati è una delle richieste di supporto più frequenti che riceviamo. La maggior parte dei casi si risolve in tre passaggi: leggere lo stacktrace, identificare la mod responsabile, aggiornarla o rimuoverla. Il problema è che molti amministratori saltano il primo passaggio e vanno direttamente a toccare max-tick-time, trasformando un problema diagnosticabile in un server instabile senza una causa chiara.
Un hosting professionale può fare molto: risorse dedicate su NVMe, backup automatici pianificati fuori dagli orari di gioco, monitoraggio delle metriche di sistema. Ma non può sostituire la diagnostica applicativa. Se il problema è una mod con un loop sincrono, nessun hardware lo risolve. Quello che un buon hosting può fare è darti gli strumenti per diagnosticare velocemente (accesso ai log, pannello con metriche in tempo reale, supporto tecnico che conosce Minecraft) e un ambiente stabile dove il problema non è amplificato da risorse condivise o storage lento.
Quando un cliente ci porta un crash da Watchdog, la prima cosa che chiediamo è sempre lo stacktrace completo e i timings. Se non li ha, li aiutiamo a raccoglierli. Se il problema è nell’infrastruttura (I/O, CPU, memoria), lo vediamo subito dalle metriche del pannello. Se è applicativo, lo stacktrace lo dice chiaramente.
Un hosting stabile per server modati fa la differenza
I problemi di tick time su server modati spesso non dipendono dalla configurazione, ma dall’infrastruttura sottostante. Storage lento, CPU condivisa con altri tenant, backup che girano durante il picco di gioco: sono tutti fattori che amplificano qualsiasi inefficienza nelle mod.
AtomSync è progettato per server modati che richiedono stabilità reale: storage NVMe su ogni piano, risorse dedicate, backup automatici quotidiani pianificati fuori dagli orari di gioco e protezione DDoS fino a 1 Tbps. Il pannello Pterodactyl personalizzato mostra CPU, RAM e I/O in tempo reale, così puoi correlare un picco di utilizzo con un crash nel log senza dover aprire un ticket. Il supporto in italiano via Discord è disponibile nei giorni lavorativi e conosce Minecraft in modo specifico, non generico.
Se gestisci un server modato e vuoi smettere di rincorrere crash da Watchdog, attiva un piano su AtomSync con garanzia di rimborso nelle prime 48 ore e nessun vincolo contrattuale.
Fonti
Domande frequenti
Che cos’è il max tick time in Minecraft?
max-tick-time è un parametro di server.properties che definisce in millisecondi quanto può durare un singolo tick prima che il Watchdog arresti il server. Il valore di default è 60000 (60 secondi); impostare -1 disabilita il controllo.
Quanti tick al secondo esegue Minecraft?
Quando un tick supera la soglia impostata in max-tick-time, il Watchdog interviene.
Quanto dura 1000 tick in Minecraft?
Un certo numero di tick corrisponde a un frazione di secondo di tempo di gioco, assumendo che il server giri alla velocità nominale senza lag.
Come si aumenta il max tick time?
Apri server.properties, trova la riga max-tick-time=60000 e modifica il valore (es. 120000 per 2 minuti). Molti provider espongono questo campo direttamente nel pannello di hosting. Riavvia il server dopo la modifica. Ricorda che si tratta di una misura temporanea: la causa del problema va identificata con /timings o analizzando lo stacktrace.
Quando è sicuro impostare max-tick-time=-1?
Solo durante sessioni controllate di worldgen o test di mod, senza giocatori attivi. In produzione, disabilitare il Watchdog espone il mondo a corruzione dei dati se il thread principale si blocca indefinitamente, come documentato nel bug tracker Mojang.