Palworld server lag and memory growth: what restarts can and cannot do

Is it the Palworld server, the network or your PC?

Match the symptom to a layer before changing anything, because a restart only reaches one of them. This table follows Connect Hosting (18 Jul 2026) and WinterNode, both sellers, with no data behind either.

Pocketpair's player list endpoint includes each player's ping. For a shaky connection, Connect Hosting suggests running mtr from the affected player's machine for a few minutes: loss on the final hop is real, and loss only on a middle hop is usually harmless. A version mismatch or a closed UDP 8211 port is a connection failure, not lag.

What has Pocketpair said about a memory leak?

The newest official item is Pocketpair's v1.0 changelog, posted on Steam on 10 July 2026, which lists "Fixed crashes and memory leaks occurring on PS5, Xbox, and dedicated server environments." and "Optimized memory-related processing, improving overall performance." Later patch notes through v1.0.5 (15 Sep 2026) list no further memory-leak item. An older line, "Fixed a memory leak on dedicated servers", was read on The Pal Professor's v0.5.3 page, dated 9 April 2025 and credited to Pocketpair. That fan site carries a sponsored hosting link, so treat its wording as relayed. No note gives a cause, a size or a list of affected settings.

Pocketpair's configuration page does not mention memory growth or restarts. Its arguments page says of -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS: "In v1.0 and later, leaving this parameter unset may improve performance." The example commands on the same page still include them, and the "Regarding performances" section it links is absent.

Fixes listed in April 2025 and July 2026 do not show that memory growth is absent in November 2026.

What do hosts report, and where do they disagree?

Every publisher below sells Palworld hosting, and none shows logs, a method or a test setup for its claims.

The invader figures describe three different things: memory at a fresh start, memory over a session, and the rate of growth. Pocketpair documents the key only as "Enable Invader", with no memory note. At 16 GB+ with invaders off, WinterNode says 4-6 hours while Sparked Host says daily. Treat every interval here as a starting guess.

How do you tell memory growth from load?

Log memory and server speed together for a few days. If memory climbs steadily while players and bases stay the same, and serverfps holds, restarts target the right problem. If memory is flat and serverfps drops when more players or bases are active, restarts will not help.

Pocketpair's GET /metrics returns serverfps, serverframetime (ms), currentplayernum, uptime (seconds) and basecampnum (REST API metrics). Its example response shows 57 FPS, which illustrates the format and is not a target; no official threshold was found. Palworld reports FPS and frame time, not "TPS". Enable the API with RESTAPIEnabled=True. Authentication is HTTP Basic, and Pocketpair warns the APIs "are not designed to be exposed directly to the Internet", so keep the port on your LAN.

For memory, sample the process from the operating system every minute (confirm the process name with ps or Task Manager first, since Pocketpair's docs do not name it):

while true; do
  echo "$(date -Is),$(ps -o rss= -p "$(pgrep -f PalServer | head -n1)")" >> palworld-rss-kb.csv
  sleep 60
done

Pair each sample with serverfps, player count and base count, and note each restart. After a week, compare the memory baseline at the same hour on consecutive days. A climbing baseline is growth over uptime; a flat baseline with dips in serverfps is load. Flux reports a separate failure in which the world unloads while the process keeps running, so a sudden memory drop with players stuck on a black screen deserves its own look.

Which fix should you try first?

Try these in order, cheapest first. No source read for this page shows a measured gain for any of them.

1. Update the server so it matches clients. Pocketpair's v1.0.4 notes also list load reductions, mostly in rendering.
2. Remove the three multithreading flags if your launch line has them, per Pocketpair's v1.0 note above. Then log again.
3. Trim base load. Pocketpair says increasing BaseCampMaxNumInGuild and BaseCampWorkerMaxNum "raises processing load", and marks PalSpawnNumRate as "Impacts performance." Lower one at a time. Flux says capping workers is the biggest lever on CPU; that is its claim. Stop the server before editing PalWorldSettings.ini, because WinterNode says a running server overwrites your edits.
4. Test invaders off, as a test. You lose raids, and the size of the effect is exactly what the table above disputes.
5. Set a restart schedule from your log, such as before memory reaches 80% of the plan (this page's suggested margin).

Pocketpair's REST API has POST /save and POST /shutdown, which takes a required waittime and an optional message (shutdown docs). Flux warns that some restart scripts refuse to shut down when the save fails, so check that restarts really happened.

What can a restart schedule do, and what can it not?

A restart ends the process, so memory it held is returned and the server loads again from the save. That resets growth over uptime if your log shows it, applies updates on a predictable schedule, and moves crashes to a quiet time.

It does not change how heavy the world is. If lag appears right after a restart, when memory is lowest, the cause is load or something outside the process. Restarts also disconnect everyone, so a two-hour schedule on a busy server is a visible cost, and a schedule that frequent can hide growth you could have traced to one setting.

What is not worth your time?

Skip these unless a log points at them.

• Changing host to fix shader stutter. Connect Hosting says no server can touch it, and it sells servers.
• RAM as a cure for a leak. XGamingServer, WinterNode, Sparked Host and Shockbyte all say more RAM only delays it.
• AutoSaveSpan changes. XGamingServer advises 30, but Pocketpair's configuration page does not list that key, so check it exists in your file.
• ServerReplicatePawnCullDistance below 5000. Pocketpair's stated minimum is 5000.

Keep bIsUseBackupSaveData on. Pocketpair says it "increases disk load", and its requirements page warns low-performance storage may corrupt saves, so backups protect you where disk is the weak point.

When is the answer a bigger plan or a different host?

A bigger plan buys time between restarts when your log shows real growth or out-of-memory crashes between restarts. Pocketpair's requirements page says 8 GB boots but raises the chance of out-of-memory crashes. Compare your logged peak with Palworld RAM requirements and try the server RAM calculator.

If serverfps falls with base load while memory is flat, after trimming settings, CPU is the suspect. Connect Hosting says per-core speed matters more than core count, and publishes no numbers. Ask your host for the CPU model and whether it is shared.

A different host makes sense for reasons you can check first: no region near your players, no scheduled restarts, no access to PalWorldSettings.ini, or no way to read metrics. Plan structures are on the Palworld hosting hub.

How do you test a restart interval yourself?

Change one thing at a time and keep the log. Log for 3-7 days with no schedule to see the growth rate, if any. Set an interval from that rate and log for the same length. Separately, toggle one setting and log again, keeping the interval fixed. How to benchmark your game server covers keeping runs comparable.

What GameServerBench plans to record

GameServerBench has no data on restart intervals or the invader setting. The planned protocol would run identical scripted bot load with different restart intervals and one setting toggled at a time, logging memory, serverfps and ping, and publish the raw logs with dates. A statement about memory growth over weeks needs a 30-day run per host, which has not happened. Hosts' terms may restrict automated load; see independence and host terms.

If your log shows growth, go next to the Palworld RAM requirements.