A propriedade max-tick-time em server.properties define quantos milissegundos um único tick pode levar antes de o watchdog considerar o servidor travado e encerrar o processo. Paper documenta que, quando o limite é excedido, o watchdog pode forçar o término com System.exit(1). O valor padrão atual listado é 60.000 ms, e -1 desativa completamente o watchdog.
Um tick normal deve caber em aproximadamente 50 ms para atingir 20 ticks por segundo. Um tick acima do limite configurado por um longo período costuma indicar bloqueio grave, deadlock, chamada síncrona lenta ou operação de plugin que não retorna. O watchdog existe para detectar esse estado; desligá-lo pode deixar processo travado consumindo recursos sem oferecer jogo.
Leia a mensagem antes de mudar a propriedade
Quando o watchdog dispara, preserve o stack trace completo e os logs anteriores. A mensagem costuma listar threads e métodos ativos, dando uma pista do trabalho que impediu o tick de concluir. Copie latest.log, crash reports e a saída do painel. Reinícios repetidos podem sobrescrever evidências e tornar a causa mais difícil de encontrar.
Observe se o incidente acontece em horário, mundo ou ação específicos: explosões, teleporte, geração de chunks, autosave, carregamento de plugin, evento ou comando. Registre versão de Java, Paper, plugins, argumentos de inicialização, quantidade de jogadores e o estado de CPU, disco e memória no momento. Isso diferencia o sintoma de causas comuns.
Se o servidor fecha sem stack útil, veja se o processo Java realmente encerrou ou se o painel o matou por timeout. Compare o horário do watchdog com logs do sistema e do provedor. Um desligamento externo e um watchdog podem exigir correções diferentes.
Use spark durante a ocorrência
Para lentidão que pode ser reproduzida, o Paper recomenda spark como profiler atual. O perfil precisa ser coletado enquanto o problema ocorre; uma captura depois de o pico passar não mostrará o método responsável. Inicie perfil com timeout adequado à duração do incidente e guarde o link privado gerado para análise.
Procure a thread principal, método que ocupa o tempo de tick e chamadas a plugins ou IO. Se um plugin domina, atualize ou reporte com passos e versão exatos. Se a pilha aponta geração de chunks, compare exploração nova, armazenamento e pré-geração. Se aponta serialização ou salvamento, investigue autosave e o disco, sem desativar durabilidade às cegas.
Evite publicar links de perfis com informação identificável sem revisar permissões. Eles podem revelar nomes de plugins, estrutura e atividade. Remova dados privados quando compartilhar no suporte e nunca inclua segredos de forwarding ou credenciais de banco.
Não confunda watchdog com TPS baixo
TPS baixo é uma degradação sustentada da frequência de ticks, mas o servidor ainda responde. Watchdog é disparado quando um único tick excede um limite extremo e o servidor considera a instância travada. Aumentar max-tick-time pode mudar quando o encerramento acontece, mas não torna o tick rápido.
Se o servidor está lento mas não trava, use métricas de MSPT e profiling. Se um tick preso ultrapassa o watchdog, encontre o trabalho bloqueante. Alterar limite sem evidência apenas prolonga a espera até a mesma falha ou desativa um controle de encerramento.
Um plugin que faz chamada de rede síncrona pode prender a thread principal esperando um serviço externo. Um carregamento de chunk pode esperar disco. Código de geração pode fazer trabalho excessivo. Identifique a pilha e corrija o ponto que impede o tick de retornar.
Analise CPU, disco, heap e dependências
Confirme se a CPU está saturada ou se o processo está bloqueado à espera de IO. Um disco cheio, volume congestionado, snapshot ou banco lento pode prolongar operações. Heap quase cheio ou coleta de lixo longa pode causar pausas; examine GC logs e configurações de memória. Cada cenário deve ser observado com ferramentas do host ou do painel.
Revise mudanças recentes: atualização de plugin, Java, Paper, configuração de mundo, novos datapacks, geração de mapa ou aumento de população. Em staging, reverta uma mudança por vez e tente reproduzir. Não remova plugins de produção enquanto eles podem ter dados ou tarefas de desligamento importantes; faça cópia e teste isolado.
Se a falha começou após atualizar Paper, leia mudanças e requisitos oficiais e compare build. Não assuma que o watchdog está errado. Uma alteração de código pode fazer um caminho que antes era raro ocorrer com mais frequência, mas stack trace e reprodução ainda são a evidência central.
Quando ajustar o limite é razoável
Há cenários de operação em que o provedor ou um procedimento específico recomenda outro limite temporário. Antes de mudar, entenda a causa e defina o que o servidor deve fazer se voltar a travar. Se desativar o watchdog, tenha monitor externo, política de encerramento, captura de threads e responsável de plantão. Uma configuração que deixa um processo preso sem recuperação pode consumir recursos e bloquear a comunidade indefinidamente.
Não use -1 como solução padrão, e não aumente o valor para encobrir plugin lento. Se uma atualização legítima e controlada precisa de uma janela maior, faça em ambiente de teste, registre o motivo e reverta quando a operação terminar. Confirme compatibilidade com a versão instalada.
Uma recuperação melhor geralmente envolve corrigir o método bloqueante, atualizar componente incompatível, ampliar ou substituir recurso saturado, reduzir trabalho síncrono ou preparar uma restauração. O limite deve ser parte da política de falha, não um substituto para correção.
Faça backup e teste rollback
Antes de alterar arquivos ou atualizar plugins, desligue corretamente e gere backup completo dos mundos, dimensões, configurações e bancos relacionados. Preserve logs e a configuração atual. Teste a mudança em cópia isolada, usando o mesmo tipo de mundo e dependências, e confirme comportamento sob carga.
Defina critérios de sucesso: ausência de watchdog durante cenário reproduzível, MSPT estável, persistência de dados e logs limpos. Se a mudança apenas posterga a falha, reverta. Quando promover, monitore a próxima atividade de pico e tenha pessoa autorizada para restaurar configuração ou voltar versão.
Um watchdog configurado para proteger o serviço deve trabalhar junto de backup, profiling e procedimento de incidente. Preserve evidências e corrija a causa raiz antes de retomar o servidor para toda a comunidade.
Fontes e referências
Documentação consultada em 2026-10-08. Os exemplos precisam ser conferidos na versão instalada; este guia não afirma que a configuração foi testada no seu ambiente.