Optimiser les performances d’un serveur Palworld

Réponse courte : en Palworld 1.0, la documentation officielle Pocketpair indique que ne pas renseigner les arguments -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS peut améliorer les performances. C’est l’inverse exact de ce que recommandent la quasi-totalité des tutoriels francophones et anglophones, hérités de la version 0.x. Testez les deux configurations sur votre propre serveur, avec vos joueurs, et gardez la meilleure. Le reste de l’optimisation tient en trois piliers : fréquence CPU élevée (Palworld dépend surtout du mono-thread), 16 Go de RAM (recommandation officielle) et SSD NVMe (un stockage lent peut corrompre les sauvegardes selon la doc).

Les offres serveur Palworld d’HebergTonServ tournent sur AMD Ryzen 9 5950X et SSD NVMe, avec 16 Go de RAM sur l’offre Pro — exactement la recommandation Pocketpair.

Le gotcha 1.0 : les arguments multithread ne sont plus une évidence

Depuis la sortie du serveur dédié en 0.x, une recette circule partout : ajoutez -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS à votre ligne de lancement, et votre serveur ira mieux. Elle est reprise telle quelle par des dizaines de tutoriels, de vidéos et de panels d’hébergement.

La documentation officielle de Palworld indique qu’en version 1.0 et supérieure, ne PAS renseigner ces paramètres peut améliorer les performances.

Ces arguments existent toujours et restent documentés — l’exemple officiel de ligne de commande les utilise encore :

PalServer.exe -port=8000 -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS

Mais leur bénéfice n’est plus acquis. Le moteur a évolué entre la 0.x et la 1.0, et ce qui compensait un défaut de threading en early access peut désormais brider le serveur.

Ce qu’il faut en faire concrètement

Ne remplacez pas un dogme par un autre. Pocketpair écrit que le retrait peut améliorer les performances, pas qu’il l’améliore toujours. La bonne démarche est un test A/B sur votre serveur, avec votre charge :

Configuration	Ligne de lancement	À mesurer
A — historique	`-port=8211 -players=32 -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS`	Fluidité en base, latence ressentie, stabilité sur 2 h
B — 1.0	`-port=8211 -players=32`	Idem, même créneau horaire, même nombre de joueurs

Protocole minimal pour que le test veuille dire quelque chose :

Testez au même moment de la journée, avec un nombre de joueurs comparable
Laissez tourner au moins deux heures par configuration — les problèmes de threading se révèlent sous charge, pas au démarrage
Ne changez rien d’autre entre les deux essais : ni la config .ini, ni les mods, ni le nombre de bases
Notez ce qui se ressent vraiment : rubber banding, délai de ramassage d’objets, Pals de base figés

À 4-8 joueurs, la différence sera souvent imperceptible. C’est à 16 joueurs et au-delà, avec plusieurs bases actives, que le choix devient mesurable.

Ce guide est à jour pour Palworld 1.0 (sortie le 10 juillet 2026).

Les autres arguments de lancement utiles

Argument	Effet	Recommandation
`-port=8211`	Port d’écoute UDP du serveur	Laisser 8211 sauf conflit — voir ouvrir les ports Palworld
`-players=32`	Nombre maximum de joueurs simultanés	Mettre la valeur réellement visée, pas 32 par défaut
`-NumberOfWorkerThreadsServer=X`	Nombre de threads de travail du serveur	À ajuster selon les threads réellement alloués
`-publiclobby`	Publie le serveur dans la liste communautaire	Coût réseau marginal, à n’activer que si nécessaire
`-logformat=text`	Format des logs (`text` ou `json`)	`text` pour lire, `json` pour outiller

`-NumberOfWorkerThreadsServer` : combien mettre ?

Cet argument fixe le nombre de threads de travail du serveur. Pocketpair le documente mais ne publie pas de valeur optimale.

Le principe de dimensionnement est simple : cette valeur doit rester cohérente avec les threads dont vous disposez réellement. Sur une offre à 2 ou 3 threads, déclarer 16 threads de travail ne crée pas de puissance, cela crée de la contention. Ne renseignez cet argument que si vous constatez un problème et que vous mesurez l’effet du changement — sinon, laissez-le non renseigné.

