When a Palworld base starts stuttering, first establish whether the problem is the player's frame rate, the connection or the dedicated server's simulation. Those require different changes. Increasing a tick-rate limit or buying more RAM without that distinction can leave the original problem untouched.
This guide covers an existing dedicated server and its current world. Pocketpair's documentation checked on 25 October 2026 is version 1.0.4; settings inherited from early-access guides deserve a fresh review.
Find out who slows down, and where#
Ask two players to visit the affected base together. Compare their local FPS and whether interactions with the world are delayed. Then visit a quieter location with the same players. Use ordinary movement and the same short activity rather than comparing a peaceful baseline with a raid.
| Observation | Next check |
|---|---|
| One player loses FPS while another remains smooth | Compare that client's resolution, graphics settings and resource use. |
| Both players see delayed interactions or position corrections | Compare server frame time and their connection behavior at the same timestamp. |
| One player has delayed interactions everywhere | Compare that player's route, Wi-Fi and other traffic before changing the base. |
| One worker is stuck while other interactions remain responsive | Inspect that Pal's access to the job, bed and food; this alone does not establish server overload. |
These are diagnostic branches, not final diagnoses. For example, a base can be expensive for both the client to draw and the server to simulate. Record both symptoms instead of choosing whichever explanation sounds familiar.
Capture a comparable baseline#
Keep a small log: time, server build, uptime, players online, their locations, active base work, mods and the visible symptom. Include the host's CPU usage by core, memory pressure, disk activity and any container resource limits. A low average across many CPU cores can conceal a busy core; unused host memory does not prove a container has room left.
If a private REST connection is already configured, Palworld's metrics include serverfps, serverframetime in milliseconds, currentplayernum, uptime and basecampnum. Server FPS describes server work, not the frames rendered on a player's screen. Compare a series of observations rather than one instantaneous number; the example values in the API documentation are not performance targets.
Use the existing private REST access guide if you need that collection route. Do not publish the administration endpoint to gather a measurement. Otherwise start with available host monitoring and players' observations.
An example experiment is five minutes at a quiet location followed by five minutes at the affected base, with the same participants. That duration is a starting procedure, not a guarantee that intermittent stalls will appear. Extend it when the reported fault occurs less often.
Reduce one piece of base work reversibly#
Before testing, save and protect the world with the save-before-shutdown procedure. Avoid dismantling a developed base to obtain your first comparison.
Start with something you can undo: temporarily return a known group of workers to the Palbox, or pause one production activity through its normal controls. Record exactly what changed. Keep the players and test route the same, then repeat the baseline observation. Restore the previous arrangement and repeat if the result is unclear.
Pocketpair identifies higher BaseCampWorkerMaxNum and BaseCampMaxNumInGuild values as additional processing load. Treat these limits as capacity decisions, not automatic cleanup tools. Lowering a maximum does not establish that existing bases or assigned workers were removed. Confirm the actual workload in the world before interpreting the comparison.
If fewer active workers improve server frame time while client FPS remains poor, you have evidence for two separate investigations. If nothing changes, restore the workers and test another hypothesis. Do not stack several changes until it becomes impossible to tell which mattered.
Review old startup tweaks and the host#
The current official argument table says that, in Palworld 1.0 and later, leaving -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS unset may improve performance. The same page still contains older-looking example commands with those flags. That is a reason to compare your real launch arguments against the current version-specific table, rather than copying an old optimization block.
Record the existing launch command before testing an alternative. Preserve unrelated port, listing and instance arguments. A restart changes uptime too, so compare similar periods after each startup. Removing the flags is an experiment, not a promised fix.
Check whether a container CPU quota, memory limit, competing process or storage stall coincides with the slowdown. Pocketpair's hardware requirements are a starting point for operation; they are not a guaranteed base count. If memory repeatedly reaches its limit or the process is killed, retain the logs. A scheduled restart can hide the timing of growth without resolving its cause.
Keep changes that survive a repeat check#
For a persistent setting change, stop the server cleanly, retain a copy of its effective PalWorldSettings.ini, edit that instance's existing configuration and restart normally. The file is under Pal/Saved/Config/WindowsServer or LinuxServer. Editing DefaultPalWorldSettings.ini alone does not apply the setting.
Verify the expected world, the changed value and the same base activity after startup. Revert if the result fails to repeat or the gameplay cost exceeds the benefit. Preserve the world backup independently of the configuration copy.
For a server on your own infrastructure, Nexardo can provide a common administration interface. Useful performance decisions still depend on comparable measurements and a known rollback point.
When asking for further help, send the build, launch arguments, limits, timestamps and before/after observations. Remove passwords and tokens. “Both players lose server responsiveness at this base while frame time rises” gives an operator something testable; “the server lags” does not.
