Dernière vérification : 25 septembre 2026 avec Palworld v1.0.5 et la documentation serveur de Pocketpair en version v1.0.4. Les mesures de l'époque de l'accès anticipé ne sont pas transposables telles quelles : la 1.0 (10.07.2026) a apporté des optimisations des serveurs dédiés avec beaucoup de joueurs, auxquelles se sont ajoutées les versions 1.0.2 à 1.0.5.
Bien lire les exigences officielles
Pour un serveur dédié Palworld, Pocketpair indique 16 Go de RAM, au moins quatre cœurs CPU recommandés et un SSD rapide. Ces indications sont une recommandation de l'éditeur, mais pas un tableau de joueurs par Go. Elles ne signifient pas qu'une quantité de RAM donnée garantit automatiquement un certain nombre de joueurs.
Tu trouveras la source actuelle de l'éditeur dans les exigences officielles du serveur Palworld. Pocketpair y avertit aussi qu'un stockage lent peut corrompre les données de sauvegarde. Planifie donc ensemble la RAM, le CPU et le stockage.
Ce que nous avons mesuré sur nos serveurs
Sur nos serveurs clients en service avec jusqu'à 4 joueurs actifs simultanément, les besoins en RAM sont restés sous 6 Go avec un redémarrage quotidien, sans arrêt dû à un manque de mémoire (mesure sur 14 jours, octobre 2026). Les pics se situaient entre 3,4 et 5,3 Go, quelle que soit l'offre réservée. Le CPU était en revanche le goulot d'étranglement : avec chaque joueur supplémentaire, la charge CPU augmentait nettement, et un serveur avec 4 joueurs a parfois tourné à la limite CPU. Pour des groupes plus importants, nous n'avons pas de mesures propres.
Si plus de joueurs doivent jouer en même temps, choisis une offre avec une limite CPU plus élevée ou réserve un cœur supplémentaire : +1 vCPU pour 2,99 € par mois, avec un maximum de 2 cœurs supplémentaires.
| Composant | Classification officielle | Conséquence pour ta planification |
|---|---|---|
| RAM | 16 Go de configuration requise | Indication de l'éditeur ; sur nos serveurs clients avec jusqu'à 4 joueurs, les besoins sont restés sous 6 Go |
| CPU | au moins quatre cœurs recommandés | détermine combien de joueurs peuvent jouer de façon fluide ; plus de joueurs nécessitent une limite CPU plus élevée |
| Stockage | SSD rapide recommandé | ne pas négliger les données de sauvegarde et les E/S |
Pourquoi le nombre de joueurs seul ne donne pas de formule de RAM
Deux mondes avec le même nombre de joueurs connectés peuvent générer une charge totalement différente. Un nouveau monde où un groupe voyage ensemble se comporte autrement qu'un monde ancien avec des bases dispersées, de nombreux Pals de travail, de grands complexes de bâtiments et un taux d'apparition augmenté. Les zones du monde actives en même temps, l'automatisation et les paramètres de serveur modifiés influencent aussi le travail que le serveur dédié doit accomplir.
Le nombre maximal de participants est donc une limite d'accès et non un indicateur direct de ressources. Une affirmation générale comme une quantité fixe de RAM par joueur ignore l'état du monde, la charge CPU et les accès mémoire. Utilise le nombre de joueurs comme valeur de contexte, mais ne décide d'une mise à niveau qu'avec des données de mesure reproductibles.
Construire une baseline de mesure exploitable
Définis d'abord une plage de charge typique. Cela peut être une soirée de communauté, un événement de boss ou une phase où plusieurs groupes travaillent en même temps sur différentes bases. Pendant cette plage, relève au minimum les joueurs connectés simultanément, l'utilisation de la RAM et du CPU, les FPS du serveur, le frame time, le nombre de bases et les événements de log remarquables. Tu lis les FPS du serveur et le frame time via l'API REST du serveur (RESTAPIEnabled=True dans PalWorldSettings.ini, puis GET /v1/api/metrics) : elle fournit serverfps, serverframetime, currentplayernum et uptime. Note aussi quels taux d'apparition et quels paramètres influant sur les performances étaient actifs.
Un pic isolé ne suffit pas comme preuve. Répète l'observation à des moments comparables et documente si la saturation est durable ou seulement brève. Note aussi la version du correctif : depuis la version 1.0, Palworld vérifie strictement la version, et un serveur non mis à jour rejette comme incompatibles les clients plus récents. Une mise à jour du jeu ou une nouvelle phase du monde peut en outre modifier la charge sans que le nombre de joueurs augmente. Cette référence rend possibles les comparaisons avant/après ultérieures.
Distinguer les goulots de RAM des autres causes
Avant d'augmenter la RAM, vérifie la durée de fonctionnement du processus : le serveur Palworld occupe plus de mémoire à chaque heure de fonctionnement, même après la version 1.0. Si la consommation de RAM augmente régulièrement à nombre de joueurs constant et retombe à sa valeur initiale après un redémarrage, un redémarrage planifié (avec sauvegarde préalable, à une heure calme de la journée) est la mesure adaptée, pas une mise à niveau.
Une mise à niveau de la RAM est plausible si le processus atteint à plusieurs reprises la limite disponible, si des événements OOM surviennent ou si le serveur tourne de façon reproductible plus stable avec de la mémoire supplémentaire sous une charge comparable. Une valeur d'occupation élevée ne prouve pas à elle seule un manque : le système d'exploitation et l'application peuvent utiliser la mémoire libre comme cache. Ce qui compte, ce sont la saturation, le tableau des erreurs et le comportement reproductible.
Vérifie en parallèle le CPU. Sur nos serveurs clients, il était plus souvent le goulot d'étranglement que la RAM. Si certains cœurs sont saturés en permanence alors qu'il reste de la réserve de RAM, davantage de mémoire ne résout pas le vrai goulot. Des FPS serveur en baisse ou un frame time en hausse peuvent être liés aussi bien au travail du CPU qu'à des états de monde complexes. Ne modifie donc pas en même temps la RAM, l'allocation CPU et le taux d'apparition ; sinon, la mesure efficace ne peut plus être identifiée.
Inclure le stockage et la sécurité des sauvegardes
Pocketpair recommande un stockage SSD rapide et signale un risque pour les données de sauvegarde en cas de stockage peu performant ; la page des exigences déconseille explicitement Docker Desktop, car il augmente le risque de sauvegardes endommagées. bIsUseBackupSaveData (activé par défaut) crée des sauvegardes tournantes dans le dossier de sauvegarde de partie, au prix d'une charge disque supplémentaire. Surveille donc les erreurs d'E/S, les opérations de sauvegarde anormalement longues et l'espace disque libre. Avant chaque test avec des mods, de plus grosses modifications de configuration ou des mises à jour du serveur, crée une sauvegarde vérifiable. Le guide Sauvegarder et restaurer un monde Palworld décrit la procédure adaptée.
Une sauvegarde n'est fiable que si tu sais où elle se trouve, quel état du monde elle contient et comment fonctionne la restauration. N'effectue pas de tests de charge risqués sur l'unique copie de ton monde de production. Tu évites ainsi qu'une enquête sur les performances entraîne elle-même une perte de données.
Tester les modifications de façon contrôlée
Avant la modification, établis un court plan de vérification : quel symptôme doit disparaître, quelle valeur mesurée doit s'améliorer et dans quelle plage de charge comparable la vérification aura-t-elle lieu ? Sauvegarde ensuite le monde et ne modifie qu'une seule variable. En cas de goulot de RAM supposé, il s'agit de la capacité mémoire ; en cas de goulot de CPU, d'une limite CPU plus élevée, par exemple via un cœur supplémentaire, ou d'un paramètre influant sur les performances.
Redémarre proprement le serveur après la modification et répète la fenêtre de charge documentée. Compare non pas seulement une valeur de pointe, mais la stabilité, les événements OOM, la RAM, le CPU, les FPS du serveur et le frame time. Si le problème reste identique, annule la modification ou étudie le prochain goulot justifié. Si le comportement s'améliore de façon reproductible, documente la nouvelle baseline et le déclencheur.
Pour les modifications de configuration, utilise le guide Configurer les paramètres du serveur Palworld. La liste officielle des arguments de Pocketpair explique notamment le port d'écoute, le nombre maximal de participants et les indications actuelles sur les arguments de performances. Ne reprends pas aveuglément des paramètres de démarrage issus d'anciens messages de la communauté, car pour la version 1.0 et les suivantes, le fabricant signale explicitement, pour certains anciens paramètres de multithreading, un meilleur comportement possible sans ces paramètres.
Contrôle de capacité après les mises à jour et la croissance du monde
Depuis la v1.0.3, bAllowEnemyCampSpawnNearBaseCamp=False limite les spawns de raids près des bases des joueurs, et depuis la v1.0.4, MaxBuildingLimitNum plafonne les éléments de construction par joueur ; ce sont deux interrupteurs influençant les performances. Le clustering de serveurs, annoncé en juin 2026, n'est pas livré jusqu'à la v1.0.5 ; la répartition de la charge sur plusieurs instances ne reste donc pas une option.
Une valeur mesurée une fois ne reste pas automatiquement correcte pour toujours. Répète le contrôle après les mises à jour majeures de Palworld, une forte croissance des bases, des taux d'apparition modifiés et une communauté nettement plus grande. Compare toujours avec la dernière référence stable. Tu sauras ainsi si les besoins en ressources ont réellement changé ou si un nouveau défaut est apparu indépendamment de la RAM et du CPU.
Utilise le même ordre pour chaque décision : vérifier la base minimale officielle, sauvegarder le monde, relever les mesures, classer le goulot, tester exactement une modification et documenter le résultat. Tu évites ainsi aussi bien les instances trop petites que les mises à niveau coûteuses qui ne résolvent pas un problème de CPU, de stockage ou de configuration.
FAQ
6 Go de RAM suffisent-ils pour un serveur Palworld ?
Sur nos serveurs clients en service avec jusqu'à 4 joueurs actifs simultanément, les besoins en RAM sont restés sous 6 Go avec un redémarrage quotidien, sans arrêt dû à un manque de mémoire (mesure sur 14 jours, octobre 2026). Pocketpair indique 16 Go de RAM comme configuration requise. Pour des groupes plus importants, nous n'avons pas de mesures propres.
De combien de RAM ai-je besoin par joueur ?
Il n'existe pas de formule fixe fiable pour cela. Le nombre de joueurs, les bases, les Pals de travail, les constructions, le taux d'apparition, les paramètres et les zones du monde actives en même temps agissent ensemble sur la charge. Sur nos serveurs, c'est surtout la charge CPU qui augmentait avec chaque joueur, à peine la RAM. Décide d'une capacité supplémentaire à partir de mesures reproductibles.
Quand ai-je besoin de plus de RAM ou d'une limite CPU plus élevée ?
Plus de RAM aide lorsque la saturation de la RAM ou des événements OOM se produisent de façon reproductible sous une charge comparable. Si le CPU tourne en permanence à sa limite alors que de la RAM est libre, il te faut une limite CPU plus élevée, par exemple via un cœur supplémentaire.
Plus de RAM aide-t-il contre tous les types de lag ?
Non. La saturation du CPU, un stockage lent, la complexité du monde, des problèmes réseau et des paramètres inadaptés peuvent provoquer des symptômes similaires. Vérifie ensemble la RAM, le CPU, les FPS du serveur, le frame time, les logs et le stockage avant de déterminer une cause.
Que dois-je sauvegarder avant un test de performances ?
Crée une sauvegarde vérifiable du monde et documente la version du correctif ainsi que les paramètres. Ne modifie ensuite qu'une seule variable et répète une plage de charge comparable. Le résultat reste ainsi traçable et le monde de production restaurable.