O servidor de Palworld cai: como diagnosticar e corrigir

A versão curta

O Palworld tem um vazamento de memória de longa data na build do servidor dedicado. O uso de RAM sobe de forma constante enquanto o servidor estiver no ar, aproximadamente em proporção a quantos jogadores estão online e a quantos Pals existem no mundo, e nunca é liberado. Eventualmente o processo esgota a RAM que recebeu e o sistema operacional o encerra. De fora, isso parece uma queda aleatória, e é por isso que tanta gente culpa o host primeiro.

Operadores de servidor relatam o padrão de forma consistente: um mundo de quatro jogadores com cerca de 80 Pals costuma crescer de cerca de 3 GB para mais de 8 GB em quatro horas, e um servidor comunitário movimentado de 16 jogadores pode chegar a 12 GB em meia hora. Esses números variam com o seu mundo, mas o padrão não. Se suas quedas chegam em um horário mais ou menos regular, e não aleatoriamente, esse é o vazamento.

As duas falhas que não parecem um crash

Uma queda é o caso fácil: o processo morre, e quem o monitora percebe. As duas falhas que mais geram chamados de suporte confusos deixam o processo vivo e todas as verificações de saúde passando. Diagnosticamos as duas a partir de 22 horas de amostras de um minuto de um servidor de 16 GB de um cliente, e elas são assim:

Nenhum dos dois é o vazamento de memória. A falha de descarregamento do mundo aconteceu três vezes em duas horas em um servidor que usava menos de 2.3GB, então não é o vazamento nem o limite de RAM. O que os torna caros é que a verificação de saúde habitual, se o processo do jogo está rodando, passa nos dois estados, então nada reinicia o servidor e ele pode ficar morto por horas enquanto você dorme.

Confirme que é memória antes de mudar qualquer coisa

Abra o gráfico de recursos no seu painel e acompanhe a RAM durante uma sessão. O vazamento de memória tem uma assinatura difícil de confundir:

• A RAM sobe em linha quase reta desde o momento em que o servidor inicia e nunca volta a cair depois que os jogadores saem.
• O travamento acontece quando essa linha atinge o teto do seu plano, e não em um evento específico do jogo.
• Não há uma mensagem de erro útil. O processo simplesmente desaparece, porque o sistema operacional o encerrou em vez de o jogo decidir sair.
• Reiniciar o servidor resolve por completo, por mais algumas horas.

Se, em vez disso, seu servidor morre sempre no mesmo momento, ou falha em segundos após iniciar, vá para a última seção. Esses são problemas diferentes, com soluções diferentes.

Correção 1: reinicie em um cronograma

Esta é a resposta sem brilho, e também a que funciona. Como o vazamento é linear e um reinício limpa tudo, um reinício agendado reseta o relógio antes de o limite ser atingido. Operadores experientes costumam reiniciar a cada três a seis horas em um servidor público movimentado, e uma ou duas vezes por dia em um servidor privado pequeno.

Um reinício do Palworld leva cerca de um minuto, e o mundo é salvo antes, então o custo para os jogadores é pequeno. Escolha um horário em que seu grupo costuma estar offline, avise no Discord, e o problema deixa de ser um problema. Na Flux você pode reiniciar pelo painel com um clique, e como o reinício também pega qualquer atualização pendente do jogo, ele serve como sua rotina de patches.

Uma armadilha que vale conhecer se você hospeda por conta própria ou usa outro provedor: o script de reinício agendado na imagem padrão do servidor de Palworld pede ao servidor que salve primeiro e se recusa a desligar se essa gravação falhar. Em um servidor que está vazando, travado ou sem mundo, que é justamente o único tipo de servidor para o qual o reinício noturno existe, o salvamento é exatamente o que falha. Assim, o reinício não faz nada silenciosamente nas noites em que era necessário, e os logs mostram que ele rodou. Verifique se o seu realmente reiniciou em vez de presumir que sim.

Correção 2: desative os invasores de Pal

Raids geram ondas de Pals hostis que o servidor mantém na memória muito depois de a raid acabar. Desligá-las é a forma mais próxima que o Palworld tem de uma solução alternativa aceita pela comunidade para o vazamento, e operadores relatam de forma consistente que a RAM sobe a cerca de metade da velocidade anterior depois disso.

No PalWorldSettings.ini, defina bEnableInvaderEnemy=False e reinicie. Você perde as raids nas bases, que alguns grupos vão sentir falta e muitos não vão, e em troca praticamente dobra o tempo entre os reinícios. Edite o arquivo pelo editor de configuração do painel; não é preciso abrir um terminal.

Correção 3: limite o que cresce

O vazamento escala com quanto mundo há para manter na memória, então limitar quanto os jogadores podem criar o torna mais lento. Duas configurações fazem a maior parte do trabalho:

Uma guilda que deixou 50 Pals trabalhando em cada uma de várias bases está mantendo uma grande quantidade de simulação persistente na RAM, e cada um desses Pals contribui para o vazamento. Limitar o número de trabalhadores não é só uma correção de memória: é a maior alavanca sobre a carga de CPU do servidor no Palworld, então geralmente também melhora o lag.

Correção 4: dê folga de recursos

Nada disso impede o vazamento, apenas o retarda. A variável restante é quanto espaço o servidor tem antes de atingir o teto, e isso é o tamanho do seu plano. Se você roda 16 jogadores em 8 GB, está pedindo para o vazamento te derrubar em menos de uma hora, não importa quão bem você configure o mundo.

