Il server Palworld continua a crashare: come diagnosticarlo e risolverlo

In breve

Palworld ha da tempo un memory leak nella sua build di server dedicato. L'uso della RAM cresce costantemente per tutto il tempo in cui il server è attivo, più o meno in proporzione a quanti giocatori sono online e a quanti Pal esistono nel mondo, e non viene mai rilasciato. Alla fine il processo esaurisce la RAM che gli è stata assegnata e il sistema operativo lo termina. Dall'esterno sembra un crash casuale, ed è per questo che molte persone incolpano prima il proprio host.

Chi gestisce server riporta costantemente lo stesso andamento: un mondo da quattro giocatori con circa 80 Pal di solito passa da circa 3 GB a più di 8 GB in quattro ore, e un server community affollato da 16 giocatori può raggiungere 12 GB in mezz'ora. Questi numeri variano con il tuo mondo, ma il pattern no. Se i tuoi crash arrivano secondo una pianificazione approssimativa invece che a caso, quello è il leak.

I due guasti che non sembrano un crash

Un crash è il caso facile: il processo muore e chiunque lo monitori se ne accorge. I due guasti che generano più ticket di assistenza confusi lasciano il processo in vita e ogni controllo di integrità superato. Li abbiamo diagnosticati entrambi partendo da 22 ore di campioni al minuto di un server da 16GB di un cliente, e appaiono così:

Nessuno dei due è la memory leak. Il guasto di unload del mondo si è verificato tre volte in due ore su un server che usava meno di 2.3GB, quindi non è la leak né il limite di RAM. Ciò che li rende costosi è che il classico controllo di salute, cioè se il processo di gioco è in esecuzione, passa in entrambi gli stati: nulla riavvia il server, che quindi può restare fermo per ore mentre dormi.

Verifica che sia la memoria prima di cambiare qualsiasi cosa

Apri il grafico delle risorse nel tuo dashboard e osserva la RAM durante una sessione. Il memory leak ha una firma difficile da confondere:

• La RAM sale in linea quasi retta dal momento in cui il server parte e non torna mai indietro dopo che i giocatori se ne vanno.
• Il crash avviene quando quella riga raggiunge il limite del tuo piano, non in un particolare evento di gioco.
• Non esiste un messaggio di crash utile. Il processo semplicemente scompare, perché il sistema operativo lo ha terminato invece che il gioco decidesse di chiudersi.
• Riavviare il server lo risolve del tutto, per altre poche ore.

Se invece il tuo server muore ogni volta esattamente nello stesso momento, o fallisce pochi secondi dopo l'avvio, vai all'ultima sezione. Sono problemi diversi con soluzioni diverse.

Correzione 1: riavvia con una pianificazione

È la risposta poco appariscente, ed è anche quella efficace. Poiché il leak è lineare e un riavvio lo azzera del tutto, un riavvio programmato resetta il conteggio prima che si raggiunga il limite. Gli operatori esperti di solito riavviano ogni tre-sei ore su un server pubblico molto frequentato, e una o due volte al giorno su uno piccolo e privato.

Un riavvio di Palworld dura circa un minuto e il mondo viene salvato prima, quindi il costo per i giocatori è basso. Scegli un orario in cui il tuo gruppo di solito è offline, annuncialo su Discord, e il problema smette di essere un problema. Su Flux puoi riavviare dal dashboard con un clic e, poiché un riavvio applica anche eventuali aggiornamenti del gioco in sospeso, fa anche da routine di patch.

Una trappola da conoscere se gestisci il server da solo o usi un altro provider: lo script di riavvio programmato nell'immagine standard del server Palworld chiede al server di salvare prima, e si rifiuta di spegnersi se il salvataggio fallisce. Su un server che perde memoria, è bloccato o senza mondo, cioè l'unico tipo di server per cui esiste un riavvio notturno, proprio il salvataggio è ciò che fallisce. Quindi il riavvio non fa nulla in silenzio proprio nelle notti in cui serviva, e i log lo mostrano come eseguito. Controlla che il tuo server sia davvero stato riavviato invece di darlo per scontato.

Correzione 2: disattiva gli invasori Pal

I raid generano ondate di Pal ostili che il server tiene in memoria molto dopo la fine del raid. Disattivarli è la cosa più vicina a una soluzione condivisa dalla community per il leak, e chi gestisce server riferisce costantemente che la RAM sale a circa la metà della velocità precedente dopo.

In PalWorldSettings.ini imposta bEnableInvaderEnemy=False e riavvia. Perdi i raid alle basi, di cui alcuni gruppi sentiranno la mancanza e molti no, e in cambio raddoppi circa il tempo tra un riavvio e l'altro. Modifica il file dall'editor di configurazione del dashboard: non serve aprire un terminale.

Correzione 3: limita le cose che crescono

La perdita di memoria cresce con quanto mondo c'è da tenere in memoria, quindi limitare quanto i giocatori possono costruire ne rallenta la crescita. Due impostazioni fanno la maggior parte del lavoro:

Una gilda che ha parcheggiato 50 Pal al lavoro in ciascuna di diverse basi sta tenendo in RAM una grande quantità di simulazione persistente, e ognuno di quei Pal contribuisce alla leak. Limitare il numero di lavoratori non è solo un rimedio alla memoria: è anche la leva più importante sul carico della CPU del server in Palworld, quindi di solito migliora anche la lag nello stesso momento.

Soluzione 4: dagli più margine

Niente di quanto sopra ferma la leak, la rallenta soltanto. La variabile restante è quanto spazio ha il server prima di raggiungere il limite, e quella è la dimensione del tuo piano. Se gestisci 16 giocatori su 8 GB, stai chiedendo alla leak di ucciderti in meno di un'ora, per quanto bene configuri il mondo.

