Palworld-server crasht steeds: zo stel je de diagnose en los je het op

Kort samengevat

Palworld heeft al lang een geheugenlek in zijn dedicated serverbuild. Het RAM-gebruik loopt gestaag op zolang de server draait, ongeveer evenredig met hoeveel spelers online zijn en hoeveel Pals er in de wereld bestaan, en het wordt nooit vrijgegeven. Uiteindelijk put het proces het RAM uit dat het kreeg en doodt het besturingssysteem het. Van buitenaf lijkt dat op een willekeurige crash, en daarom geven zoveel mensen eerst hun host de schuld.

Serverbeheerders melden het patroon consistent: een wereld met vier spelers en ongeveer 80 Pals groeit doorgaans van ongeveer 3 GB naar meer dan 8 GB binnen vier uur, en een drukke communityserver met 16 spelers kan in een half uur 12 GB bereiken. Die getallen variëren met je wereld, maar het patroon niet. Als je crashes op een ruw schema komen en niet willekeurig, dan is dat het geheugenlek.

De twee storingen die niet op een crash lijken

Een crash is het makkelijke geval: het proces sterft, en alles wat ernaar kijkt merkt dat. De twee storingen die de meeste verwarde supporttickets veroorzaken, laten het proces draaien en elke gezondheidscontrole slagen. We hebben beide gediagnosticeerd aan de hand van 22 uur metingen per minuut op de 16GB-server van een klant, en ze zien er zo uit:

Geen van beide is het geheugenlek. De storing waarbij de wereld uitlaadt, gebeurde drie keer in twee uur op een server die minder dan 2.3GB gebruikt, dus het is niet het lek en niet de RAM-limiet. Wat ze duur maakt, is dat de gebruikelijke health check (draait het spelproces?) in beide toestanden slaagt, dus niets herstart de server en die kan urenlang dood blijven liggen terwijl jij slaapt.

Controleer eerst of het aan het geheugen ligt voordat je iets wijzigt

Open de resourcegrafiek in je dashboard en volg het RAM-gebruik tijdens een sessie. Het geheugenlek heeft een kenmerk dat je niet snel verwart:

• Het RAM-gebruik stijgt vanaf het moment dat de server start bijna in een rechte lijn en daalt nooit meer nadat spelers vertrekken.
• Het crasht wanneer die regel het plafond van je abonnement bereikt, niet bij een bepaald moment in het spel.
• Er is geen bruikbare crashmelding. Het proces verdwijnt gewoon, omdat het besturingssysteem het heeft gestopt in plaats van dat het spel besloot af te sluiten.
• Een herstart van de server lost het volledig op, voor nog een paar uur.

Als je server daarentegen elke keer op precies hetzelfde moment sterft, of binnen seconden na de start faalt, ga dan naar de laatste sectie. Dat zijn andere problemen met andere oplossingen.

Oplossing 1: herstart volgens schema

Dit is het onopvallende antwoord, en het is ook het effectieve. Omdat het lek lineair is en een herstart alles wist, zet een geplande herstart de klok terug voordat het plafond ooit wordt bereikt. Ervaren beheerders herstarten doorgaans elke drie tot zes uur op een drukke publieke server, en één of twee keer per dag op een kleine privéserver.

Een Palworld-herstart duurt ongeveer een minuut en de wereld wordt eerst opgeslagen, dus de kosten voor spelers zijn klein. Kies een moment waarop je groep meestal offline is, kondig het aan op Discord, en het probleem houdt op een probleem te zijn. Op Flux kun je met één klik vanaf het dashboard herstarten, en omdat een herstart ook een openstaande gameupdate oppikt, is het tegelijk je patchroutine.

Een valkuil om van te weten als je zelf host of een andere provider gebruikt: het geplande herstartscript in de standaard Palworld serverimage vraagt de server eerst op te slaan en weigert af te sluiten als die save mislukt. Op een server die lekt, bevroren is of geen wereld heeft, wat precies het enige type server is waarvoor een nachtelijke herstart bestaat, is de save juist wat mislukt. Dus de herstart doet stilzwijgend niets op precies de nachten dat hij nodig was, en de logs tonen hem toch als uitgevoerd. Controleer of je server daadwerkelijk is herstart in plaats van dat aan te nemen.

