Optimiser les ressources d'un serveur Palworld dédié sans sacrifier la fluidité

Optimisation serveur Palworld : tout se joue sur quatre curseurs, la mémoire allouée, le nombre de Pals simulés en permanence, la cadence d'auto-save et le nombre de joueurs autorisés. Bien réglés, ils permettent de tenir un monde fluide sur une machine raisonnable. Mal réglés, ils font gonfler la sauvegarde et provoquent des micro-freezes toutes les trente secondes.

Où passent la RAM et le CPU d'un monde persistant

Le moteur de Palworld simule en continu chaque Pal assigné à une base, chaque structure posée, chaque objet tombé au sol et chaque coffre. Cette simulation ne s'arrête pas quand le propriétaire est déconnecté : les bases continuent de produire. C'est la principale raison pour laquelle la consommation mémoire grimpe semaine après semaine, même sans nouveau joueur.

Côté processeur, le jeu repose massivement sur un thread principal. Un CPU à forte fréquence par cœur, comme un Ryzen 9 7950X3D, encaisse bien mieux qu'un processeur à nombreux cœurs lents. Ajouter des cœurs ne divise pas la charge du thread de simulation, c'est la fréquence et l'IPC qui déterminent la fluidité ressentie en jeu.

Le troisième poste, souvent ignoré, c'est le disque. Chaque auto-save sérialise l'intégralité du monde dans Level.sav, un fichier qui dépasse facilement plusieurs centaines de mégaoctets sur un monde mature. Sur un stockage lent, cette écriture bloque le thread principal et produit le fameux gel d'une à trois secondes que tous les joueurs ressentent en même temps.

Les trois symptômes à reconnaître

• Freeze périodique régulier : auto-save trop fréquente ou sauvegarde devenue trop volumineuse.
• Dégradation progressive sur plusieurs heures : accumulation mémoire, corrigée par un redémarrage planifié.
• Rubber-banding permanent des Pals : trop d'entités répliquées autour des joueurs, ou bande passante saturée.

Les réglages de PalWorldSettings.ini qui pèsent sur les performances

Avant toute modification, sachez qu'une machine correctement dimensionnée dès le départ évite la moitié des problèmes décrits ici : un hébergement Palworld avec RAM DDR5 ECC et SSD NVMe absorbe naturellement les pics d'écriture des sauvegardes. Les réglages qui suivent restent utiles dans tous les cas, ils réduisent la charge à la source.

Le fichier se trouve dans Pal/Saved/Config/LinuxServer/PalWorldSettings.ini. À la première installation il est vide : il faut le remplir à partir du modèle livré à la racine de l'installation, sinon le serveur ignore vos valeurs et repart sur les réglages par défaut.

cd ~/PalServer
cp DefaultPalWorldSettings.ini Pal/Saved/Config/LinuxServer/PalWorldSettings.ini
nano Pal/Saved/Config/LinuxServer/PalWorldSettings.ini

Piège classique : tous les paramètres tiennent sur une seule ligne, à l'intérieur de OptionSettings=(...). Une virgule oubliée, un retour à la ligne ajouté par un éditeur trop zélé, et le serveur redémarre sur la configuration par défaut sans le moindre message d'erreur. Éditez toujours le serveur à l'arrêt, puis vérifiez vos valeurs en jeu.

Tableau des paramètres orientés ressources

Paramètre	Défaut	Valeur de travail	Effet sur la charge
ServerPlayerMaxNum	32	10 à 16	Moins de zones chargées simultanément
AutoSaveSpan	30	180 à 300	Supprime les freezes réguliers
BaseCampMaxNumInGuild	4	2 ou 3	Limite les bases simulées hors ligne
BaseCampWorkerMaxNum	15	10 à 15	Réduit les Pals en IA permanente
DropItemMaxNum	3000	1000 à 1500	Allège Level.sav et le réseau
DropItemAliveMaxHours	1.0	0.5	Nettoyage plus rapide du sol
PalSpawnNumRate	1.0	0.7 à 1.0	Moins de Pals sauvages actifs
ServerReplicatePawnCullDistance	15000	10000 à 12000	Diminue la réplication réseau
bIsUseBackupSaveData	True	True	Consomme du disque, à purger

