2026-07-30 · 3 min read
Why Your Palworld Server Gets Laggy (and How to Fix It)
You set up a Palworld server, everything was fine for the first few days, and now it's stuttering even when nobody's playing. You didn't change anything. The server didn't break. Here's what's actually happening — and it's been affecting everyone since the 1.0 update.
The memory leak: plain English

The server allocates RAM for each Pal, NPC, and world object it loads. Those allocations don't always get released cleanly. Over 24–48 hours of continuous uptime, RAM fills up steadily.
When available RAM runs out, the server starts paginating to disk, dropping simulation ticks, and disconnecting players. It looks like lag. It is lag — caused by an out-of-memory condition that builds gradually rather than crashing the process outright.
This is a confirmed bug in Pocketpair's dedicated server software. It affects everyone, not just players on underpowered hardware.
Why the 1.0 update made it worse
The 1.0 release added Sakurajima, a new island that roughly doubles the world area. More world area means more Pals roaming at any given time, which means more allocations per hour.
A server that used to degrade after 36 hours might now hit the same state in 18–20. Pocketpair has acknowledged the leak and hasn't patched it as of this writing.
For a full breakdown of what else changed in 1.0, see Palworld 1.0 Is Live — What Changed for Your Server.
Three settings that help immediately
Open PalWorldSettings.ini and set the following under [/Script/Pal.PalGameWorldSettings]:
NpcSpawnIntervalTimeInSeconds=600
PalSpawnNumRate=0.5
ServerPlayerMaxNum=8
NpcSpawnIntervalTimeInSeconds=600 — Default is 300. Doubling the respawn interval keeps fewer NPC entities active at a time. Less active = fewer live allocations.
PalSpawnNumRate=0.5 — Default is 1.0. This halves the Pal population density across the world. The game still feels populated; RAM savings are real.
ServerPlayerMaxNum — Set this to your actual group size. If you're running an 8-person server, reserving 24 additional player slots wastes resources. The default of 32 is for public servers.
The restart schedule: the real fix
Settings reduce how fast the leak accumulates. They don't stop it. The only reliable fix is a scheduled restart that clears the leak before it degrades gameplay.
A nightly restart at 3 AM server time takes 30 seconds. Players never see the degraded state. RAM resets to baseline and the cycle starts over. In the Noogservers panel, scheduled restarts are configured under your server's settings — set it once and forget it.
When settings aren't enough
If your server lags within the first few hours after a fresh restart, the problem isn't the memory leak — it's an undersized instance. The leak is slow; early-onset lag is a RAM floor issue.
Minimum and recommended RAM by player count:
| Players | Minimum RAM | Recommended RAM |
|---|---|---|
| 1–4 | 6 GB | 8 GB |
| 5–8 | 8 GB | 12 GB |
| 9–16 | 12 GB | 16 GB |
| 17–32 | 16 GB | 24 GB |
These figures reflect a 1.0 world with Sakurajima. Pre-1.0 recommendations were roughly 2 GB lower across the board.