Le serveur Palworld plante sans cesse : comment le diagnostiquer et le réparer

En bref

La version serveur dédiée de Palworld souffre d'une fuite mémoire de longue date. L'utilisation de la RAM grimpe régulièrement tant que le serveur est allumé, à peu près proportionnellement au nombre de joueurs connectés et de Pals présents dans le monde, et elle n'est jamais libérée. Finalement, le processus épuise la RAM qui lui a été allouée et le système d'exploitation le tue. De l'extérieur, cela ressemble à un plantage aléatoire, c'est pourquoi tant de personnes accusent d'abord leur hébergeur.

Les opérateurs de serveurs décrivent ce phénomène de façon constante : un monde à quatre joueurs avec environ 80 Pals passe généralement d'environ 3 GB à plus de 8 GB en quatre heures, et un serveur communautaire chargé de 16 joueurs peut atteindre 12 GB en une demi-heure. Ces chiffres varient selon votre monde, mais le schéma, lui, ne varie pas. Si vos plantages surviennent selon un rythme approximatif plutôt qu'au hasard, c'est la fuite.

Les deux pannes qui ne ressemblent pas à un crash

Un plantage est le cas facile : le processus meurt, et tout ce qui le surveille s'en aperçoit. Les deux pannes qui génèrent le plus de tickets d'assistance confus laissent le processus en vie et toutes les vérifications de santé au vert. Nous avons diagnostiqué les deux à partir de 22 heures d'échantillons d'une minute sur le serveur 16GB d'un client, et voici à quoi elles ressemblent :

Ni l'un ni l'autre n'est la fuite mémoire. La panne de déchargement du monde s'est produite trois fois en deux heures sur un serveur utilisant moins de 2.3GB, donc ce n'est ni la fuite ni la limite de RAM. Ce qui les rend coûteuses, c'est que le contrôle de santé habituel, à savoir si le processus de jeu tourne, réussit dans les deux cas. Rien ne redémarre donc le serveur, qui peut rester bloqué pendant des heures pendant que vous dormez.

Vérifiez que le problème vient de la mémoire avant de modifier quoi que ce soit

Ouvrez le graphique des ressources dans votre tableau de bord et suivez la RAM pendant une session. La fuite mémoire a une signature difficile à confondre :

• La RAM grimpe presque en ligne droite dès le démarrage du serveur et ne redescend jamais après le départ des joueurs.
• Le plantage survient lorsque cette ligne atteint le plafond de votre offre, et non lors d'un événement particulier dans le jeu.
• Il n'y a aucun message de plantage utile. Le processus disparaît simplement, car le système d'exploitation l'a tué plutôt que le jeu ne décide de quitter.
• Redémarrer le serveur le répare complètement, pour quelques heures encore.

Si au contraire votre serveur meurt à chaque fois au même moment, ou tombe quelques secondes après son démarrage, allez directement à la dernière section. Ce sont des problèmes différents, avec des solutions différentes.

Correctif 1 : redémarrer selon un planning

C'est la réponse peu glamour, et aussi la plus efficace. Comme la fuite est linéaire et qu'un redémarrage l'efface entièrement, un redémarrage planifié remet l'horloge à zéro avant que le plafond ne soit atteint. Les opérateurs expérimentés redémarrent en général toutes les trois à six heures sur un serveur public très fréquenté, et une à deux fois par jour sur un petit serveur privé.

Un redémarrage de Palworld prend environ une minute et le monde est sauvegardé au préalable, donc le coût pour les joueurs est faible. Choisissez un créneau où votre groupe est généralement hors ligne, annoncez-le sur Discord, et le problème n'en est plus un. Sur Flux, vous pouvez redémarrer depuis le tableau de bord en un clic, et comme un redémarrage prend aussi en compte toute mise à jour du jeu en attente, il fait office de routine de patch.

Un piège à connaître si vous auto-hébergez ou utilisez un autre hébergeur : le script de redémarrage planifié de l'image standard du serveur Palworld demande au serveur de sauvegarder d'abord, et refuse de s'arrêter si cette sauvegarde échoue. Sur un serveur qui fuit, est figé ou sans monde, c'est-à-dire le seul type de serveur pour lequel un redémarrage nocturne existe, la sauvegarde est justement ce qui échoue. Le redémarrage ne fait donc rien, en silence, précisément les nuits où il était nécessaire, et les journaux l'indiquent comme exécuté. Vérifiez que le vôtre a réellement redémarré au lieu de le supposer.