Oplossing 2: schakel Pal-invasies uit

Raids spawnen golven vijandige Pals die de server lang na afloop van de raid in het geheugen houdt. Ze uitzetten is het dichtste wat Palworld heeft bij een door de community geaccepteerde workaround voor het lek, en beheerders melden consequent dat het RAM-gebruik daarna ongeveer half zo snel stijgt.

Zet in PalWorldSettings.ini bEnableInvaderEnemy=False en herstart. Je verliest basisaanvallen, die sommige groepen zullen missen en veel groepen niet, en in ruil verdubbel je de tijd tussen herstarts ruwweg. Bewerk het bestand via de configuratie-editor in het dashboard; je hoeft geen terminal te openen.

Fix 3: beperk wat blijft groeien

Het geheugenlek groeit mee met hoeveel wereld er in het geheugen moet worden gehouden, dus het beperken van wat je spelers kunnen bouwen vertraagt het. Twee instellingen doen het meeste werk:

Een gilde dat 50 werkende Pals in elk van meerdere bases heeft geparkeerd, houdt een grote hoeveelheid persistente simulatie in RAM vast, en elke Pal daarvan draagt bij aan het lek. Het begrenzen van het aantal werkers is ook niet alleen een geheugenfix: het is de grootste hefboom op de serverbelasting van de CPU in Palworld, dus het verbetert meestal tegelijk de lag.

Oplossing 4: zorg voor extra marge

Geen van bovenstaande stopt het lek, ze vertragen het alleen. De resterende variabele is hoeveel ruimte de server heeft voordat hij het plafond raakt, en dat is de grootte van je abonnement. Als je 16 spelers op 8 GB draait, vraag je het lek je binnen een uur te doden, hoe goed je de wereld ook configureert.

Die niveaus gaan al uit van een lekkende server, niet van een theoretische inactieve. Als je crasht op het niveau dat bij je aantal spelers past, is de gebruikelijke oorzaak een sterk uitgebouwde wereld, en de twee instellingen hierboven helpen je meer dan het volgende abonnement. Zit je één niveau onder je aantal spelers, ga dan omhoog. RAM schalen op Flux raakt je wereldsave niet aan.

Hoe houd je een Palworld server 24/7 online

Alles hierboven vertraagt de storingen. Niets daarvan zorgt ervoor dat een server die al is uitgevallen weer opkomt, en dat is het verschil tussen een server die meestal online is en een server die altijd online is. Iets moet opmerken en ingrijpen terwijl jij slaapt.

Dat is het gat dat onze Palworld-serverimage dichtmaakt, en daarom bouwen we er een eigen in plaats van de standaardimage te gebruiken. Elke minuut controleert hij de server, vanuit de container, op de dingen die een speler echt zou merken: of de netwerksocket leegloopt, of de admin-API antwoordt, of de wereld geladen is en draait, en of het savebestand nog op schijf staat. Als het antwoord nee is, herstart hij de server. Je hoeft niets in te schakelen en er is geen instelling om te vinden.

De terughoudendheid is even belangrijk als de trigger, want een monitor die gezonde servers herstart is erger dan geen monitor:

• Het heeft drie keer achter elkaar hetzelfde oordeel nodig, elke minuut één keer, voordat het actie onderneemt. Eén slecht meetmoment is geen storing.
• Het handelt nooit op een server die het nog niet heeft zien werken, en nooit in de eerste minuten na de start. Een grote wereld laden kost tijd, en een herstartlus helpt een server niet die kapot is opgestart.
• Het kondigt de herstart aan in het spel en telt 60 seconden af, met herinneringen bij 30 en 10 seconden, en neemt daarna één laatste meting. Een server die zich tijdens het aftellen herstelt, wordt met rust gelaten en het aftellen wordt hardop afgeblazen.
• Het slaat nooit op. In elke staat die dit ver genoeg bereikt is de wereld in het geheugen al weg of bevroren, en een kapotte server vragen om op te slaan riskeert die leegte over je laatste goede save te schrijven. Wat een herstart je kost, zijn de minuten sinds de laatste autosave, en die waren al verloren op het moment van de storing.