Pourquoi la fréquence CPU compte plus que le nombre de cœurs

C’est le point que les comparatifs d’hébergement escamotent le plus souvent, parce que « 8 vCPU » se vend mieux que « fréquence élevée ».

La documentation officielle recommande 4 cœurs et plus pour le serveur dédié Palworld. Mais au-delà de ce seuil, empiler des cœurs n’apporte pas grand-chose : la boucle de simulation du monde reste très dépendante du mono-thread. Le calcul de l’IA des Pals, des bases actives et de la physique se concentre sur un chemin d’exécution que le nombre de cœurs ne raccourcit pas.

Conséquence directe pour choisir une offre :

Critère	Impact réel sur un serveur Palworld
Fréquence / performance mono-cœur	Déterminant — c’est ce qui fixe la fluidité de la simulation
Nombre de threads alloués	Utile jusqu’au seuil recommandé (4 cœurs +), rendement décroissant ensuite
Génération du CPU	Importante : IPC plus élevé = plus de travail par cycle
« vCPU » sans fréquence annoncée	Information peu exploitable en l’état

Un AMD Ryzen 9 5950X, comme celui qui équipe les offres Palworld d’HebergTonServ, coche la bonne case : haute fréquence et fort IPC. Une offre à beaucoup de cœurs mais à fréquence basse produira un serveur qui lag alors que le graphique d’utilisation CPU paraît confortable — parce que c’est un cœur qui sature, pas l’ensemble.

Combien de RAM pour tenir la charge ?

La documentation officielle Pocketpair est nette : 16 Go de RAM recommandés. Elle précise que 8 Go permet de démarrer le serveur, mais augmente le risque de crash par manque de mémoire (out of memory).

Contexte	RAM
Petit groupe, monde jeune	8 Go — fonctionne, mais avec un risque de crash OOM documenté
Recommandation officielle Pocketpair	16 Go
Serveur chargé : nombreuses bases, monde ancien, effectif proche de 32 joueurs	16 Go, sans compression

Le manque de RAM ne se manifeste pas par un message clair. Il produit des freezes de quelques secondes, puis un crash sec en pic de connexions — symptômes que tout le monde attribue au réseau. Si votre serveur tient bien à 6 joueurs et s’écroule à 15, la mémoire est le premier suspect. Le détail du dimensionnement est traité dans combien de RAM pour un serveur Palworld. L’offre Pro d’HebergTonServ fournit 16 Go de DDR4, soit exactement la recommandation officielle.

Le stockage : un enjeu de performance ET d’intégrité

La configuration requise officielle indique : « Recommended for faster SSD. Low-performance storage may corrupt saved data ». Un stockage lent peut corrompre les données sauvegardées.

Ce point dépasse la question du confort. Palworld écrit un fichier Level.sav volumineux d’un bloc ; sur un stockage lent, ces écritures s’étirent, se chevauchent avec l’activité du serveur et provoquent des à-coups perceptibles en jeu. Si un arrêt ou un crash survient pendant une écriture qui traîne, le fichier reste partiel. C’est aussi la raison pour laquelle la documentation déprécie Docker Desktop comme méthode d’hébergement.

En clair : SSD NVMe, jamais de HDD ni de stockage réseau lent pour le dossier Pal/Saved/. Et une politique de sauvegarde qui suit — voir sauvegarder et restaurer un serveur Palworld.

Les leviers côté `PalWorldSettings.ini`

Le matériel ne fait pas tout : plusieurs paramètres de configuration pilotent directement la quantité de simulation que le serveur doit maintenir en permanence.