Quei livelli presuppongono già un server che perde memoria, non uno inattivo in teoria. Se vai in crash con il livello che corrisponde al tuo numero di giocatori, la causa più comune è un mondo molto costruito, e le due impostazioni sopra ti aiuteranno più del piano superiore. Se sei un livello sotto il numero dei tuoi giocatori, passa a quello superiore. Ridimensionare la RAM su Flux non tocca il salvataggio del mondo.

Come tenere un server Palworld online 24/7

Tutto quanto sopra rallenta i guasti. Nulla di questo fa tornare online un server già guasto, ed è questa la differenza tra un server online la maggior parte del tempo e uno online sempre. Qualcosa deve accorgersi del problema e agire mentre dormi.

È la lacuna che colmano le nostre immagini del server Palworld, ed è per questo che ne costruiamo una nostra invece di usare quella standard. Controlla il server ogni minuto, dall'interno del container, sulle cose che un giocatore noterebbe davvero: se il socket di rete sta drenando, se l'API admin risponde, se il mondo è caricato e in esecuzione e se il file di salvataggio è ancora su disco. Se la risposta è no, riavvia il server. Non c'è nulla da attivare né impostazioni da trovare.

La moderazione conta quanto il trigger, perché un monitor che riavvia server sani è peggio di nessun monitor:

• Richiede lo stesso verdetto tre volte di seguito, a un minuto di distanza, prima di agire: un singolo campione sbagliato non è un guasto.
• Non agisce mai su un server che non ha ancora visto funzionare, né durante i primi minuti dopo l'avvio. Caricare un mondo grande richiede tempo, e un ciclo di riavvii non aiuta un server partito guasto.
• Annuncia il riavvio in gioco e fa un conto alla rovescia di 60 secondi, con promemoria a 30 e 10 secondi, poi prende un ultimo campione. Un server che si è ripreso durante il conto alla rovescia viene lasciato in pace e il conto alla rovescia viene annullato ad alta voce.
• Non salva mai. In ogni stato che arriva fin qui il mondo in memoria è già perso o bloccato, e chiedere a un server guasto di salvare rischia di scrivere quel vuoto sopra il tuo ultimo buon salvataggio. Ciò che un riavvio ti costa sono i minuti dall'ultimo salvataggio automatico, che erano già andati persi quando si è verificato il guasto.

Anche il riavvio notturno su questa immagine è stato corretto. Avvisa i giocatori, salva solo se il mondo è ancora caricato e sta davvero girando, chiede al server di spegnersi, e poi smette di chiederlo: dopo un periodo di tolleranza termina il processo, e un nuovo server è online pochi secondi dopo. Non salta mai in silenzio.

Una cosa che vale la pena fare da solo: imposta una password admin nella scheda Impostazioni server. I controlli su socket e file di salvataggio funzionano comunque, ma quelli che rilevano un mondo non caricato parlano con l'API admin del server, e un server senza password rifiuta queste chiamate. Non consideriamo mai una chiamata rifiutata come un server morto, perché farlo riavvierebbe mondi sani ogni pochi minuti. Quindi lasciarla vuota significa una protezione più silenziosa, non più rumorosa.

Quando non è il memory leak

Si blocca pochi secondi dopo l'avvio, subito dopo un aggiornamento del gioco

Pocketpair rilascia insieme gli aggiornamenti di client e server, e un server ancora sulla build precedente rifiuterà le connessioni o cadrà non appena entra un client aggiornato. Aggiorna il server non appena arriva la patch del client invece di aspettare una segnalazione dai tuoi giocatori. Su Flux un riavvio scarica l'immagine corrente, quindi basta un clic.

Si blocca sempre nello stesso punto

Un crash che si riproduce esattamente, per esempio ogni volta che un giocatore specifico accede o ogni volta che il mondo raggiunge una certa zona, punta a un salvataggio corrotto e non alla memoria. Ripristina il backup più recente fatto prima che il comportamento iniziasse. Mantieni i backup su una pianificazione proprio per questo motivo: un salvataggio che non puoi riportare indietro è un salvataggio che puoi perdere.

Non parte mai

Se il server non è mai partito, si tratta di un problema di configurazione o di porta e non di un crash. Verifica che UDP 8211 sia la porta a cui compongono i tuoi giocatori e che PalWorldSettings.ini sia valido, perché una sola riga malformata impedisce la lettura del file. La guida alla configurazione spiega entrambe le cose.

Una checklist da seguire

1. Capisci quale guasto hai. Una salita dritta della RAM fino al limite è il leak. Online ma non accessibile è un blocco. Accessibile ma senza mondo è un mondo scaricato. Richiedono risposte diverse.
2. Imposta bEnableInvaderEnemy=False in PalWorldSettings.ini e riavvia.
3. Imposta BaseCampWorkerMaxNum su un valore ragionevole per il tuo gruppo e limita BaseCampMaxNum al numero di giocatori.
4. Pianifica un riavvio ogni tre-sei ore su un server molto frequentato, o ogni giorno su uno privato.
5. Verifica che la RAM del piano corrisponda al numero di giocatori e passa a un livello superiore se non corrisponde.
6. Tieni attivi i backup automatici, così un salvataggio corrotto è un fastidio e non la fine del mondo.
7. Imposta una password admin, così i controlli che rilevano un mondo non caricato possono raggiungere il tuo server.
8. Assicurati che qualcosa riavvii il server quando smette di rispondere, non solo quando muore. Su Flux è integrato nell'immagine del server.

Segui questi passaggi in quest'ordine e la maggior parte delle segnalazioni di crash di Palworld si ferma. Ciò che resta è un limite del motore di gioco che nessuno può correggere al posto tuo, quindi la domanda smette di essere come evitare ogni guasto e diventa quanto in fretta il server torna online dopo uno.