Timings in Paper è deprecato: dalla versione 1.21 è sostituito da spark e in Paper 1.21.3 funziona in modalità no-op, quindi non restituisce dati utili. Per diagnosticare lag e cali di prestazioni va usato il comando /spark profiler start --timeout 600, che registra per dieci minuti e genera un report leggibile tramite browser.
In breve:
- La profilazione con spark richiede almeno dieci minuti di registrazione nel momento in cui si verifica il lag, preferibilmente usando filtri come --only-ticks-over per isolare i problemi.
- La visualizzazione sources consente di individuare facilmente plugin o mod che causano rallentamenti, riducendo il tempo di diagnosi rispetto al flame graph.
- La maggior parte dei crash legati a versioni recenti di Java si risolve passando a Java 21, mentre Java 23 può generare problemi documentati.
- È fondamentale avviare la profilazione durante il lag, poiché un report registrato in momenti di stabilità sarà privo di dati utili.
- Per minimizzare problemi di micro-lag ricorrenti, si consiglia di pianificare riavvii regolari del server e di ottimizzare configurazioni come view-distance e numero di entità.
Indice
- Come generare un report spark: requisiti e comandi utili
- Leggere il report spark: TPS, MSPT, albero e flame graph
- Checklist per isolare e risolvere i lag spike
- Documentazione ufficiale e punti di riferimento pratici
- Cosa conta davvero quando si passa da timings a spark
- Un’alternativa pratica: hosting ottimizzato con supporto dedicato
- Fonti
- Domande frequenti
Come generare un report spark: requisiti e comandi utili
Prima di avviare qualsiasi profilazione, conviene verificare se la versione di Paper installata include già spark o se serve aggiungerlo come plugin separato. Alcune build recenti lo integrano nativamente, altre richiedono l’installazione manuale: in quel caso va impostato il parametro paper.preferSparkPlugin=true per evitare conflitti tra la versione interna e quella del plugin.
Una volta confermata la disponibilità di spark, la sequenza operativa è semplice:
- Avvia la sessione con
/spark profiler start --timeout 600per registrare dieci minuti di attività del server. - Se il lag si manifesta solo in certi momenti, usa
--only-ticks-over 150per salvare solo i tick che superano una soglia espressa in millisecondi. - Per un monitoraggio continuo senza generare un report completo, usa
/spark tickmonitor, che segnala in tempo reale i tick fuori norma. - Al termine, spark fornisce un URL univoco con il report pronto per l’analisi.
La durata della sessione dipende dal tipo di problema: dieci secondi bastano per un picco isolato e riproducibile, mentre dieci minuti sono più indicati per catturare un comportamento intermittente. La documentazione ufficiale di Paper ricorda che la profilazione va avviata mentre il problema è in corso, perché un report registrato a vuoto non contiene dati utilizzabili.
Un consiglio: se non sai quando si verificherà il lag, lascia il profiler attivo con un timeout lungo e usa il filtro sui tick per isolare solo i momenti critici, invece di dover rileggere ore di dati.
Leggere il report spark: TPS, MSPT, albero e flame graph
Il server punta a 20 TPS, equivalenti a 50 millisecondi per tick, secondo la documentazione sulla tick loop di spark. Il problema è che una media accettabile può nascondere micro-lag ricorrenti: un MSPT medio di 40 ms può convivere con picchi isolati di 300 ms che i giocatori percepiscono comunque come scatti.
Il viewer di spark propone tre modalità di lettura, ciascuna utile per uno scopo diverso:
- L’albero dei thread mostra percentuali e millisecondi spesi in ogni ramo del codice, utile per capire da dove parte il carico.
- La flat view elenca le chiamate più costose indipendentemente dalla loro posizione nell’albero, comoda per individuare rapidamente il metodo più lento.
- Il flame graph rappresenta visivamente gli hotspot, con blocchi più larghi che corrispondono a più tempo impiegato.
- La vista sources raggruppa i tempi per plugin o mod, il modo più diretto per capire chi sta causando il rallentamento.
Una percentuale qualitativamente elevata di “sleep” nel tick loop indica un server sano, mentre valori più bassi segnalano un server costantemente sotto pressione, come spiegato nella guida alla tick loop di spark. Quando si analizza l’albero, conviene ignorare i nodi legati alle attese e concentrarsi sul “Server thread” e sui nodi con alto self time, che indicano dove il codice passa effettivamente più tempo a lavorare.
Checklist per isolare e risolvere i lag spike
Una volta ottenuto il report, la diagnosi segue uno schema ripetibile. Il primo errore comune è profilare quando il server è tranquillo: la documentazione PaperMC è chiara sul fatto che il profiler deve essere attivo mentre il sintomo si verifica, altrimenti il report non conterrà nulla di utile.
- Avvia la profilazione nel momento esatto in cui il lag si manifesta, non dopo.
- Filtra con
--only-ticks-overper isolare solo i tick realmente problematici e ignorare il rumore di fondo. - Nella vista sources, individua plugin con self time anomalo e disattivali temporaneamente per confermare l’ipotesi.
- Controlla sincronizzazioni di chunk, entità e circuiti redstone, cause frequenti di micro-lag ricorrente.
- Verifica la versione di Java installata: alcune combinazioni con Java 23 hanno generato crash documentati in una issue ufficiale di PaperMC, mentre Java 21 resta la scelta più compatibile.
- Applica correzioni mirate: aggiorna i plugin segnalati, riduci il numero di entità in aree critiche, abbassa la view-distance o sposta operazioni pesanti su thread secondari dove il plugin lo consente.
Un consiglio: pianifica un riavvio regolare del server anche in assenza di problemi evidenti: la memoria frammentata nel tempo è una causa silenziosa di micro-lag che il profiler fatica a isolare in sessioni brevi.
Documentazione ufficiale e punti di riferimento pratici
Le indicazioni di questa guida si basano su fonti verificabili, non su impressioni raccolte in community:
- L’annuncio ufficiale di Paper 1.21.3 confirma che timings è stato messo in modalità no-op e che spark è lo strumento di riferimento.
- La documentazione sul profiling di PaperMC descrive comandi, parametri e best practice per l’uso di spark.
- Le guide di spark sul viewer e sulla tick loop spiegano nel dettaglio come interpretare ogni metrica del report.
Chi gestisce un server senza tempo o competenze per questo lavoro di analisi può affidarsi a un supporto tecnico dedicato: è uno dei motivi per cui molti amministratori scelgono un hosting con assistenza diretta in italiano, invece di affrontare da soli ogni crash o regressione di Java.
Cosa conta davvero quando si passa da timings a spark
La parte che molti sottovalutano non è imparare i comandi di spark, ma cambiare l’abitudine mentale legata a timings. Timings invitava a guardare un report generico “per vedere come va il server”; spark funziona bene solo quando lo si usa con un’ipotesi precisa in testa, filtrando i tick giusti nel momento giusto. Chi continua ad avviare profilazioni lunghe e generiche ottiene report pieni di rumore e nessuna risposta chiara.
L’altro punto trascurato è che il flame graph, per quanto affascinante da guardare, raramente è il primo posto dove guardare. La vista sources, che raggruppa per plugin, risolve la maggior parte dei casi reali più rapidamente di un’analisi visiva degli hotspot. Il flame graph diventa utile solo dopo aver già isolato un sospetto.
Infine, la caccia ossessiva al TPS perfetto distrae da un problema più comune: pochi picchi isolati di MSPT alto, invisibili nella media, ma percepiti distintamente dai giocatori. Vale la pena dare priorità a questi spike prima di ottimizzare configurazioni che non stanno realmente causando disagio.
— Fabio Turi
Un’alternativa pratica: hosting ottimizzato con supporto dedicato
Analizzare un report di spark richiede tempo, e non tutti vogliono diventare esperti di profilazione solo per tenere il proprio server stabile. Offriamo server Minecraft con attivazione rapida, storage NVMe e protezione DDoS avanzata, pensati per ridurre le cause più comuni di lag prima che diventino un problema da diagnosticare.
Il pannello Pterodactyl semplifica la gestione di plugin, backup e configurazioni anche per chi non ha familiarità con la riga di comando, mentre il supporto tecnico via Discord, in italiano, può aiutare a interpretare un report spark o a capire se un calo di TPS dipende dal plugin o dall’hardware.
- Setup rapido del server, senza configurazioni manuali complesse.
- Protezione DDoS inclusa in ogni piano.
- Supporto Discord in italiano per assistenza su crash, aggiornamenti Java o configurazioni specifiche.
Chi vuole partire da un’infrastruttura già pensata per minimizzare questi problemi può consultare i piani hosting Minecraft di AtomSync, tra cui Coal Plan e Piano Gold, per attivare un server e verificare direttamente la differenza.
Fonti
Per approfondire oltre questa guida: la documentazione PaperMC sul profiling, le guide di spark sul viewer e la discussione ufficiale sulla sostituzione di timings su GitHub.
Per approfondire ottimizzazioni correlate, puoi consultare anche la nostra guida pratica contro il lag del server, la checklist per i cali di TPS e il confronto tra Paper e Spigot.
- Announcement - 1.21.3 | PaperMC
- Profiling | PaperMC Docs
- The Tick Loop | spark docs
- PaperMC issue: 1.21.3-12 fatal error on launching
Domande frequenti
Cos’è il timbreaggio in Minecraft e perché non funziona più?
Il “timbreaggio”, cioè l’uso dello strumento timings, serviva a misurare quanto tempo il server dedicava a ciascuna operazione. Dalla versione 1.21.3 è stato messo in modalità no-op da Paper, quindi non raccoglie più dati reali e va sostituito con spark.
Come si avvia una profilazione con spark su Paper?
Si usa il comando /spark profiler start --timeout 600, che registra l’attività del server per dieci minuti e genera un report leggibile tramite link, secondo la documentazione ufficiale di Paper. Per isolare picchi specifici si può aggiungere il filtro --only-ticks-over seguito dalla soglia in millisecondi.
Paper è meglio di Spigot per le prestazioni?
Paper include ottimizzazioni specifiche per il tick loop e supporta nativamente strumenti come spark, il che lo rende generalmente più adatto a chi vuole diagnosticare e migliorare le prestazioni in modo approfondito. La scelta finale dipende comunque dalla compatibilità dei plugin usati sul proprio server.
Perché il mio server crasha dopo aver aggiornato Paper o spark?
Un crash dopo l’aggiornamento è spesso legato alla versione di Java installata: alcune combinazioni con Java 23 hanno causato errori documentati in una issue ufficiale di PaperMC. Passare a Java 21 risolve la maggior parte di questi casi segnalati dalla community.
Come installo Paper rapidamente su un server?
Paper può essere scaricato dal sito ufficiale e installato manualmente, oppure attivato tramite un pannello di hosting che gestisce l’installazione in automatico. Su AtomSync, ad esempio, il server viene attivato rapidamente con Paper già pronto all’uso tramite il pannello di controllo.