Palworld Performance Optimization
Real fixes for lag, memory growth, and server FPS issues - with tradeoffs explained.
The Memory Leak
Palworld dedicated servers have a known memory leak that has been present since launch. The 1.0 release did not fix it. Server RAM usage climbs steadily over time, eventually causing crashes when the server hits its memory limit.
Symptoms: rubber-banding (you move forward and snap back), delayed Pal actions, lag spikes during busy moments, and eventually a crash. The longer the server runs, the worse it gets.
The most effective fix is a regular restart. The leak resets completely on one.
Use the "Automatic Daily Restart" card on the Admin tab. It offers three intervals - every 6, 12 or 24 hours - and it only fires when NOBODY is connected: the host agent checks every five minutes and waits if there are players. Nobody is ever kicked, but a permanently busy server may never reach its window, in which case restart it by hand at a quiet hour.
Settings That Reduce Memory Growth
Invading Enemies off - the setting's own description in the panel warns that community sources report memory growth over long uptimes when it is on. The trade-off: you lose the raid-defence gameplay, which some players enjoy.
Pal Spawn Rate - lowering it reduces the number of wild Pals. Fewer entities means less memory and CPU. The trade-off: the world feels less populated and capture takes longer.
Workers per Base (default 15, panel maximum 100) - fewer Pals simulated at each base. The trade-off: bases work more slowly.
Base Camps per Guild (default 4) - fewer bases means less simulation. Note this is the per-guild limit; Total Base Camp Maximum (default 128) is the separate world-wide one.
Dropped-Item Maximum (default 3000) - fewer tracked item entities in the world. The trade-off: items may disappear sooner, which frustrates players.
All of these need a server restart, like every Palworld setting.
Server FPS Stuck at 10-15
If your server FPS is stuck at 10-15, this is often a capped tick rate, not a hardware problem. Palworld servers cap the tick rate by default.
To raise it, add the following to Engine.ini in Pal/Saved/Config/WindowsServer/ using the Files tab, on two lines:
[/Script/OnlineSubsystemUtils.IpNetDriver] then NetServerMaxTickRate=60
Restart the server afterwards. The platform only ever appends a [Core.Log] section to this file and otherwise leaves it alone, so a section you add survives restarts.
The trade-off: higher tick rates use more CPU and bandwidth. If your server is already CPU-bound, this makes lag worse rather than better. Change it, watch the Resource Usage card, and put it back if CPU climbs.
Distinguishing Lag Types
Server-side lag: Everyone on the server experiences it. Symptoms include delayed Pal actions, rubber-banding, and slow crafting. Usually caused by the memory leak, too many entities, or CPU saturation. Fix with restarts and setting adjustments.
Client FPS: Only one player experiences it. Their game runs at low FPS. This is a client hardware issue, not a server issue. Suggest they lower their graphics settings.
Network latency: One player has high ping. They see delayed interactions or teleporting. This is a network routing issue between the player and the server. Check with WinMTR (see the Platform Guides section).
Packet loss: Players' actions don't register or they get disconnected. Usually a network issue. Check the server's network connection and the player's ISP.
Hardware Requirements
On GameGrid, the hardware is ours. Your plan decides your allocation, and the Resource Usage card on the server Overview tab shows what the server process is actually using.
CPU: Palworld is CPU-heavy, especially with high Pal counts and many bases. Each instance here is pinned to its own core.
RAM: the memory leak means you need headroom rather than a tight fit. If memory is regularly near the top of your allocation, move to a larger plan.
Storage: GameGrid servers use SSDs. Palworld's own documentation warns that slow storage can corrupt saves.
Network: nothing for you to configure. The game port, Steam query port and the two internal ones are allocated from your 28000-39000 block and firewalled by the platform - see the Ports guide.
Adding more RAM does not by itself fix lag. If the cause is CPU saturation or the memory leak, more RAM only delays the crash.