Como diagnosticar lag no Minecraft com TPS, MSPT e spark

O que TPS e MSPT mostram?

TPS é a quantidade de atualizações do jogo processadas por segundo. Na operação normal de 20 ticks por segundo, cada tick dispõe de aproximadamente 50 milissegundos. MSPT mede o tempo necessário para processar um tick. Quando esse tempo supera repetidamente o orçamento, o servidor pode deixar de manter a cadência esperada.

Um valor médio saudável não exclui travadas breves. Observe também os picos e a distribuição do tempo. A explicação oficial do spark sobre TPS e MSPT mostra como interpretar essas medidas. Elas descrevem a execução do servidor; não equivalem aos FPS do computador nem ao tempo de resposta da conexão.

Registre um cenário que possa ser comparado

Anote horário e fuso, número de jogadores, versão, software e o que acontecia: exploração, evento, carregamento de uma área ou uso de um comando. Pergunte se vários jogadores sentiram o mesmo efeito ao mesmo tempo. Compare relatos de conexões diferentes sem concluir, apenas pelo relato, que existe um problema específico de rede.

Guarde trechos do console próximos ao horário e a lista de alterações recentes. Essa referência permite avaliar uma hipótese sem mudar tudo simultaneamente. Se o problema surgiu após instalar uma extensão, registre qual versão entrou e preserve uma cópia anterior para um teste controlado.

Capture o perfil durante a lentidão

O Paper inclui spark a partir da versão 1.21. A documentação oficial de profiling do Paper recomenda capturar enquanto o problema ocorre; um perfil de um servidor vazio dificilmente explica uma travada durante um evento.

Em uma conta administrativa autorizada, use o comando abaixo no jogo para uma captura com duração definida. No console do servidor, normalmente se omite a barra inicial.

/spark profiler start --timeout 600

Após dez minutos, abra o endereço de relatório apresentado. Guarde junto dele o horário e a atividade observada. Os comandos do spark também permitem verificar uma captura em andamento e encerrá-la. Evite iniciar várias medições simultâneas sem saber qual já está ativa.

Quando o problema é uma travada isolada

A média de uma captura longa pode esconder poucos ticks lentos. O guia de picos de lag do spark descreve o monitoramento por duração e a filtragem de ticks. Por exemplo, o comando abaixo acompanha ocorrências acima de 50 milissegundos:

/spark tickmonitor --threshold-tick 50

Relacione os avisos à ação observada. Esse limiar é uma referência para investigação, não uma prova automática de falha. Se precisar filtrar a captura, ajuste --only-ticks-over conforme a duração dos picos e a ajuda da versão instalada.

Leia o relatório antes de escolher a correção

No visualizador, examine a thread principal e expanda as tarefas que concentram tempo. Um nó com 100% no topo significa o total daquela thread, não necessariamente que toda a máquina esteja com CPU esgotada. A documentação do visualizador explica os percentuais e como navegar pelas chamadas.

Use o resultado para formular uma hipótese: processamento de entidades, geração de terreno, uma tarefa de plugin ou outra atividade identificada. Uma chamada aparecer no relatório não prova que há defeito nela. Considere a frequência, o contexto e o trabalho esperado.

1. Escolha uma hipótese apoiada na captura.
2. Prepare um backup e um ambiente de teste quando a mudança afetar arquivos ou mundo.
3. Altere um fator e repita uma sessão comparável.
4. Compare duração dos ticks, sintomas e efeitos na jogabilidade.

Ao pedir ajuda, envie versão, descrição do cenário, horários e relatório relevante. Revise os dados compartilhados. Para avaliar memória, consulte o guia de dimensionamento de RAM.

Perguntas frequentes sobre lag