Configurer un serveur Palworld pour de meilleures performances

PalWorldSettings.ini is the configuration file that decides how much CPU, memory and disk I/O your Palworld world actually burns once real players start logging in, breeding Pals and building bases. Every value inside this file compounds with the others during the tick loop. This guide walks through the parameters that drive lag, with concrete values to keep the simulation stable under load.

PalWorldSettings.ini and the Palworld Tick Loop

On a dedicated Palworld process, the file lives under Pal/Saved/Config/WindowsServer/PalWorldSettings.ini (or LinuxServer on a Linux build). It's a single-line structure starting with [/Script/Pal.PalGameWorldSettings] followed by an OptionSettings=(...) block where every parameter sits comma-separated. The process reads this file once at launch, so each change requires a restart to take effect — there's no hot reload.

The tick loop is what simulates Pal AI, hunger/stamina decay, base production and physics every frame. Every entity that exists — a Pal, a dropped item, a base worker — adds a small cost to that loop. PalWorldSettings.ini doesn't control the tick rate directly, but it controls how many entities the tick loop has to process, which is what actually produces or removes lag on a running instance. If you're setting this up from scratch, our Palworld server hosting environment ships with the file pre-generated and reachable through the file manager, so you can start tuning values immediately instead of hunting for the path.

Before touching anything, open a console and confirm the process is healthy:

systemctl status palworld
tail -f /var/log/palworld/server.log

If the log shows repeated save stalls or frame hitches during combat, the cause is almost always too many active entities rather than raw player count. That's where the next sections come in.

Pal Spawn Rates and CPU Load

Pal spawn density is the single biggest lever on CPU usage in PalWorldSettings.ini. Every Pal roaming the map runs its own AI behavior tree — pathfinding, aggro checks, idle animations — and that cost scales roughly linearly with population, not with the number of connected players.

Parameter	Default	Lower-lag value	Effect
PalSpawnNumRate	1.000000	0.600000 - 0.800000	Reduces the number of simultaneously simulated Pals
PalCaptureRate	1.000000	unchanged	Gameplay only, no measurable tick cost
EnablePredatorBossPal	True	False on small worlds	Boss Pals carry heavier AI routines
PalEggDefaultHatchingTime	72.000000	unchanged	Affects breeding pace, not performance
CollectionObjectRespawnSpeedRate	1.000000	0.800000	Fewer world objects respawning at once

A practical rule used on busy communities: if your guild has 15+ active members exploring simultaneously, drop PalSpawnNumRate before touching anything else. It's the fastest way to cut entity count without changing drop rates, capture mechanics or progression. The official technical documentation also details how spawn density interacts with region loading: Palworld Technical Documentation.

World and Guild Limits: Memory and Replication Cost

Beyond spawn density, PalWorldSettings.ini defines hard ceilings that determine how much memory the process reserves and how much data gets replicated to every connected client each tick.

Parameters that drive memory footprint

• ServerPlayerMaxNum — each connected player holds inventory, equipment and position state in memory; raising this past what your community actually fills wastes RAM reservations.
• GuildPlayerMaxNum — larger guilds mean more shared base data synced across members.
• BaseCampMaxNum and BaseCampWorkerMaxNum — every base worker runs its own task queue (farming, crafting, transport); this is one of the heaviest replication costs in the game.
• DropItemMaxNum — dropped items left on the ground persist and get replicated until despawn; high values on a long-running world without cleanup quietly accumulate.

Replication distance

ServerReplicatePawnCullDistance controls how far an entity needs to be from a player before the server stops sending its updates to that client. Lowering this value from the default reduces network tick cost on worlds with many simultaneous Pals and workers, at the cost of pop-in at range. On a world running 20+ concurrent players, trimming this distance usually buys more headroom than lowering spawn rates alone.

A sane baseline for a mid-size community (10-20 players):

ServerPlayerMaxNum=20
GuildPlayerMaxNum=20
BaseCampMaxNum=60
BaseCampWorkerMaxNum=12
DropItemMaxNum=2000
ServerReplicatePawnCullDistance=15000.000000

Push these numbers up only after confirming CPU headroom with top or the panel's live resource graph — don't guess. For communities running several worlds side by side, keeping an eye on All our game servers resource usage per instance helps spot which world is the actual bottleneck before you start editing values blindly.

Autosave Interval, Backup I/O and Tick Stability

The last piece of PalWorldSettings.ini that directly affects stability is the autosave system. A save operation serializes the entire world state — every Pal, item, base and player — to disk, and during that write the tick loop briefly stalls. On larger worlds this stall is visible as a short freeze every time the autosave fires.

Key parameters

• AutoSaveSpan — interval in minutes between automatic saves. The default (30) is a reasonable middle ground; dropping it too low (under 10) multiplies stall frequency.
• bIsUseBackupSaveData — keeps rotating backup copies; useful for recovery but adds extra disk writes on top of the regular save.
• WorkSpeedRate — doesn't touch saves directly, but faster base production means more state changes accumulate between saves, slightly increasing each save's write size.

For a world with heavy base-building, stretching the interval slightly and relying on scheduled backups instead reduces the frequency of stalls without giving up recovery points:

AutoSaveSpan=45
bIsUseBackupSaveData=True

Apply the change, then restart the instance so the new values load:

systemctl restart palworld
journalctl -u palworld -f

Watch the log around the next scheduled save timestamp — the gap between "Saving..." and "Save complete" is your real stall duration. If it's consistently above a second or two on an NVMe-backed instance, the bottleneck is almost always the entity count discussed earlier, not the disk itself. Automated backups running on the platform side, separate from the in-game save system, also mean you can safely push AutoSaveSpan a bit higher without losing recovery options. For broader tuning reading on other survival titles, the Fly-Serv blog covers similar configuration patterns worth comparing against.

Conclusion

PalWorldSettings.ini gives you direct control over the variables that actually produce lag: spawn density, world limits and save frequency. Adjust one parameter at a time, restart, and check the logs before moving to the next — that incremental approach is what turns a laggy world into a stable one.

FAQ

Does changing PalWorldSettings.ini require a full world wipe?

No. Editing values in PalWorldSettings.ini only affects how the game engine behaves going forward; it doesn't touch the save data itself. A restart is enough for changes to apply.

Which single parameter has the biggest impact on CPU usage?

PalSpawnNumRate. It directly controls how many Pals are simultaneously simulated, and AI processing for each one is the heaviest recurring cost in the tick loop.

Why does my world freeze briefly every 30 minutes?

That's the autosave triggered by AutoSaveSpan writing the full world state to disk. If the freeze is too noticeable, raise the interval slightly and reduce entity count first rather than lowering save frequency too aggressively.