Palworld server lag: bases, Pals and resource pressure

Record useful conditions

Note player count, active bases, working Pals, mods and game version. Compare a quiet location with a busy base, then repeat under similar conditions after each change.

If only one client loses FPS, inspect its graphics settings and mods first. If players on several networks experience the same delays, collect panel measurements and logs. Do not assume insufficient RAM without checking whether usage reaches the actual limit.

Inspect settings that increase simulation work

Pocketpair explicitly identifies additional load from more bases per guild and more Pals per base. Review BaseCampMaxNumInGuild, BaseCampWorkerMaxNum and PalSpawnNumRate before blindly adding resources.

Do not sharply lower limits on the main world when existing bases or Pals may depend on them. Prepare a copy, agree with the group and verify the effect. Settings that delete inactive guilds are not consequence-free optimization switches.

Reconsider older performance arguments

Startup recipes copied from old tutorials may be outdated. For version 1.0 onward, Pocketpair notes that leaving the older -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS arguments unset may improve performance.

This is not a guarantee for every server. Retain the current startup configuration and compare a test using guidance for your version. Avoid simultaneously updating every mod, which would obscure the cause of any difference.

Match symptoms to resource constraints

Memory climbing toward a shutdown calls for reviewing logs and the effective limit. Save-related pauses also warrant checking disk workload and backup frequency. A restart that helps for only a few hours deserves investigation of the subsequent degradation.

When saturation is established, share these observations with support to choose suitable hosting. For capacity planning, see our Palworld RAM guide. This article diagnoses an existing active world.

Frequently asked questions