Correctif 2 : désactiver les envahisseurs Pal

Les raids font apparaître des vagues de Pals hostiles que le serveur garde en mémoire bien après la fin du raid. Les désactiver est ce qui se rapproche le plus d'un contournement consensuel de la communauté pour la fuite, et les opérateurs constatent systématiquement que la RAM grimpe alors à peu près deux fois moins vite.

Dans PalWorldSettings.ini, réglez bEnableInvaderEnemy=False et redémarrez. Vous perdez les raids sur les bases, que certains groupes regretteront et que beaucoup ne remarqueront pas, et en échange vous doublez à peu près le temps entre deux redémarrages. Modifiez le fichier depuis l'éditeur de configuration du tableau de bord ; pas besoin d'ouvrir un terminal.

Correctif 3 : limiter ce qui grandit

La fuite augmente avec la quantité de monde à garder en mémoire : limiter ce que vos joueurs peuvent créer la ralentit donc. Deux paramètres font l'essentiel du travail :

Une guilde qui a garé 50 Pals au travail dans chacune de plusieurs bases détient une grande quantité de simulation persistante en RAM, et chacun de ces Pals contribue à la fuite. Limiter le nombre de travailleurs n'est pas seulement un correctif de mémoire : c'est le levier le plus important sur la charge CPU du serveur dans Palworld, donc cela améliore généralement aussi le lag en même temps.

Correctif 4 : prévoyez de la marge

Rien de ce qui précède n'arrête la fuite, cela ne fait que la ralentir. La variable restante est la marge de mémoire dont dispose le serveur avant d'atteindre le plafond, et c'est la taille de votre offre. Si vous faites tourner 16 joueurs sur 8GB, vous demandez à la fuite de vous tuer en moins d'une heure, quelle que soit la qualité de votre configuration du monde.

Ces paliers supposent déjà un serveur qui fuit, et non un serveur inactif en théorie. Si votre serveur plante sur le palier correspondant à votre nombre de joueurs, la cause habituelle est un monde très chargé, et les deux paramètres ci-dessus vous apporteront plus que l'offre supérieure. Si vous êtes à un palier en dessous de votre nombre de joueurs, passez au palier supérieur. Augmenter la RAM sur Flux ne touche pas à la sauvegarde de votre monde.

Comment garder un serveur Palworld en ligne 24/7

Tout ce qui précède ralentit les pannes. Rien de cela ne fait revenir un serveur déjà défaillant, et c'est là la différence entre un serveur disponible la plupart du temps et un serveur disponible tout le temps. Quelque chose doit détecter le problème et agir pendant que vous dormez.

C'est le manque que comble notre image de serveur Palworld, et c'est pourquoi nous en construisons une plutôt que d'utiliser la version standard. Elle vérifie le serveur chaque minute, depuis l'intérieur du conteneur, sur ce qu'un joueur remarquerait réellement : si le socket réseau se vide, si l'API d'administration répond, si le monde est chargé et tourne, et si le fichier de sauvegarde est toujours présent sur le disque. Si la réponse est non, elle redémarre le serveur. Il n'y a rien à activer et aucun paramètre à trouver.

La retenue compte autant que le déclencheur, car un moniteur qui redémarre des serveurs en bonne santé est pire que l'absence de moniteur :

• Il faut le même verdict trois fois de suite, à une minute d'intervalle, avant d'agir : un mauvais échantillon ne constitue pas une panne.
• Il n'intervient jamais sur un serveur qu'il n'a pas encore vu fonctionner, ni pendant les premières minutes après le démarrage. Le chargement d'un grand monde prend du temps, et une boucle de redémarrage n'aide pas un serveur qui a démarré en panne.
• Il annonce le redémarrage en jeu et compte à rebours 60 secondes, avec des rappels à 30 et 10 secondes, puis prend un dernier échantillon. Un serveur qui s'est rétabli pendant le compte à rebours est laissé tranquille, et le compte à rebours est annulé à voix haute.
• Il ne sauvegarde jamais. Dans tous les états qui parviennent jusque-là, le monde en mémoire est déjà perdu ou figé, et demander à un serveur défaillant de sauvegarder risque d'écrire ce vide par-dessus votre dernière bonne sauvegarde. Un redémarrage vous coûte les minutes écoulées depuis la dernière sauvegarde automatique, qui étaient déjà perdues au moment de la panne.