Paramètre	Effet sur la charge	Conseil
`ServerPlayerMaxNum`	Chaque slot est un joueur potentiel, avec sa base et ses Pals	Mettre le nombre réaliste, pas 32 par principe
`BaseCampMaxNumInGuild`	Nombre de bases par guilde — chaque base est simulée en continu	Levier le plus efficace : la doc PvP suggère `2` pour maîtriser la charge
`GuildPlayerMaxNum`	Taille maximale d’une guilde	La doc PvP suggère `4` ; des guildes plus petites répartissent mieux la charge
`bEnableInvaderEnemy`	Active les raids d’ennemis sur les bases	Le désactiver retire des vagues d’entités simulées et calme les pics

BaseCampMaxNumInGuild est le paramètre le plus sous-estimé. Une base n’est pas un décor : ses Pals travaillent, produisent et se déplacent en permanence, même sans joueur à proximité. Multipliez par le nombre de guildes, et vous obtenez la vraie charge de votre serveur. Sur un serveur qui rame en fin de saison, réduire le nombre de bases par guilde a plus d’effet que n’importe quel argument de lancement.

bEnableInvaderEnemy mérite un test si vos joueurs signalent des saccades périodiques : les vagues d’invasion créent des pics d’entités.

Le détail de chaque famille de réglages est couvert dans configurer un serveur Palworld via PalWorldSettings.ini. Sur un serveur PvP, les recommandations d’équilibrage officielles vont dans le même sens — voir activer le PvP sur un serveur Palworld.

Redémarrages planifiés : simple, et ça marche

Un serveur de jeu à monde persistant accumule de la mémoire au fil des heures. Un redémarrage quotidien à heure creuse remet les compteurs à zéro et évite la dérive lente que les joueurs décrivent comme « ça lag de plus en plus dans la soirée ».

La procédure propre, avec les commandes admin officielles :

/Broadcast Redemarrage planifie dans 5 minutes
/Save
/Shutdown 60 "Redemarrage quotidien"

Le /Save avant le /Shutdown garantit que le monde est écrit sur le disque avant l’arrêt. Une fois par jour suffit : redémarrer toutes les 4 h dérange plus les joueurs que ça ne résout de problèmes. Voir les commandes admin Palworld.

Lag serveur ou FPS client : ne pas confondre

C’est la source de diagnostic erroné la plus fréquente : un joueur dit « ça lag », et l’administrateur cherche côté serveur alors que le problème est sur le PC du joueur — ou l’inverse.

Ce que voit le joueur	Origine	Où chercher
Image saccadée, compteur de FPS bas, mais déplacements cohérents	Client	Réglages graphiques, GPU, pilotes du joueur
Image fluide mais personnage qui « revient en arrière » (rubber banding)	Serveur ou réseau	Charge serveur, latence, qualité de la connexion
Ramassage d’objets et interactions en retard de 1 à 3 secondes	Serveur	CPU saturé, RAM limite, trop de bases simulées
Pals de base figés ou immobiles	Serveur	Simulation en retard : réduire les bases par guilde
Freezes brefs de tout le monde en même temps	Serveur	Mémoire ou écriture disque
Un seul joueur en difficulté, les autres non	Client / réseau du joueur	Sa connexion, son matériel

Le test qui tranche en dix secondes : est-ce que tout le monde subit le problème au même instant ? Si oui, c’est le serveur. Si c’est une seule personne, c’est chez elle.

Tableau symptôme → cause probable → correctif

Symptôme	Cause probable	Correctif
Lag général qui s’aggrave au fil des heures	Accumulation mémoire	Redémarrage quotidien planifié
Crash au pic de connexions	RAM insuffisante (8 Go = risque OOM documenté)	Passer à 16 Go, la recommandation officielle
Saccades permanentes malgré peu de joueurs	Fréquence CPU trop basse (simulation mono-thread)	CPU à haute fréquence, pas plus de cœurs
Freezes courts et réguliers de tout le serveur	Écritures disque lentes	SSD NVMe pour `Pal/Saved/`
Lag proportionnel au nombre de bases construites	Trop de bases simulées en permanence	Réduire `BaseCampMaxNumInGuild`
Pics de lag périodiques sans cause évidente	Raids d’invasion	Tester `bEnableInvaderEnemy=False`
Performances dégradées depuis le passage en 1.0	Arguments multithread hérités de la 0.x	Tester le lancement sans `-useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS`
Serveur lent après ajout de mods	Charge additionnelle des mods	Retirer les mods un par un pour isoler (mods Palworld)
Un seul joueur ressent le problème	Client ou réseau du joueur	Rien à corriger côté serveur

