In breve:
- Per eliminare il lag su un server Minecraft, è fondamentale profilare il sistema con Spark durante il carico reale, identificando le cause principali. Se TPS è stabile e MSPT basso, il problema è quasi certamente nel lato client o nella connessione del giocatore, altrimenti si procede con ottimizzazioni software e configurazioni. Solo dopo aver escluso cause software e di configurazione si valuta un upgrade hardware o di hosting.
Il primo passo per eliminare il lag su un server Minecraft è profilare il server con Spark durante il carico reale, poi agire sulle cause identificate. Tutto il resto, comprese le modifiche a paper.yml, le flag JVM e gli upgrade hardware, viene dopo: senza dati di profilazione stai solo indovinando.
Nel giro di qualche tempo puoi già raccogliere informazioni decisive. Ecco le azioni a impatto immediato:
- Riavvia il server se non lo fai da più di 24 ore: la JVM accumula garbage e le entità si moltiplicano.
- Riduci view-distance e simulation-distance a valori contenuti come misura temporanea.
- Disabilita i plugin non critici uno alla volta per isolare eventuali responsabili.
- Imposta un worldborder provvisorio per limitare la generazione di nuovi chunk.
- Esegui
/spark tpsper leggere TPS e MSPT attuali prima di qualsiasi altra modifica.
Se TPS è stabile e MSPT è sotto una soglia contenuta, il problema è quasi certamente lato client (FPS, connessione del giocatore) e non del server. Se invece TPS scende notevolmente o MSPT supera la soglia considerata per il carico, procedi con la profilazione completa descritta nella sezione successiva. Considera un upgrade dell’hosting solo dopo che il profiling esclude plugin e configurazione come cause principali.
Indice
- Come si diagnostica il lag con Spark e Timings?
- Quali sono le cause più comuni di lag e come si correggono?
- Come si configurano paper.yml, server.properties e le flag JVM?
- Quando il problema è l’hardware o il provider?
- Fix operativi immediati da applicare subito
- Come si monitora il server nel tempo?
- Quando conviene passare a un hosting migliore?
- Punti chiave
- Una parola dall’autore: gli errori più comuni che vedo negli admin
- Hosting Minecraft senza lag: cosa offre AtomSync
- Risorse utili e link autorevoli
- Domande frequenti
Come si diagnostica il lag con Spark e Timings?
La profilazione sotto carico è lo strumento più affidabile per capire cosa rallenta il server. Spark è leggero, compatibile con Paper, Purpur e Fabric, e produce flame graph a livello di metodo che mostrano esattamente quale codice consuma il main thread. A partire da versioni recenti di Paper, Spark è incluso nel software senza bisogno di installare plugin aggiuntivi.
Prerequisiti e tempistica ideale
Prima di avviare una sessione di profilazione, verifica questi punti:
- Accesso alla console del server o a RCON.
- Un numero adeguato di giocatori connessi o attività sufficiente (mob farm attive, redstone in funzione) per riprodurre il problema.
- Nessuna modifica recente non testata in staging.
Il momento migliore per profilare è durante il picco di giocatori, non a server vuoto. Eseguire Spark su un server vuoto non mostra i picchi causati da mob farm o redstone intensiva: gli spike che cerchi compaiono solo sotto carico reale.
Workflow passo per passo
- Controlla lo stato attuale:
/spark tpsmostra TPS e MSPT medi degli ultimi 5, 10 e 15 minuti. - Monitora il garbage collector per 2 minuti:
/spark gcmonitor. Se vedi pause frequenti oltre 200 ms, il problema è probabilmente heap o flag JVM. - Se il GC è pulito, avvia la profilazione CPU:
/spark profiler start --timeout per un periodo adeguato(5 minuti di cattura). - Durante la profilazione, riproduci il problema: fai muovere i giocatori, attiva le farm, genera chunk nuovi.
- Al termine, Spark genera un URL pubblico con il flame graph. Aprilo e cerca i frame più larghi nel main thread.
/spark tps
/spark gcmonitor
/spark profiler start --timeout per un periodo adeguato
/spark profiler stop
Per i timings di Paper/Spigot, il comando è /timings paste: genera un report su timings.shockbyte.com con i tempi medi per plugin e per fase del tick. Utile come secondo livello di analisi, ma meno preciso di Spark per isolare singoli spike.
Come leggere il flame graph
Nel flame graph, la larghezza di ogni frame è proporzionale al tempo CPU consumato. Cerca:
EntityAI.Goal.tickoPathfinderGoal: mob con pathfinding attivo in massa.- Chiamate sincrone a database (JDBC, SQLite sul main thread): plugin che bloccano il tick loop.
- Task schedulati in sync con il tick loop: plugin che eseguono operazioni pesanti ogni tick invece di delegarle a thread asincroni.
SparkAnalyzer legge il JSON del report e produce suggerimenti pratici: plugin coinvolti, chiavi di configurazione da modificare e impatto stimato. Vale la pena usarlo dopo aver aperto il flame graph manualmente, perché automatizza la lettura delle sezioni più profonde.
Un consiglio: Spark può segnalare singoli tick anomali che superano una soglia configurabile. Usalo per isolare spike non visibili nelle medie: un tick da 200 ms ogni 30 secondi non abbassa il TPS medio ma causa stuttering evidente ai giocatori.
Quali sono le cause più comuni di lag e come si correggono?
La mappa causa-azione che segue copre i problemi che compaiono più spesso nei flame graph. Seguila nell’ordine: prima conferma TPS/MSPT, poi profila, poi intervieni su una causa alla volta.
Entità e mob farm. Troppe entità nello stesso chunk saturano il pathfinding. Limita il numero massimo di mob per chunk in paper.yml (per-player-mob-spawns, max-entity-collisions) e valuta un plugin di stacking per le farm esistenti.
Redstone complessa. Circuiti a clock rapido o reti estese consumano tick in modo sproporzionato. Semplifica i circuiti o spostali in chunk meno frequentati. Paper riduce già alcune ottimizzazioni di redstone rispetto a vanilla, ma non elimina il problema alla radice.
Plugin sincroni. Molti problemi gravi non derivano dal GC ma da chiamate sincrone sul main thread: query a database, lettura di file, o task schedulati ogni tick. Verifica se il plugin ha una versione async o sostituiscilo.
View-distance e simulation-distance troppo alte. Ogni chunk caricato aggiunge entità da tickare e I/O da gestire. Valori sopra 10 per view-distance su server con più di 10 giocatori sono raramente giustificati.
I/O disco lento. I salvataggi dei chunk su disco meccanico creano colli di bottiglia visibili nel flame graph come RegionFile o ChunkSerializer. La soluzione è migrare su NVMe.
GC e heap mal configurati. Pause GC lunghe bloccano il main thread. Rivedi le flag JVM (vedi sezione successiva) e assicurati che -Xmx non superi la RAM disponibile meno circa 1 GB per il sistema operativo.
Rete e DDoS. Se TPS è stabile ma i giocatori segnalano rubber-banding o timeout, il problema è di rete. Controlla la saturazione della banda e verifica che il provider offra protezione DDoS attiva. Per approfondire i problemi di connessione, la guida su timeout di connessione al server copre i casi più frequenti.
Flusso di troubleshooting
- Conferma TPS/MSPT con
/spark tps. - Profila con Spark sotto carico reale.
- Identifica la causa dominante nel flame graph.
- Applica un solo intervento alla volta.
- Misura di nuovo con lo stesso test di carico.
- Conserva i profili prima e dopo per confronto.
Un consiglio: Dopo ogni modifica, aspetta almeno 15 minuti sotto carico prima di trarre conclusioni. Alcune ottimizzazioni mostrano effetti ritardati perché il GC deve completare un ciclo completo.
Come si configurano paper.yml, server.properties e le flag JVM?
Le impostazioni predefinite di Paper sono già migliori di quelle vanilla, ma con un server in produzione vale la pena affinarle. Ecco i parametri che incidono di più sulle prestazioni.
Impostazioni chiave in paper.yml e server.properties
# paper.yml (valori orientativi per server con 10-20 giocatori)
simulation-distance: 6
view-distance: 8
max-entity-collisions: 2
mob-spawn-range: 4
per-player-mob-spawns: true
keep-spawn-loaded: false
# server.properties
view-distance=8
simulation-distance=6
network-compression-threshold=256
Ridurre simulation-distance a valori contenuti ha spesso più impatto di qualsiasi altra singola modifica, limitando il numero di entità che il server deve tickare per ogni giocatore. Impostare max-entity-collisions bassi aiuta a eliminare il calcolo delle collisioni a cascata nelle farm affollate.
Flag JVM: le Aikar’s flags come punto di partenza
Le Aikar’s flags sono una configurazione JVM raccomandata per server Minecraft e possono ridurre le pause del garbage collector su heap grandi.
java -Xms4G -Xmx4G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
-XX:+DisableExplicitGC -XX:+AlwaysPreTouch \
-XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 \
-XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 \
-XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 \
-XX:InitiatingHeapOccupancyPercent=15 \
-XX:G1MixedGCLiveThresholdPercent=90 \
-XX:G1RSetUpdatingPauseTimePercent=5 \
-XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem \
-XX:MaxTenuringThreshold=1 -jar server.jar nogui
La regola pratica per
-Xmx: prendi la RAM fisica totale del server e sottrai una quantità per il sistema operativo. Non impostare un heap più grande della RAM disponibile: il sistema inizierà a usare swap e le prestazioni crolleranno.
Un consiglio: Testa sempre le flag JVM in un ambiente di staging prima di applicarle in produzione. Rimuovere una flag senza capirne l’effetto può peggiorare le pause GC invece di ridurle. Usa /spark gcmonitor per confrontare il comportamento prima e dopo.
Per una guida completa all’installazione e alla configurazione iniziale, consulta la guida alla creazione di un server Minecraft su AtomSync.
Quando il problema è l’hardware o il provider?
Ottimizzare la configurazione ha un limite. Se dopo il profiling e i fix software il lag persiste, il collo di bottiglia è probabilmente infrastrutturale.
Sizing orientativo RAM e giocatori
| Scenario | RAM consigliata | Note |
|---|---|---|
| 2–5 giocatori, vanilla | 2 GB | Sufficiente con flag JVM corrette |
| 5–10 giocatori, plugin leggeri | 4 GB | Margine per GC e chunk cache |
| 10–20 giocatori, plugin medi | 6–8 GB | Necessario per evitare pressione GC |
| 20+ giocatori o modpack pesanti | 8 GB | Dipende dal modpack; profila sempre |
La CPU conta più dei core totali: Minecraft è single-thread per il main tick loop, quindi una CPU con alta frequenza su singolo core batte un server con molti core lenti. Cerca processori con frequenze boost sopra 4 GHz.
Disco. I chunk vengono letti e scritti continuamente. Un disco meccanico crea colli di bottiglia visibili nel flame graph come operazioni RegionFile lente. NVMe riduce questi tempi di un ordine di grandezza rispetto a HDD e migliora anche i tempi di avvio e di backup.
Rete. Per server pubblici, la protezione DDoS non è opzionale: un attacco volumetrico satura la banda e causa lag o disconnessioni per tutti i giocatori, indipendentemente da quanto sia ottimizzato il software. Controlla che il provider offra filtri attivi, non solo mitigazione reattiva.
Un consiglio: Quando il profiling mostra che il main thread è idle ma i giocatori segnalano lag, il problema è quasi sempre di rete o di I/O disco. Controlla le metriche di rete del server (pacchetti persi, latenza verso i giocatori) prima di aumentare la RAM.
Fix operativi immediati da applicare subito
Questi interventi non richiedono riavvio completo o modifiche permanenti alla configurazione. Applicali nell’ordine indicato e misura l’effetto dopo ognuno.
- Pianifica un riavvio pulito. Avvisa i giocatori con almeno 5 minuti di anticipo, esegui
/save-alle poi riavvia. Un server che gira da più di 48 ore accumula entità orfane e garbage non raccolta. - Imposta un worldborder temporaneo.
/worldborder set 10000blocca la generazione di nuovi chunk e riduce il carico di I/O. Aumenta il valore gradualmente se necessario. - Disabilita i plugin non critici. Sposta i jar dei plugin sospetti fuori dalla cartella
plugins/e riavvia. Testa un plugin alla volta. - Riduci view-distance e simulation-distance. Modifica
server.propertiesepaper.yml, poi esegui/reload confirmo riavvia. - Limita le mob farm attive. Usa
/kill @e[type=!player]con cautela e solo dopo un backup: rimuove tutte le entità non-giocatore nel mondo. Alternativa più sicura: usa un plugin di gestione entità che permette di impostare limiti per chunk. - Esegui
/save-alle flush prima del backup. Assicura che i dati su disco siano coerenti prima di qualsiasi operazione di manutenzione.
Attenzione ai comandi di pulizia massiva: /kill @e[type=!player] è irreversibile e può eliminare oggetti importanti o animali domestici dei giocatori. Esegui sempre un backup completo prima. Worldedit con selezioni grandi può causare spike di I/O che peggiorano temporaneamente il lag invece di ridurlo.
Per ogni azione, comunica ai giocatori cosa sta succedendo: un messaggio in chat con /say Manutenzione in corso, possibile lag per 5 minuti riduce le segnalazioni e mantiene la fiducia nella community.
Come si monitora il server nel tempo?
Il monitoraggio continuo trasforma il troubleshooting da reattivo a preventivo. Con dati storici, un picco di lag diventa un’anomalia identificabile invece di un mistero.
Routine settimanale consigliata
- Esegui
/spark tpsogni giorno alla stessa ora e annota TPS e MSPT in un foglio condiviso. - Avvia una sessione di profilazione Spark una volta a settimana durante il picco di giocatori e salva l’URL del report.
- Esporta i timings di Paper prima e dopo ogni aggiornamento di plugin.
- Controlla i log GC (
/spark gcmonitor) dopo ogni modifica alle flag JVM.
Cosa registrare
- MSPT e TPS medi e massimi per sessione.
- URL dei report Spark: conservali in ordine cronologico per confrontare trend.
- Numero di entità per mondo:
/sparkmostra statistiche aggregate; alcuni plugin espongono comandi dedicati. - Utilizzo CPU e RAM del processo Java: disponibile nel pannello di controllo del server o tramite
top/htopsulla macchina host. - Metriche disco: IOPS e latenza di lettura/scrittura, visibili nei log del sistema operativo o nel pannello del provider.
Soglie di allerta
Configura avvisi (o controlla manualmente) quando:
- TPS scende sotto 18 per più di 5 minuti consecutivi.
- MSPT supera 45 ms in media su una sessione.
- Una singola regione del mondo ospita più di 500 entità.
- Le pause GC superano 500 ms in un singolo evento.
Per mantenere il server sempre attivo e strutturare una routine di backup solida, la guida su server Minecraft sempre aperto copre i processi di manutenzione continua in dettaglio.
Quando conviene passare a un hosting migliore?
Prima di migrare, conferma che il problema sia davvero infrastrutturale. Una migrazione fatta senza dati risolve il lag solo per caso.
Migra solo dopo aver escluso plugin, configurazione e JVM come cause. Se il flame graph mostra il main thread idle ma il server è lento, o se le metriche disco mostrano latenze alte indipendentemente dal carico di gioco, allora il problema è il provider.
Checklist decisionale pre-migrazione
- Il profiling Spark mostra risorse hardware sature (CPU al 100%, I/O disco costantemente alto)?
- Hai già ridotto view-distance, ottimizzato i plugin e rivisto le flag JVM senza miglioramenti stabili?
- Il provider attuale offre protezione DDoS attiva, NVMe e CPU con alta frequenza single-thread?
- Hai un backup recente e un piano di downtime comunicato ai giocatori?
- Il supporto tecnico del provider risponde in tempi utili e nella tua lingua?
Criteri per scegliere l’hosting
| Criterio | Perché conta | Cosa cercare |
|---|---|---|
| CPU single-thread | Il main tick loop è single-thread | Frequenza boost sopra 4 GHz |
| Storage NVMe | Chunk I/O è continuo | NVMe PCIe, non SATA SSD |
| Protezione DDoS | Attacchi volumetrici causano lag di rete | Filtri attivi, non solo mitigazione |
| Supporto tecnico | Problemi complessi richiedono risposta rapida | Supporto in italiano, canale dedicato |
| Pannello di controllo | Gestione file, plugin, backup | Pterodactyl o equivalente |
| Scaling istantaneo | Il carico cresce con la community | Upgrade/downgrade senza migrazione |
AtomSync offre server Minecraft con attivazione in meno di 60 secondi, storage NVMe, protezione DDoS fino a 1 Tbps e pannello Pterodactyl personalizzato. Il supporto tecnico è in italiano via Discord nei giorni lavorativi, il che fa differenza quando devi risolvere un problema durante un evento della community. I piani sono mensili senza vincoli contrattuali, con possibilità di upgrade o downgrade istantaneo.
Punti chiave
Profilare con Spark sotto carico reale è il punto di partenza obbligatorio: senza dati, ogni modifica è un tentativo alla cieca.
| Punto | Dettagli |
|---|---|
| Profila prima di tutto | Usa Spark sotto carico reale per identificare la causa dominante prima di modificare qualsiasi configurazione. |
| Fix software prima dell’hardware | Risolvi plugin sincroni, entità eccessive e flag JVM errate prima di considerare un upgrade dell’hosting. |
| Configurazione JVM | Usa le Aikar’s flags e imposta -Xmx a RAM totale meno circa 1 GB per il sistema operativo. |
| Monitoraggio continuo | Registra TPS, MSPT e report Spark settimanalmente per rilevare trend prima che diventino problemi. |
| AtomSync come opzione infrastrutturale | Se il profiling esclude software e config, AtomSync offre NVMe, DDoS fino a 1 Tbps e supporto in italiano senza vincoli contrattuali. |
Una parola dall’autore: gli errori più comuni che vedo negli admin
L’errore più frequente è modificare paper.yml o le flag JVM a caso, senza aver mai aperto un flame graph. Si aggiunge una flag, si riavvia, si aspetta qualche minuto e si trae una conclusione basata sulla sensazione. Il problema è che il lag su Minecraft ha cause molto diverse: un plugin che fa query sincrone sul main thread risponde a soluzioni completamente diverse rispetto a un heap sottodimensionato. Trattarle allo stesso modo significa perdere ore.
Il secondo errore è usare comandi di pulizia massiva senza backup. Ho visto admin eseguire /kill @e[type=!player] su server con centinaia di giocatori, eliminando oggetti e animali domestici irreversibilmente, per poi scoprire che il lag era causato da un plugin di economia con query bloccanti. Il backup non è una formalità: è il prerequisito per qualsiasi intervento invasivo.
Il terzo, e forse il più sottile, è ignorare i log GC. Le pause del garbage collector non abbassano il TPS medio in modo vistoso, ma causano stuttering periodico che i giocatori percepiscono come lag intermittente. /spark gcmonitor richiede due minuti e mostra immediatamente se il problema è lì.
La cultura di manutenzione che funziona è semplice: profila regolarmente, conserva i report, modifica una cosa alla volta e misura sempre prima e dopo. Non è glamour, ma è l’unico approccio che rende il troubleshooting ripetibile invece di casuale.
Hosting Minecraft senza lag: cosa offre AtomSync
Se dopo il profiling e i fix software il collo di bottiglia è chiaramente l’infrastruttura, cambiare provider è la mossa giusta. AtomSync è pensato per chi gestisce server Minecraft in Italia e vuole CPU ad alta frequenza single-thread, storage NVMe e protezione DDoS attiva fino a 1 Tbps senza dover negoziare ogni dettaglio tecnico con il supporto.
L’attivazione richiede meno di 60 secondi, il pannello Pterodactyl personalizzato gestisce file, plugin, backup automatici e configurazioni da un’unica interfaccia, e il supporto in italiano via Discord risponde nei giorni lavorativi con competenza tecnica diretta. Nessun vincolo contrattuale: puoi scalare le risorse o cambiare piano in qualsiasi momento.
Verifica i piani di hosting Minecraft disponibili su AtomSync e attiva il tuo server oggi.
Risorse utili e link autorevoli
Per approfondire la diagnosi e la configurazione del server, questi riferimenti sono i più affidabili:
- Documentazione ufficiale di Spark: comandi, opzioni di profilazione, configurazione delle soglie di allerta per tick anomali.
- SparkAnalyzer: guida alla lettura del flame graph: come interpretare i report Spark e trasformare i dati in azioni concrete.
- Spark su Paper e Docker: guida pratica: workflow per server in container, inclusi i comandi
docker execper profilazione remota. - Debug del lag con Spark: workflow completo: procedura passo per passo da TPS a flame graph, con esempi di cause comuni.
- Configurazione JVM e sizing su VPS: regole pratiche per
-Xmx, Aikar’s flags e dimensionamento della RAM. - Issue tracker Mojang (MC-275131): segnalazioni di bug noti su versioni specifiche di Minecraft, utile per verificare se un aggiornamento è all’origine del problema.
- Repository ufficiale Spark su GitHub: codice sorgente, changelog e istruzioni di installazione per tutte le piattaforme supportate.
Un consiglio: Quando apri una issue al manutentore di un plugin, allega sempre l’URL del report Spark generato durante il problema. Il flame graph mostra esattamente quale metodo del plugin consuma CPU e rende la segnalazione molto più utile di una semplice descrizione testuale.
Domande frequenti
Come si risolve il lag su un server Minecraft?
Avvia una profilazione con Spark durante il carico reale (/spark profiler start --timeout per un periodo adeguato), identifica la causa dominante nel flame graph e intervieni su quella specifica. Le cause più comuni sono plugin sincroni, troppe entità e flag JVM errate.
1 GB di RAM è sufficiente per un server Minecraft?
No, per quasi tutti gli scenari pratici. Con 1 GB di RAM il garbage collector entra in pressione costante già con pochi giocatori. Il minimo consigliato è 2 GB per 2–5 giocatori vanilla, con flag JVM corrette.
Cosa causa il lag su un server Minecraft?
Le cause principali sono: plugin che eseguono operazioni bloccanti sul main thread, troppe entità in pochi chunk, heap JVM sottodimensionato, disco lento (HDD invece di NVMe), view-distance troppo alta e, per server pubblici, attacchi DDoS che saturano la banda.
La versione 1.21 di Minecraft causa lag?
Alcune release della serie 1.21 contengono bug noti che causano cali di TPS o freeze: l’issue tracker di Mojang riporta segnalazioni specifiche come MC-275131. Se il lag è comparso dopo un aggiornamento, verifica se esiste una patch o considera un rollback temporaneo alla versione precedente.
Quanto tempo richiedono i fix e quando conviene scalare l’hosting?
I fix software (ridurre view-distance, disabilitare plugin, correggere flag JVM) richiedono tempo relativamente breve e mostrano effetti immediati. Un upgrade dell’hosting richiede più tempo per la migrazione, ma è giustificato solo dopo che il profiling esclude cause software come origine del problema.