De nachtelijke herstart op deze image is ook opgelost. Hij waarschuwt je spelers, slaat alleen op als de wereld nog geladen is en daadwerkelijk draait, vraagt de server om af te sluiten en stopt daarna met vragen. Na een coulanceperiode beëindigt hij het proces, en een nieuwe server is enkele seconden later weer online. Hij slaat nooit stilzwijgend over.

Eén ding dat het waard is om zelf te doen: stel een admin-wachtwoord in op het tabblad Server Settings. De socket- en savebestandscontroles werken sowieso, maar de controles die een uitgeladen wereld opvangen praten met de admin API van de server, en een server zonder ingesteld wachtwoord weigert die aanroepen. We behandelen een geweigerde aanroep bewust nooit als een dode server, want dat zou gezonde werelden elke paar minuten herstarten. Het effect van het leeg laten is dus stillere bescherming, niet luidere bescherming.

Wanneer het niet het geheugenlek is

Het crasht enkele seconden na het starten, direct na een game-update

Pocketpair brengt client- en serverupdates samen uit, en een server die nog op de vorige build draait, weigert verbindingen of valt om zodra een geüpdatete client joint. Update de server zodra de clientpatch uitkomt, in plaats van te wachten op een melding van je spelers. Op Flux haalt een herstart de huidige image op, dus dat is één klik.

Het crasht elke keer op hetzelfde punt

Een crash die precies reproduceert, bijvoorbeeld telkens wanneer een specifieke speler inlogt of wanneer de wereld een bepaald gebied bereikt, wijst naar een beschadigde save en niet naar geheugen. Herstel de meest recente backup die is gemaakt voordat het gedrag begon. Houd backups op schema om precies deze reden: een save die je niet kunt terugdraaien is een save die je kunt kwijtraken.

Hij start helemaal niet

Als de server nooit is opgekomen, is dit een configuratie- of poortprobleem en geen crash. Controleer of UDP 8211 de poort is die je spelers gebruiken om te verbinden en of PalWorldSettings.ini geldig is, want één verkeerd gevormde regel zorgt dat het bestand niet wordt ingelezen. De installatiegids loopt beide stappen door.

Een checklist die je kunt doorwerken

1. Bepaal welke storing je hebt. Een rechte stijging in RAM tot het plafond is het lek. Online maar niet joinbaar is een stilstand. Joinbaar maar zonder wereld is een uitgeladen wereld. Ze vragen om verschillende oplossingen.
2. Zet bEnableInvaderEnemy=False in PalWorldSettings.ini en herstart.
3. Begrens BaseCampWorkerMaxNum tot iets redelijks voor je groep, en begrens BaseCampMaxNum tot je aantal spelers.
4. Plan op een drukke server elke drie tot zes uur een herstart, of op een privéserver dagelijks.
5. Controleer of het RAM van je abonnement overeenkomt met je aantal spelers, en ga naar een hoger niveau als dat niet zo is.
6. Houd automatische backups aan, zodat een beschadigde save een ongemak is en niet het einde van de wereld.
7. Stel een admin-wachtwoord in, zodat de controles die een niet-geladen wereld detecteren je server kunnen bereiken.
8. Zorg dat iets de server herstart wanneer die stopt met reageren, niet alleen wanneer die crasht. Op Flux is dat ingebouwd in de serverimage.

Werk het in die volgorde af en het grootste deel van de Palworld-crashmeldingen houdt op. Wat overblijft is een beperking van de game-engine die niemand voor je kan oplossen, dus de vraag is niet meer hoe je elke storing voorkomt, maar hoe snel de server zich ervan herstelt.