Pianifica la RAM di Palworld in base ai requisiti del produttore e a misurazioni del carico ripetibili. Contano saturazione della memoria, FPS del server, frame time e mondo attivo; il numero di giocatori da solo non fornisce una formula affidabile per la RAM. Un upgrade serve solo quando la memoria limita davvero il funzionamento.
Ultima verifica: 25 settembre 2026 con Palworld v1.0.5 e la documentazione server di Pocketpair alla versione v1.0.4.
Leggere correttamente i requisiti ufficiali
Per un server Palworld dedicato Pocketpair indica 16 GB di RAM, almeno quattro core CPU consigliati e un SSD veloce. Secondo il produttore 8 GB possono avviare il server, ma aumentano la probabilità di crash per memoria insufficiente. Per setup più grandi Pocketpair indica più di 32 GB. Queste indicazioni sono una base tecnica solida, ma non una tabella giocatori per GB. Non dicono che una certa quantità di RAM garantisca automaticamente un certo numero di giocatori.
La fonte attuale del produttore è nei requisiti ufficiali del server Palworld. Pocketpair avverte inoltre che uno storage lento può danneggiare i dati di salvataggio. Pianifica quindi RAM, CPU e storage insieme e non considerare 8 GB una raccomandazione di stabilità.
| Componente | Classificazione ufficiale | Conseguenza per la tua pianificazione |
|---|---|---|
| RAM | 16 GB come requisito operativo | Punto di partenza per un server regolare |
| 8 GB di RAM | avviabile, maggiore rischio di OOM/crash | da considerare solo come funzionamento di prova limitato |
| setup grandi | più di 32 GB consigliati | conferma il fabbisogno con misurazioni |
| CPU | almeno quattro core consigliati | controlla il carico della CPU separatamente dalla RAM |
| Storage | SSD veloce consigliato | non trascurare dati di salvataggio e I/O |
Perché il numero di giocatori da solo non dà una formula per la RAM
Due mondi con lo stesso numero di giocatori connessi possono generare carichi molto diversi. Un mondo nuovo in cui un gruppo viaggia insieme si comporta in modo diverso da un mondo attivo da tempo con basi distribuite, molti Pal lavoratori, grandi complessi edilizi, tasso di spawn aumentato e più mod. Anche aree del mondo attive contemporaneamente, automazioni e impostazioni del server modificate influenzano il lavoro che il server dedicato deve svolgere.
Il numero massimo di partecipanti è quindi un limite di accesso e non un misuratore diretto delle risorse. Un'affermazione generica come una quantità fissa di RAM per giocatore ignora stato del mondo, carico della CPU, accessi alla memoria e comportamento delle mod. Usa il numero di giocatori come valore di contesto, ma decidi un upgrade solo insieme a dati di misurazione riproducibili.
Costruire una baseline di misurazione utilizzabile
Definisci prima una finestra di carico tipica. Può essere una serata della community, un evento boss o una fase in cui più gruppi lavorano contemporaneamente su basi diverse. Durante questa finestra rileva almeno i giocatori connessi contemporaneamente, l'utilizzo di RAM e CPU, gli FPS del server, il frame time, il numero di basi e gli eventi di log rilevanti. FPS del server e frame time si leggono tramite l'API REST del server (RESTAPIEnabled=True in PalWorldSettings.ini, poi GET /v1/api/metrics): restituisce serverfps, serverframetime, currentplayernum e uptime. Annota inoltre quali mod, tassi di spawn e impostazioni rilevanti per le prestazioni erano attivi.
Un singolo picco non basta come prova. Ripeti l'osservazione in momenti comparabili e documenta se la saturazione è costante o solo breve. Registra anche la versione della patch: dalla versione 1.0 Palworld controlla rigorosamente la versione, e un server non aggiornato respinge come incompatibili i client con una versione più recente. Un aggiornamento del gioco, di una mod o una nuova fase del mondo possono inoltre cambiare il carico senza che aumenti il numero di giocatori. Questa baseline rende possibili i confronti prima/dopo.
Separare i colli di bottiglia della RAM dalle altre cause
Prima di aumentare la RAM, confronta consumo di memoria e tempo di esecuzione del processo con carico simile. Se il consumo cresce nel tempo a parità di attività e cala dopo un riavvio, un riavvio pianificato può limitare temporaneamente il sintomo. Salva prima lo stato del mondo. Indaga comunque causa e aggiornamenti disponibili: questo andamento non dimostra che un upgrade sia sempre superfluo.
Un upgrade della RAM è plausibile quando il processo raggiunge ripetutamente il limite disponibile, si verificano eventi OOM o il server, con carico comparabile, funziona in modo riproducibile più stabile con memoria aggiuntiva. Un valore elevato di memoria occupata non dimostra da solo una carenza: sistema operativo e applicazione possono usare la memoria libera come cache. Contano saturazione, quadro degli errori e comportamento ripetibile.
Controlla in parallelo la CPU. Se singoli core sono costantemente al limite mentre c'è ancora RAM disponibile, più memoria non risolve il vero collo di bottiglia. FPS del server in calo o frame time in aumento possono dipendere sia dal lavoro della CPU sia da stati del mondo complessi. Non modificare quindi contemporaneamente RAM, assegnazione della CPU, mod e tasso di spawn; altrimenti non si potrà più stabilire quale misura abbia funzionato.
Considerare storage e sicurezza dei salvataggi
Pocketpair raccomanda storage SSD veloce e segnala un rischio per i dati di salvataggio con storage poco performante; la pagina dei requisiti sconsiglia espressamente Docker Desktop perché aumenta il rischio di salvataggi danneggiati. bIsUseBackupSaveData (attivo di default) crea backup a rotazione nella cartella dei salvataggi e comporta un carico aggiuntivo sul disco. Osserva quindi errori di I/O, operazioni di salvataggio insolitamente lunghe e spazio libero. Prima di ogni test con mod, modifiche di configurazione importanti o aggiornamenti del server, crea un backup verificabile. La guida Salvare e ripristinare il mondo di Palworld descrive la procedura adatta.
Un backup è affidabile solo quando sai dove si trova, quale stato del mondo contiene e come funziona il ripristino. Non eseguire test di carico rischiosi sull'unica copia del tuo mondo di produzione. In questo modo eviti che un'indagine sulle prestazioni causi essa stessa una perdita di dati.
Testare le modifiche in modo controllato
Prima della modifica prepara un breve piano di verifica: quale sintomo deve sparire, quale valore misurato deve migliorare e in quale finestra di carico comparabile si controlla? Poi salva il mondo e cambia esattamente una variabile. Con un sospetto collo di bottiglia della RAM è la capacità di memoria; con un collo di bottiglia della CPU può essere la dimensione dell'istanza o un'impostazione rilevante per le prestazioni.
Dopo la modifica riavvia il server in modo pulito e ripeti la finestra di carico documentata. Confronta non solo un valore di picco, ma stabilità, eventi OOM, RAM, CPU, FPS del server e frame time. Se il problema resta uguale, annulla la modifica o indaga il successivo collo di bottiglia motivato. Se il comportamento migliora in modo riproducibile, documenta la nuova baseline e la causa scatenante.
Per le modifiche di configurazione usa la guida Configurare le impostazioni del server Palworld. L'elenco ufficiale degli argomenti di Pocketpair spiega, tra l'altro, la porta di ascolto, il numero massimo di partecipanti e le indicazioni attuali sugli argomenti per le prestazioni. Non copiare alla cieca i parametri di avvio da vecchi post della community, perché per la versione 1.0 e successive il produttore segnala espressamente, per alcuni precedenti parametri di multithreading, un possibile comportamento migliore senza di essi.
Controllo della capacità dopo aggiornamenti e crescita del mondo
Dalla v1.0.3 bAllowEnemyCampSpawnNearBaseCamp=False limita gli spawn di raid vicino alle basi dei giocatori, dalla v1.0.4 MaxBuildingLimitNum limita gli elementi costruttivi per giocatore; entrambi sono interruttori rilevanti per le prestazioni. Il clustering dei server, annunciato a giugno 2026, non è stato rilasciato fino alla v1.0.5, quindi la distribuzione del carico su più istanze non è ancora un'opzione.
Una dimensione misurata una volta non resta automaticamente corretta per sempre. Ripeti il controllo dopo grandi aggiornamenti di Palworld, mod nuove o aggiornate, forte crescita delle basi, tassi di spawn modificati e una community sensibilmente più grande. Confronta sempre con l'ultima baseline stabile. In questo modo capisci se è davvero cambiato il fabbisogno di risorse o se è comparso un nuovo errore indipendente da RAM e CPU.
Per ogni decisione segui lo stesso ordine: controlla la base minima ufficiale, salva il mondo, rileva i valori di misurazione, classifica il collo di bottiglia, testa esattamente una modifica e documenta il risultato. Così eviti sia istanze troppo piccole sia upgrade costosi che non risolvono un errore di CPU, storage, mod o configurazione.
FAQ
8 GB di RAM bastano per un server Palworld?
Pocketpair descrive 8 GB come sufficienti per l'avvio, ma avverte di una maggiore probabilità di crash OOM. Per il funzionamento il produttore indica 16 GB. Considera quindi 8 GB come stato di prova limitato, non come raccomandazione generale di stabilità.
Quanta RAM mi serve per giocatore?
Non esiste una formula fissa affidabile. Numero di giocatori, basi, Pal lavoratori, edifici, mod, tasso di spawn, impostazioni e aree del mondo attive contemporaneamente influiscono insieme sul carico. Parti dal requisito operativo ufficiale e decidi la capacità aggiuntiva in base a valori misurati ripetibili.
Quando dovrei passare a più di 16 GB?
Quando la saturazione della RAM o gli eventi OOM sono riproducibili con carico comparabile e un test controllato con più memoria migliora la stabilità. Per setup più grandi Pocketpair indica più di 32 GB, senza ricavarne un'assegnazione fissa per giocatore.
Più RAM aiuta contro ogni tipo di lag?
No. Saturazione della CPU, storage lento, mod, complessità del mondo, problemi di rete e impostazioni inadatte possono causare sintomi simili. Controlla insieme RAM, CPU, FPS del server, frame time, log e storage prima di stabilire una causa.
Cosa devo salvare prima di un test delle prestazioni?
Crea un backup del mondo verificabile e documenta versione della patch, mod e impostazioni. Poi modifica una sola variabile e ripeti una finestra di carico comparabile. In questo modo il risultato resta tracciabile e il mondo di produzione ripristinabile.
Usare un riavvio come confronto
Annota RAM e FPS del server prima di un riavvio pianificato e salvato correttamente, e dopo il rientro dello stesso gruppo. Attendi che le stesse basi siano di nuovo attive; un server vuoto subito dopo l'avvio non è un punto di misurazione comparabile. Se l'utilizzo resta basso con un'attività comparabile, esamina l'andamento nel corso del tempo di esecuzione. Se la memoria si esaurisce subito di nuovo, controlla carico del mondo e mod. Un riavvio può ridurre temporaneamente un sintomo, ma non dimostra né un errore di memoria né un piano troppo piccolo. Decidi in base a più finestre di funzionamento comparabili.