Les valeurs de gameplay (taux de capture, vitesse d'expérience, dégâts) n'ont aucun impact mesurable sur la charge machine. Ne les touchez que pour l'équilibrage de votre communauté, pas dans l'espoir de gagner des images par seconde. Le détail complet des clés reste consultable dans la documentation technique officielle de Palworld.

Options de lancement côté binaire

Certains arguments passés au démarrage changent la façon dont le moteur répartit ses tâches. Ils s'ajoutent au script de démarrage, pas au fichier de configuration.

./PalServer.sh -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS \
  -port=8211 -queryport=27015 -players=16

Sur les machines à forte fréquence, ce trio réduit les à-coups de chargement quand plusieurs joueurs explorent des zones éloignées. Testez sans, puis avec, sur une session de deux heures avec le même nombre de connectés : c'est le seul moyen sérieux de juger l'effet sur votre monde.

Limiter les Pals actifs, les bases et les objets au sol

Chaque Pal assigné à une base tourne dans une boucle d'IA permanente : recherche de tâche, déplacement, pathfinding, gestion de la faim. Multipliez par le nombre de bases autorisées, puis par le nombre de guildes, et vous obtenez la vraie charge de votre monde. Trois joueurs avec quatre bases chacune saturées de Pals pèsent plus lourd que quinze joueurs nomades.

Réduire le compte global de Pals

• BaseCampMaxNumInGuild à 2 ou 3 : le levier le plus efficace, et le moins ressenti par les joueurs qui construisent rarement quatre bases utiles.
• BaseCampWorkerMaxNum maintenu à 15 maximum : au-delà, le pathfinding s'effondre et les Pals se bloquent dans les décors.
• PalSpawnNumRate à 0.7 : moins de faune sauvage simulée pendant les déplacements, sans rendre les zones désertes.
• bEnableInvaderEnemy à False si les raids ne servent à rien sur votre monde : chaque vague génère un pic d'entités.

Le nettoyage des objets et des guildes fantômes

Les objets au sol sont stockés dans la sauvegarde jusqu'à leur expiration. Un monde ouvert depuis des mois avec DropItemMaxNum=3000 traîne en permanence des milliers d'entités inutiles. Descendre à 1000 et réduire DropItemAliveMaxHours à 0.5 fait fondre le volume de Level.sav en quelques cycles de sauvegarde.

Même logique pour les joueurs partis : activez la remise à zéro automatique des guildes inactives. Les bases abandonnées continuent sinon d'être simulées et sauvegardées éternellement.

bAutoResetGuildNoOnlinePlayers=True,
AutoResetGuildTimeNoOnlinePlayers=168.000000

Cent soixante-huit heures correspondent à sept jours sans connexion. Annoncez la règle sur votre Discord avant de l'activer : un joueur qui revient de vacances et retrouve sa base effacée ne revient généralement pas une seconde fois.

Fréquence de sauvegarde : trouver le bon compromis

La valeur par défaut de AutoSaveSpan est de 30 secondes. Sur un monde jeune, personne ne le remarque. Sur un monde de plusieurs centaines de mégaoctets, cela signifie une écriture complète toutes les demi-minutes, donc un micro-gel permanent pour tout le monde. C'est la cause numéro un des plaintes de lag sur les mondes anciens.

Passer à 300 secondes change radicalement le ressenti. Le risque assumé est de perdre au maximum cinq minutes de progression en cas d'arrêt brutal, ce qui reste acceptable pour la plupart des communautés. Pour un monde très fréquenté où la progression est rapide, 180 secondes offrent un équilibre plus prudent.

AutoSaveSpan=300.000000,
bIsUseBackupSaveData=True,

Surveiller le poids réel des sauvegardes

Le dossier de sauvegarde se trouve dans Pal/Saved/SaveGames/0/<IDdumonde>/. Mesurez-le chaque semaine pour repérer une dérive avant qu'elle ne devienne bloquante.

du -sh ~/PalServer/Pal/Saved/SaveGames/0/*/
ls -lh ~/PalServer/Pal/Saved/SaveGames/0/*/Level.sav

Au-delà de 500 Mo pour Level.sav, les temps de sauvegarde deviennent perceptibles quel que soit le matériel. C'est le signal qu'il faut nettoyer les guildes inactives et resserrer les limites d'objets plutôt que d'ajouter de la mémoire.

Garder les sauvegardes de secours sous contrôle

Les copies de secours s'empilent dans le sous-dossier backup et finissent par saturer le disque. Une purge automatisée évite l'incident classique du serveur qui refuse d'écrire faute d'espace.

find ~/PalServer/Pal/Saved/SaveGames/0/*/backup/ -type d -mtime +14 -exec rm -rf {} +

Conservez malgré tout une copie hors machine avant chaque mise à jour majeure du jeu. Une sauvegarde locale ne protège pas d'une corruption de fichier survenue pendant une écriture interrompue.

Calibrer les slots joueurs sur la mémoire disponible

Le plafond du jeu est de 32 joueurs, mais ce chiffre suppose un monde peu chargé et une machine solide. Chaque joueur connecté charge sa portion de carte, ses Pals d'escouade et déclenche la réplication des entités environnantes. Deux groupes qui explorent deux extrémités opposées de la carte coûtent bien plus cher que dix joueurs réunis dans la même base.

Ordres de grandeur mémoire

• 4 à 8 joueurs, monde récent : 8 Go de RAM suffisent confortablement.
• 8 à 16 joueurs, monde installé depuis plusieurs mois : prévoir 12 à 16 Go.
• 16 à 32 joueurs, guildes nombreuses et bases maximales : 16 Go minimum, avec surveillance active.

Ces valeurs décrivent le comportement du jeu, pas une règle absolue. Un monde à dix joueurs avec quarante bases actives consomme davantage qu'un monde à vingt joueurs discipliné sur le nombre de camps. Comptez toujours en entités simulées, pas en slots vendus.

Réduire ServerPlayerMaxNum reste le levier le plus honnête quand la machine sature. Mieux vaut un monde fluide à seize places qu'un monde à trente-deux qui gèle dès que la moitié des joueurs se connectent. D'autres titres du même genre réagissent de façon comparable, comme on le voit sur tous nos serveurs de jeux orientés survie et construction.

Redémarrages planifiés et suivi des ressources

Le processus Palworld accumule de la mémoire au fil des heures. Un redémarrage quotidien, planifié à une heure creuse, remet le compteur à zéro et évite la dégradation progressive que les joueurs décrivent comme un lag apparu de nulle part en fin de soirée.

Arrêt propre via RCON

Activez RCON dans la configuration, avec un mot de passe distinct de celui de l'administrateur en jeu.

RCONEnabled=True,
RCONPort=25575,
AdminPassword="mot_de_passe_long_et_unique",

Le script d'arrêt prévient les joueurs, force une sauvegarde, puis coupe proprement. Attention, la commande Broadcast n'accepte pas les espaces : utilisez des underscores, sinon seul le premier mot est transmis.

#!/bin/bash
RCON="/opt/palworld/rcon -a 127.0.0.1:25575 -p mot_de_passe_long_et_unique"
$RCON "Broadcast Redemarrage_dans_60_secondes"
$RCON "Save"
sleep 5
$RCON "Shutdown 60 Maintenance_quotidienne"

chmod +x /opt/palworld/restart.sh
crontab -e
# Redémarrage quotidien à 6h du matin
0 6 * * * /opt/palworld/restart.sh >> /var/log/palworld-restart.log 2>&1

Mesurer avant de modifier

Avant de changer un paramètre, relevez l'état réel de la machine. Sans mesure de départ, impossible de savoir si un réglage a servi à quelque chose.

free -h
htop -p $(pgrep -f PalServer-Linux)
journalctl -u palworld --since "1 hour ago" | tail -50

Sur un panel de gestion, les graphiques de consommation et la console en direct donnent la même information sans ligne de commande. Notez la mémoire utilisée juste après un redémarrage, puis six heures plus tard : l'écart mesure exactement la dérive de votre monde. D'autres méthodes de suivi sont détaillées sur le blog Nexus Games.

Conclusion

Commencez par AutoSaveSpan : passer de 30 à 300 secondes règle à lui seul la majorité des plaintes de lag sur un monde ancien. Enchaînez avec la limite de bases par guilde, qui réduit durablement le nombre de Pals simulés. Ajouter de la mémoire sans avoir touché ces deux réglages revient à payer pour sérialiser plus vite un monde inutilement lourd. Mesurez avant, mesurez après, ne changez qu'un paramètre à la fois.

FAQ

Comment déplacer un monde Palworld vers une autre machine sans perdre les Pals ?