Esses níveis já pressupõem um servidor com vazamento, e não um servidor ocioso teórico. Se você está caindo no nível correspondente ao seu número de jogadores, a causa costuma ser um mundo muito carregado, e as duas configurações acima vão ajudar mais do que o plano seguinte. Se você está um nível abaixo do seu número de jogadores, suba. Escalar a RAM na Flux não mexe no save do seu mundo.

Como manter um servidor de Palworld online 24/7

Tudo o que está acima torna as falhas mais lentas. Nada disso faz um servidor que já falhou voltar, e essa é a diferença entre um servidor que está no ar a maior parte do tempo e um que está no ar o tempo todo. Alguém precisa perceber e agir enquanto você dorme.

É essa lacuna que a nossa imagem de servidor de Palworld fecha, e é por isso que construímos a nossa em vez de usar a padrão. Ela verifica o servidor a cada minuto, de dentro do contêiner, nas coisas que um jogador realmente perceberia: se o socket de rede está escoando, se a API de administração responde, se o mundo está carregado e em tick, e se o arquivo de save ainda está no disco. Se a resposta for não, ela reinicia o servidor. Não há nada para ativar e nenhuma configuração para encontrar.

A contenção importa tanto quanto o gatilho, porque um monitor que reinicia servidores saudáveis é pior do que nenhum:

• Ele precisa do mesmo veredicto três vezes seguidas, com um minuto de intervalo, antes de agir: uma única amostra ruim não é uma falha.
• Ele nunca age sobre um servidor que ainda não viu funcionando, e nunca nos primeiros minutos depois do boot. Carregar um mundo grande leva tempo, e um loop de reinícios não ajuda um servidor que subiu quebrado.
• Ele anuncia o reinício no jogo e faz uma contagem regressiva de 60 segundos, com lembretes em 30 e 10 segundos, depois faz uma última amostragem. Um servidor que se recuperou durante a contagem é deixado em paz, e a contagem é cancelada com aviso no jogo.
• Ele nunca salva. Em todos os estados que chegam até aqui, o mundo na memória já está perdido ou congelado, e pedir a um servidor quebrado que salve arrisca gravar esse vazio por cima do seu último save bom. O que um reinício custa são os minutos desde o último salvamento automático, que já foram perdidos quando a falha aconteceu.

O reinício noturno desta imagem também foi corrigido. Ele avisa os jogadores, salva apenas se o mundo ainda estiver carregado e realmente rodando, pede ao servidor para desligar e, depois, para de pedir: após um período de carência, encerra o processo, e um servidor novo volta em segundos. Nunca pula silenciosamente.

Uma coisa que vale a pena fazer por conta própria: defina uma senha de administrador na aba Configurações do Servidor. As verificações de socket e de arquivo de save funcionam de qualquer forma, mas as verificações que detectam um mundo descarregado conversam com a API de administração do servidor, e um servidor sem senha recusa essas chamadas. Nunca tratamos uma chamada recusada como servidor morto, de propósito, porque isso reiniciaria mundos saudáveis a cada poucos minutos, então o efeito de deixar em branco é uma proteção mais silenciosa, e não mais barulhenta.

Quando não é o vazamento de memória

Ele trava segundos depois de iniciar, logo após uma atualização do jogo

A Pocketpair lança as atualizações de cliente e servidor juntas, e um servidor que ainda esteja na build anterior vai recusar conexões ou cair assim que um cliente atualizado entrar. Atualize o servidor assim que o patch do cliente sair, em vez de esperar um relato dos seus jogadores. Na Flux, um reinício puxa a imagem atual, então isso é um clique.

Ele trava sempre no mesmo ponto

Uma queda que se reproduz exatamente, por exemplo sempre que um jogador específico entra ou sempre que o mundo chega a uma área específica, aponta para um save corrompido, e não para a memória. Restaure o backup mais recente feito antes de o comportamento começar. Mantenha backups agendados justamente por isso: um save que você não consegue reverter é um save que você pode perder.

Ele nunca inicia

Se o servidor nunca subiu, é um problema de configuração ou de porta, e não uma queda. Confira se a UDP 8211 é a porta que seus jogadores estão discando e se o PalWorldSettings.ini é válido, pois uma única linha malformada impede que o arquivo seja lido. O guia de configuração explica os dois.

Uma lista de verificação que você pode seguir

1. Descubra qual falha você tem. Uma subida reta da RAM até o teto é o vazamento. Online mas sem conseguir entrar é um travamento. Entrar mas sem mundo é um mundo descarregado. Cada um precisa de uma resposta diferente.
2. Defina bEnableInvaderEnemy=False no PalWorldSettings.ini e reinicie.
3. Limite BaseCampWorkerMaxNum para algo sensato para o seu grupo e limite BaseCampMaxNum ao número de jogadores.
4. Agende um reinício a cada três a seis horas em um servidor movimentado, ou diariamente em um servidor privado.
5. Confirme se a RAM do seu plano corresponde ao número de jogadores e suba um nível se não corresponder.
6. Mantenha os backups automáticos ativados, para que um save corrompido seja um incômodo e não o fim do mundo.
7. Defina uma senha de admin, para que as verificações que detectam um mundo descarregado possam acessar seu servidor.
8. Garanta que algo reinicie o servidor quando ele parar de responder, e não apenas quando morrer. Na Flux, isso já está incluído na imagem do servidor.

Siga nessa ordem e a grande maioria dos relatos de queda do Palworld deixa de acontecer. O que sobra é uma limitação do motor do jogo que ninguém consegue corrigir por você, então a questão deixa de ser como evitar toda falha e passa a ser com que rapidez o servidor volta depois de uma.