CPU e RAM: cosa rende veloce un server di gioco?
La RAM decide quanto un server riesce a tenere in memoria, la CPU decide quanto in fretta riesce a pensare. Perché la velocità su singolo core conta più di tutto e quando i core in più aiutano.
6 min di lettura · Aggiornata il 21 ott 2026 · Di GuavaHost Team
La RAM decide quanto il tuo server riesce a tenere in memoria, e la CPU decide quanto in fretta riesce a pensare. La maggior parte del lag che la gente addossa alla memoria è in realtà un problema di CPU, quindi questa guida spiega la differenza, perché la velocità su singolo core conta più del numero di core e come capire di quale delle due sei a corto.
Due lavori diversi
- La RAM è capacità. Tiene il mondo, i giocatori e le mod. Se finisce, il server scatta mentre libera memoria, oppure va in crash.
- La CPU è velocità. Fa il lavoro vero: muovere i mob, far girare l'intelligenza artificiale, la fisica, la redstone, le stazioni di crafting e ogni plugin. Se non basta, il server resta indietro e tutti lo sentono nello stesso momento come ritardo ed effetto elastico.
Aggiungere RAM a un server a corto di CPU non serve a niente, e una CPU veloce non può salvare un server che ha esaurito la memoria. Ti serve abbastanza di entrambe, ma si rompono in modi diversi.
Il budget del tick
Un server di gioco gira in un ciclo. Ogni passaggio nel ciclo si chiama tick, e in ogni tick il server aggiorna tutto quello che c'è nel mondo. Il gioco si aspetta un certo numero di tick al secondo, e questo dà a ogni tick un budget di tempo:
| Gioco | Frequenza prevista | Tempo per tick |
|---|---|---|
| Minecraft Java | 20 tick al secondo | 50 ms |
| Terraria | 60 aggiornamenti al secondo | circa 16,7 ms |
| Counter-Strike 2 | 64 tick al secondo | circa 15,6 ms |
Se un tick dura più del suo budget, il server non riesce a stare al passo. In Minecraft si vede come TPS (tick al secondo) che scendono sotto 20 e MSPT (millisecondi per tick) che salgono oltre 50. La nostra guida su come leggere TPS e MSPT mostra come misurarlo.
La RAM non compare da nessuna parte in quel budget. Chiudere ogni tick in tempo è puramente una questione di quanto lavoro c'è e di quanto in fretta la CPU lo smaltisce.
Perché la velocità su singolo core conta più di tutto
La maggior parte dei server di gioco esegue la simulazione principale su un solo thread principale. Un thread è una singola linea di lavoro che un core della CPU può eseguire, e un mondo di gioco è difficile da spezzare su più thread, perché ogni passo dipende da quello precedente: un mob non può muoversi finché il server non sa dove è finito il blocco su cui sta camminando.
Minecraft, Rust, ARK, Valheim, Project Zomboid e Terraria funzionano tutti così. Quindi la velocità di un singolo core fissa il tetto per tutto il server. Una CPU con 16 core più lenti può far girare un mondo Minecraft peggio di una con 8 core più rapidi, perché il mondo arriverà a usarne sempre uno solo per il suo lavoro principale.
La velocità su singolo core dipende da due cose:
- La frequenza di clock, misurata in GHz: quanti cicli esegue il core ogni secondo.
- Il lavoro per ciclo, che migliora a ogni generazione di CPU. Una CPU più recente alla stessa frequenza in GHz è spesso sensibilmente più rapida di una vecchia.
Aiuta anche una cache CPU ampia (un piccolo serbatoio di memoria molto rapida sul chip stesso), perché i server di gioco saltano continuamente tra moltissimi frammenti di dati.
Quando più core aiutano davvero
I core in più non sono inutili. Si prendono tutto quello che non è il tick principale:
- Lavoro in sottofondo. Salvare il mondo, caricare e generare chunk (software server come Paper spostano parte di questo fuori dal thread principale), comprimere i dati di rete ed eseguire le attività dei plugin scritte per girare in sottofondo.
- La garbage collection di Java. Minecraft Java ripulisce la memoria non usata con diversi thread, quindi i core liberi tengono corte quelle pulizie.
- Più di un processo. Un server Don't Starve Together esegue la superficie e le caverne come due processi separati, e ogni mappa di un cluster ARK è un server a sé. Ognuno può usare il proprio core.
- Aggiornamenti e backup. Scaricare un aggiornamento del gioco o comprimere un backup avviene accanto al gioco, non dentro un tick.
Alcuni motori più recenti, tra cui l'Unreal Engine dietro ARK e Palworld, distribuiscono più lavoro su thread aggiuntivi. Anche lì, però, il thread di gioco principale resta quello che dà il ritmo.
Di quale delle due sei a corto?
| Cosa vedi | Causa probabile |
|---|---|
| Grafico della memoria inchiodato al limite | RAM |
| Errori di memoria esaurita, o crash durante il caricamento | RAM |
| La memoria ha margine, ma i TPS calano e l'MSPT sale | CPU |
| Lag solo vicino a una fattoria gigantesca, a una mega base o a tante creature | CPU |
| Il lag si accumula nel corso delle ore e un riavvio lo risolve | Spesso accumulo di memoria, a volte accumulo di entità |
| Un solo giocatore ha lag | Nessuna delle due: è il suo ping |
Un dettaglio che vale la pena conoscere: la card Usage nel tuo pannello di controllo GuavaHost (nelle schede Overview e Console) mostra la CPU rispetto al tuo piano. Quando il tuo piano ha un limite di CPU, il valore è una quota di tutti i core del piano, indicata per esempio con "of 2 cores", quindi 100 per cento significa che sono occupati tutti. Il thread principale di un gioco può usare un solo core, quindi su un piano a 2 core un server che resta intorno al 50 per cento mentre va a scatti può avere il thread principale al massimo pur avendo capacità avanzata. Quando il tuo piano non ha un limite di CPU, il valore è una percentuale di un core, quindi un server intorno al 100 per cento mentre va a scatti racconta la stessa storia. È il segnale classico di un collo di bottiglia sul thread principale.
Come risolvere il lag causato dalla CPU
Qui più RAM non aiuta. Quello che aiuta è dare al thread principale meno da fare a ogni tick:
- Abbassa prima la distanza di simulazione, poi la distanza di visualizzazione. Vedi distanza di visualizzazione e di simulazione.
- Metti un tetto alle fattorie di mob e ripulisci gli oggetti a terra e le entità in eccesso.
- Pre-genera il mondo così il terreno nuovo non viene creato mentre la gente gioca.
- Trova mod o plugin pesanti con un profiler. Su Minecraft il plugin gratuito Spark dice esattamente cosa si mangia ogni tick.
- Programma un riavvio giornaliero per azzerare l'accumulo di entità e di memoria.
La nostra lista di controllo per il lag le affronta una per una nell'ordine giusto.
Come funziona tutto questo su GuavaHost
Ogni server GuavaHost gira su processori AMD Ryzen e Intel, scelti per le prestazioni elevate su singolo thread perché è proprio su quelle che si appoggiano i server di gioco, insieme a storage NVMe SSD. La parte che scegli tu è la RAM, dimensionata sul tuo gioco e sul tuo gruppo, e puoi cambiarla in qualsiasi momento con Manage plan (gestisci il piano) nel pannello di controllo, con fatturazione proporzionale. Se il tuo server ha memoria avanzata ma è comunque in difficoltà, si tratta di un lavoro di messa a punto, e la nostra guida alla RAM spiega perché comprare più memoria non lo risolverà.
Hai ancora problemi? Entra nel nostro Discord su discord.gg/GuavaHost e il team ti darà una mano.
- cpu
- ram
- performance
- single-thread
- cores
- tick rate
- lag
Ti serve ancora aiuto? Il nostro team è online 24 ore su 24, 7 giorni su 7, per rispondere alle tue domande.