Laatst gecontroleerd: 25 september 2026 met Palworld v1.0.5 en de Pocketpair-serverdocumentatie op stand v1.0.4. Metingen uit de Early Access-periode zijn niet 1:1 over te nemen: 1.0 (10-07-2026) bracht optimalisaties voor dedicated servers bij veel spelers, en daarna volgden 1.0.2 tot 1.0.5.
De officiële vereisten goed lezen
Pocketpair noemt voor een dedicated Palworld-server 16 GB RAM, minimaal vier aanbevolen CPU-kernen en een snelle SSD. Deze gegevens zijn een aanbeveling van de fabrikant, maar geen tabel met spelers per GB. Ze zeggen niet dat een bepaalde hoeveelheid RAM automatisch een bepaald aantal spelers garandeert.
De actuele bron van de fabrikant vind je in de officiële Palworld-serververeisten. Pocketpair waarschuwt daar bovendien dat trage opslag savegegevens kan beschadigen. Plan RAM, CPU en opslag daarom samen.
Wat we op onze servers hebben gemeten
Op onze draaiende klantservers met maximaal 4 gelijktijdig actieve spelers bleef de RAM-behoefte bij een dagelijkse herstart onder de 6 GB, zonder geheugenuitval (14-daagse meting, oktober 2026). De pieken lagen tussen 3,4 en 5,3 GB, onafhankelijk van het geboekte pakket. De CPU was daarentegen de bottleneck: met elke extra speler steeg de CPU-belasting duidelijk, en een server met 4 spelers draaide tijdelijk op de CPU-limiet. Voor grotere groepen hebben we geen eigen meetwaarden.
Als er meer spelers tegelijk moeten spelen, kies dan een pakket met een hogere CPU-limiet of boek een extra kern: +1 vCPU voor € 2,99 per maand, maximaal 2 extra kernen.
| Component | Officiële indeling | Gevolg voor je planning |
|---|---|---|
| RAM | 16 GB bedrijfsvereiste | Opgave van de fabrikant; op onze klantservers met maximaal 4 spelers bleef de behoefte onder de 6 GB |
| CPU | minimaal vier kernen aanbevolen | bepaalt hoeveel spelers soepel kunnen spelen; meer spelers vragen om een hogere CPU-limiet |
| Opslag | snelle SSD aanbevolen | savedata en I/O niet verwaarlozen |
Waarom het aantal spelers alleen geen RAM-formule oplevert
Twee werelden met hetzelfde aantal verbonden spelers kunnen een totaal verschillende belasting veroorzaken. Een nieuwe wereld waarin een groep samen reist, gedraagt zich anders dan een al lang draaiende wereld met verspreide bases, veel worker-pals, grote gebouwencomplexen en een verhoogde spawnrate. Ook gelijktijdig actieve wereldgebieden, automatisering en gewijzigde serverinstellingen beïnvloeden het werk dat de dedicated server moet verrichten.
Het maximale aantal deelnemers is daarom een toegangslimiet en geen directe maatstaf voor resources. Een algemene uitspraak zoals een vaste hoeveelheid RAM per speler negeert de wereldstatus, de CPU-belasting en de geheugentoegang. Gebruik het aantal spelers als contextwaarde, maar beslis pas over een upgrade samen met reproduceerbare meetgegevens.
Een bruikbare meetbaseline opbouwen
Bepaal eerst een typisch belastingsvenster. Dat kan een communityavond zijn, een bossevent of een fase waarin meerdere groepen tegelijk aan verschillende bases werken. Leg tijdens dit venster minimaal de gelijktijdig verbonden spelers, het RAM- en CPU-gebruik, de server-FPS, de frame-time, het aantal bases en opvallende logmeldingen vast. Server-FPS en frame-time lees je uit via de REST-API van de server (RESTAPIEnabled=True in de PalWorldSettings.ini, daarna GET /v1/api/metrics): die levert serverfps, serverframetime, currentplayernum en uptime. Noteer bovendien welke spawnrates en prestatiegerelateerde instellingen actief waren.
Een enkele piek is geen bewijs. Herhaal de observatie op vergelijkbare tijdstippen en documenteer of de verzadiging permanent of slechts kortstondig optreedt. Leg ook de patchstand vast: sinds versie 1.0 controleert Palworld de versie strikt, en een niet-bijgewerkte server weigert clients met een nieuwere stand als incompatibel. Een spelupdate of een nieuwe wereldfase kan de belasting bovendien veranderen zonder dat het aantal spelers stijgt. Deze baseline maakt latere vergelijkingen van voor en na mogelijk.
RAM-knelpunten van andere oorzaken onderscheiden
Controleer voordat je RAM uitbreidt de looptijd van het proces: de Palworld-server neemt met elk bedrijfsuur meer geheugen in beslag, ook na versie 1.0. Stijgt het RAM-verbruik bij een gelijk aantal spelers gestaag en zakt het na een herstart weer naar de beginwaarde, dan is een geplande herstart (met een save vooraf, op een rustig tijdstip van de dag) de passende maatregel, geen upgrade.
Een RAM-upgrade is aannemelijk als het proces herhaaldelijk tegen de beschikbare grens aan zit, er OOM-gebeurtenissen optreden of de server onder vergelijkbare belasting met extra geheugen reproduceerbaar stabieler draait. Een hoge bezette waarde bewijst op zichzelf nog geen tekort: besturingssysteem en applicatie kunnen vrij geheugen als cache gebruiken. Beslissend zijn verzadiging, foutbeeld en herhaalbaar gedrag.
Controleer parallel de CPU. Op onze klantservers was die vaker de bottleneck dan het RAM. Zijn afzonderlijke kernen permanent volledig belast terwijl er nog RAM-reserve is, dan lost meer werkgeheugen het eigenlijke knelpunt niet op. Dalende server-FPS of stijgende frame-time kunnen zowel met CPU-werk als met complexe wereldstatussen samenhangen. Wijzig daarom niet tegelijk RAM, CPU-toewijzing en spawnrate; anders is de werkzame maatregel niet meer vast te stellen.
Opslag en savebeveiliging meenemen
Pocketpair beveelt snelle SSD-opslag aan en wijst op een risico voor savedata bij zwakke opslag; van Docker Desktop raadt de vereistenpagina uitdrukkelijk af, omdat het het risico op beschadigde savegames verhoogt. bIsUseBackupSaveData (standaard aan) maakt doorlopende back-ups in de savegamemap en kost daarvoor extra schijfbelasting. Let daarom op I/O-fouten, ongewoon lange saveprocessen en vrije opslagruimte. Voor elke test met mods, grotere configuratiewijzigingen of serverupdates maak je een controleerbare back-up. De gids Palworld-wereld back-uppen en herstellen beschrijft het passende verloop.
Een back-up is pas betrouwbaar als je weet waar hij staat, welke wereldstand erin zit en hoe het herstel werkt. Voer riskante belastingtests niet uit op de enige kopie van je productieve wereld. Zo voorkom je dat een performanceonderzoek zelf tot gegevensverlies leidt.
Wijzigingen gecontroleerd testen
Maak vóór de wijziging een kort testplan: welk symptoom moet verdwijnen, welke meetwaarde moet verbeteren en in welk vergelijkbaar belastingsvenster wordt getest? Maak daarna een back-up van de wereld en wijzig precies één variabele. Bij een vermoed RAM-knelpunt is dat de geheugencapaciteit; bij een CPU-knelpunt een hogere CPU-limiet, bijvoorbeeld via een extra kern, of een prestatiegerelateerde instelling.
Herstart de server na de wijziging netjes en herhaal het gedocumenteerde belastingvenster. Vergelijk niet alleen een piekwaarde, maar stabiliteit, OOM-gebeurtenissen, RAM, CPU, server-FPS en frame-time. Blijft het probleem gelijk, draai de wijziging dan terug of onderzoek het volgende beargumenteerde knelpunt. Verbetert het gedrag reproduceerbaar, documenteer dan de nieuwe baseline en de aanleiding.
Voor configuratiewijzigingen gebruik je de gids Palworld-serverinstellingen configureren. De officiële argumentenlijst van Pocketpair legt onder andere de luisterpoort, het maximale aantal deelnemers en de actuele aanwijzingen over performanceargumenten uit. Neem startparameters niet blind over uit oude communityberichten, omdat de fabrikant voor versie 1.0 en nieuwer bij bepaalde eerdere multithreadingparameters uitdrukkelijk wijst op mogelijk beter gedrag zonder deze parameters.
Capaciteitscheck na updates en wereldgroei
Sinds v1.0.3 beperkt bAllowEnemyCampSpawnNearBaseCamp=False raid-spawns in de buurt van spelersbases, sinds v1.0.4 begrenst MaxBuildingLimitNum de bouwonderdelen per speler; beide zijn prestatierelevante schakelaars. Serverclustering, in juni 2026 aangekondigd, is tot en met v1.0.5 niet geleverd, belastingverdeling over meerdere instanties blijft dus geen optie.
Een eenmaal gemeten waarde blijft niet automatisch voor altijd juist. Herhaal de check na grotere Palworld-updates, sterke groei van bases, gewijzigde spawnrates en een duidelijk grotere community. Vergelijk altijd met de laatste stabiele baseline. Zo zie je of de resourcebehoefte daadwerkelijk is veranderd of dat er onafhankelijk van RAM en CPU een nieuwe fout is ontstaan.
Gebruik voor elke beslissing dezelfde volgorde: officiële minimumbasis controleren, wereld back-uppen, meetwaarden vastleggen, knelpunt classificeren, precies één wijziging testen en het resultaat documenteren. Zo voorkom je zowel te kleine instances als dure upgrades die een CPU-, opslag- of configuratiefout niet oplossen.
FAQ
Zijn 6 GB RAM genoeg voor een Palworld-server?
Op onze draaiende klantservers met maximaal 4 gelijktijdig actieve spelers bleef de RAM-behoefte bij een dagelijkse herstart onder de 6 GB, zonder geheugenuitval (14-daagse meting, oktober 2026). Pocketpair noemt 16 GB RAM als bedrijfsvereiste. Voor grotere groepen hebben we geen eigen meetwaarden.
Hoeveel RAM heb ik per speler nodig?
Daarvoor bestaat geen betrouwbare vaste formule. Aantal spelers, bases, worker-pals, gebouwen, spawnrate, instellingen en gelijktijdig actieve wereldgebieden werken samen op de belasting. Op onze servers steeg met elke speler vooral de CPU-belasting, nauwelijks het RAM. Beslis over extra capaciteit op basis van herhaalbare meetwaarden.
Wanneer heb ik meer RAM of een hogere CPU-limiet nodig?
Meer RAM helpt als RAM-verzadiging of OOM-gebeurtenissen onder vergelijkbare belasting reproduceerbaar optreden. Zit de CPU permanent op de limiet terwijl er RAM vrij is, dan heb je een hogere CPU-limiet nodig, bijvoorbeeld via een extra kern.
Helpt meer RAM tegen elke vorm van lag?
Nee. CPU-verzadiging, trage opslag, wereldcomplexiteit, netwerkproblemen en ongeschikte instellingen kunnen vergelijkbare symptomen veroorzaken. Controleer RAM, CPU, server-FPS, frame-time, logs en opslag samen voordat je een oorzaak vaststelt.
Wat moet ik voor een performancetest veiligstellen?
Maak een controleerbare wereldback-up en documenteer de patchstand en de instellingen. Wijzig daarna slechts één variabele en herhaal een vergelijkbaar belastingsvenster. Zo blijft het resultaat navolgbaar en de productieve wereld herstelbaar.