Le redémarrage quotidien de cette image est lui aussi corrigé. Il prévient vos joueurs, ne sauvegarde que si le monde est toujours chargé et effectivement actif, demande au serveur de s'arrêter, puis cesse de demander : après un délai de grâce, il met fin au processus, et un serveur neuf est opérationnel quelques secondes plus tard. Il ne saute jamais une étape en silence.

Une chose qui vaut la peine de faire vous-même : définissez un mot de passe administrateur dans l'onglet Paramètres du serveur. Les vérifications du socket et du fichier de sauvegarde fonctionnent dans tous les cas, mais celles qui détectent un monde déchargé interrogent l'API d'administration du serveur, et un serveur sans mot de passe refuse ces appels. Nous ne traitons volontairement jamais un appel rejeté comme un serveur mort, car cela redémarrerait des mondes sains toutes les quelques minutes. Laisser ce champ vide offre donc une protection plus discrète, pas plus bruyante.

Quand ce n'est pas la fuite mémoire

Il plante quelques secondes après le démarrage, juste après une mise à jour du jeu

Pocketpair publie les mises à jour client et serveur ensemble, et un serveur resté sur la version précédente refusera les connexions ou plantera dès qu'un client mis à jour rejoint. Mettez le serveur à jour dès que le correctif client sort, sans attendre qu'un joueur le signale. Sur Flux, un redémarrage récupère l'image actuelle, c'est donc un seul clic.

Il plante au même endroit à chaque fois

Un plantage qui se reproduit à l'identique, par exemple à chaque connexion d'un joueur précis ou à chaque fois que le monde atteint une zone particulière, indique une sauvegarde corrompue plutôt qu'un problème de mémoire. Restaurez la sauvegarde la plus récente prise avant l'apparition du comportement. Gardez des sauvegardes planifiées pour cette raison précise : une sauvegarde dont vous ne pouvez pas revenir en arrière est une sauvegarde que vous pouvez perdre.

Il ne démarre jamais du tout

Si le serveur n'a jamais démarré, il s'agit d'un problème de configuration ou de port, et non d'un plantage. Vérifiez que UDP 8211 est bien le port que vos joueurs composent et que PalWorldSettings.ini est valide, car une seule ligne mal formée empêchera la lecture du fichier. Le guide d'installation détaille les deux.

Une liste de contrôle à suivre

1. Identifiez la panne en cause. Une montée régulière de la RAM jusqu'au plafond est la fuite. En ligne mais impossible à rejoindre, c'est un blocage. Accessible mais sans monde, c'est un monde déchargé. Chacun appelle une réponse différente.
2. Définissez bEnableInvaderEnemy=False dans PalWorldSettings.ini, puis redémarrez.
3. Limitez BaseCampWorkerMaxNum à une valeur raisonnable pour votre groupe, et limitez BaseCampMaxNum à votre nombre de joueurs.
4. Planifiez un redémarrage toutes les trois à six heures sur un serveur très fréquenté, ou une fois par jour sur un serveur privé.
5. Vérifiez que la RAM de votre offre correspond à votre nombre de joueurs, et passez au palier supérieur si ce n'est pas le cas.
6. Gardez les sauvegardes automatiques activées : une sauvegarde corrompue sera un désagrément et non une catastrophe.
7. Définissez un mot de passe administrateur, afin que les vérifications qui détectent un monde non chargé puissent atteindre votre serveur.
8. Assurez-vous que quelque chose redémarre le serveur lorsqu'il cesse de répondre, pas seulement lorsqu'il plante. Sur Flux, cela est intégré à l'image du serveur.

Suivez cet ordre et la grande majorité des signalements de plantage de Palworld cessent. Ce qui reste est une limitation du moteur de jeu que personne ne peut corriger à votre place : la question n'est alors plus d'empêcher toute panne, mais de savoir à quelle vitesse le serveur revient après une panne.