FAQ

Faut-il ajouter `-useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS` sur Palworld 1.0 ?

Pas automatiquement. La documentation officielle Pocketpair indique qu’en version 1.0 et supérieure, ne pas renseigner ces arguments peut améliorer les performances — l’inverse de ce que recommandent les tutoriels hérités de la 0.x. Testez les deux lignes de lancement sur votre serveur, deux heures chacune à charge comparable, et conservez la meilleure.

Combien de RAM faut-il pour un serveur Palworld ?

La documentation officielle recommande 16 Go. Elle précise que 8 Go permet de démarrer le serveur mais augmente le risque de crash par manque de mémoire (out of memory). Pour un serveur destiné à durer, avec plusieurs bases et un effectif proche des 32 joueurs maximum, 16 Go est le bon dimensionnement.

Faut-il privilégier la fréquence CPU ou le nombre de cœurs pour Palworld ?

La fréquence. La documentation recommande 4 cœurs et plus, mais la simulation du monde reste très dépendante du mono-thread : au-delà de ce seuil, la performance par cœur détermine la fluidité bien plus que le nombre de cœurs. Un CPU haute fréquence de génération récente, type Ryzen 9 5950X, est le bon choix.

Pourquoi mon serveur Palworld lag alors que le CPU n’est pas à 100 % ?

Parce que l’utilisation globale masque la saturation d’un seul cœur. Palworld concentre sa boucle de simulation sur un chemin mono-thread : ce cœur peut être à fond pendant que la moyenne affichée reste basse. Le correctif est un CPU à fréquence plus élevée, pas un CPU avec plus de cœurs.

Quels réglages de `PalWorldSettings.ini` allègent la charge serveur ?

Quatre principalement : ServerPlayerMaxNum fixé à un effectif réaliste, BaseCampMaxNumInGuild réduit (chaque base est simulée en continu, même sans joueur), GuildPlayerMaxNum limité, et bEnableInvaderEnemy désactivé si vous constatez des pics de lag périodiques liés aux raids.

Un SSD change-t-il vraiment quelque chose pour un serveur Palworld ?

Oui, et pas seulement pour la vitesse. La documentation officielle indique qu’un stockage peu performant peut corrompre les données sauvegardées, et recommande un SSD rapide — c’est aussi le motif pour lequel elle déprécie Docker Desktop. Un SSD NVMe est indispensable pour le dossier Pal/Saved/.

En résumé

Gotcha 1.0 : la doc officielle indique que ne pas mettre -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS peut améliorer les performances. Testez les deux configurations.
Fréquence CPU > nombre de cœurs : 4 cœurs et plus recommandés officiellement, mais la simulation dépend surtout du mono-thread.
16 Go de RAM recommandés par Pocketpair ; 8 Go démarre mais expose au crash par out of memory.
SSD NVMe : un stockage lent peut corrompre les sauvegardes selon la documentation officielle.
Leviers de config : BaseCampMaxNumInGuild, GuildPlayerMaxNum, ServerPlayerMaxNum réaliste, bEnableInvaderEnemy.
Redémarrage quotidien avec /Broadcast + /Save + /Shutdown.
Lag serveur = tout le monde en même temps. FPS bas chez une seule personne = problème client.

Pour un hébergeur Palworld sur AMD Ryzen 9 5950X et SSD NVMe, HebergTonServ propose l’offre Starter à 11,90 €/mois (8 Go, recommandée pour 8 joueurs) et l’offre Pro à 19,90 €/mois (16 Go, jusqu’à 32 joueurs), avec anti-DDoS Pletx 5 Tb/s et garantie remboursement 24 h.

Optimiser les performances d'un serveur Palworld (le gotcha de la 1.0)

Sommaire

Tags populaires

Support Technique