As três mensagens de lag mais comuns no log do Minecraft não significam a mesma coisa: Can't keep up! Is the server overloaded? quer dizer que o teu servidor continua a correr, mas não consegue acompanhar. A single server tick took 60.00 seconds quer dizer que o travão de emergência integrado o encerrou à força. Exception in server tick loop quer dizer que um erro concreto de programa rebentou a sequência principal do jogo. Quem trata as três da mesma forma costuma reparar a coisa errada.
Distinguir as três mensagens
O Minecraft calcula o mundo do jogo 20 vezes por segundo. Cada uma dessas passagens chama-se tick e pode demorar no máximo 50 milissegundos. Todo o lag que sentes é um desvio deste único número.
| Mensagem de log | O que aconteceu de facto | O servidor ainda está a correr? |
|---|---|---|
Can't keep up! Is the server overloaded? Running 5074ms or 101 ticks behind |
Os ticks demoram mais de 50 ms, o servidor está a recuperar atraso | Sim, mas claramente lento |
A single server tick took 60.00 seconds + Considering it to be crashed |
Um único tick ultrapassou max-tick-time; o Watchdog encerrou o processo |
Não, encerrado à força |
Exception in server tick loop |
Um erro chegou até ao loop principal | Não, normalmente com crash report |
Dispatched async TPS command (aviso do Paper) |
A nossa própria medição de TPS consulta o servidor a partir de fora | Sim — isto é normal |
A última linha causa confusão com frequência: o Paper comunica qualquer consulta externa como aviso. É a nossa medição de desempenho planeada a cada cerca de cinco minutos, não é um erro nem uma intervenção no teu jogo.
O passo mais importante: em mensagens do Watchdog, lê para cima
O encerramento pelo Watchdog é um sintoma, não uma causa. Ele só diz: alguma coisa bloqueou a thread do servidor durante mais tempo do que o permitido. O que a bloqueou está noutro sítio.
Há dois casos, e eles levam a medidas completamente diferentes:
Caso 1 — o Watchdog veio primeiro. Antes da linha do Watchdog há funcionamento normal do jogo. Então o tempo de tick é realmente a mensagem: algo congelou o servidor enquanto ele estava em execução.
Caso 2 — o Watchdog veio depois. Antes da linha do Watchdog já aparece Stopping server ou Preparing crash report. Então o servidor já estava morto ou a desligar, e o Watchdog apenas limpou um encerramento preso.
Este segundo caso não é raro. Num caso de suporte de 22 de agosto de 2026, a thread do servidor crashou às 13:20:15, iniciou um Stopping server limpo — e só 60 segundos depois o Watchdog disparou. Quem aí declara a duração do tick como causa envia o operador para longe da mensagem de erro real, que estava um minuto mais acima. É exatamente por isso que a nossa análise da consola avalia o acerto do Watchdog deliberadamente em último lugar: se houver uma assinatura mais específica no mesmo trecho do log, vês essa afirmação e não “um tick foi lento”.
Passo a passo até à causa
1. Verificar o histórico de TPS no painel
Abre o teu servidor no painel. Em “Performance (últimas 24h)” vês o histórico de TPS; a medição é feita aproximadamente a cada cinco minutos enquanto o servidor está a correr. O formato da curva já diz muito:
- Uma queda brusca numa hora específica → um evento. Compara a hora com o log: geração de mundo, um backup, um jogador em terreno inexplorado, uma tarefa de plugin.
- Valores permanentemente baixos → sobrecarga estrutural. Aqui um reinício não resolve, é preciso aliviar carga.
- Padrão em serra → típico de pressão de memória: o servidor trabalha, a garbage collection interrompe, e isto repete-se.
Se os valores ficarem baixos durante uma janela mais longa, o painel avisa automaticamente com a indicação “TPS permanentemente baixo”.
2. Medir MSPT — só TPS não chega
Introduz /spark tps na consola. O comando fornece dois números, e o segundo é o mais importante:
- TPS — ticks por segundo, máximo 20.
- MSPT — milissegundos por tick. Tudo até 50 ms é saudável.
Porquê MSPT? Bukkit, Spigot e Paper desaceleram processos do servidor para evitar um crash. Por isso, o indicador pode mostrar 20 TPS lisos enquanto o servidor, na prática, já está no limite. Um valor MSPT de 45 ms significa: estás a uma mob farm de começar a ter lag visível — mesmo que o indicador de TPS ainda pareça perfeito.
No Paper a partir da versão 1.21, o spark já vem incluído; não precisas de instalar nada.
3. Fazer profiling do causador
Não adivinhes qual plugin é culpado — mede:
/spark profiler start --timeout 120
Durante esses dois minutos, recria a situação que causa lag. Depois abre o link de resultado que o servidor apresenta. O relatório mostra, ordenado por percentagem de tempo, para onde vai o tempo de tick: uma mod específica, uma tarefa de plugin, carregamento de chunks, processamento de entidades ou a garbage collection.
Este é o ponto em que este guia se separa de “comprar mais RAM”. O profiler responde à pergunta que uma tabela de recomendações não consegue responder: O que exatamente consome tempo no teu servidor?
4. Aliviar carga de forma direcionada
O que o profiler mostra determina a medida:
| O profiler mostra | Medida eficaz |
|---|---|
| Carregamento de chunks, geração de mundo | Reduzir simulation-distance (default 10, mínimo 3) — tem mais efeito do que view-distance, porque só chunks simulados consomem tempo de CPU |
| Processamento de entidades | Limitar mob farms, prender animais em cercas em vez de os deixar soltos, limpar acumulações de itens |
| Redstone / ticks de blocos | Construir relógios de redstone com observers em vez de loops de repeaters, desligar mecanismos que correm sem parar |
| Um único plugin ou uma mod | Desativar para teste e medir de novo; procurar alternativa ou versão mais recente |
| Garbage Collection | Agora mais RAM é a resposta certa — antes não |
O último ponto é importante: RAM só resolve um problema de memória. Se um relógio de redstone está a consumir o tempo de tick, um plano maior não torna o servidor mais rápido. O nosso calculador de RAM para Minecraft calcula quanta memória combina com o teu número de jogadores e o tamanho do modpack.
5. max-tick-time — a exceção, não a solução
O valor fica em server.properties e define a partir de que duração de tick o Watchdog intervém. O padrão é 60000 milissegundos, ou seja, 60 segundos. Se o valor for ultrapassado, o servidor encerra-se a si próprio.
Muitos tutoriais na internet recomendam aqui desligar o Watchdog com -1. Não faças isso como solução padrão. O Watchdog é a única instância integrada que sequer deteta um deadlock real. Com -1, um servidor morto fica horas preso na porta: jogadores não conseguem entrar, nada no log explica porquê, e ninguém é alertado. Removeste o indicador, não o problema.
Há exatamente uma boa justificação para aumentar o valor: um processo conhecido demora legitimamente muito tempo. O caso clássico é o primeiro arranque de um grande modpack, em que a geração de mundo e a inicialização das mods passam juntas mais de um minuto num tick. Nesse caso, um valor como 180000 (três minutos) é aceitável — temporariamente, e com a intenção de o repor depois do primeiro arranque bem-sucedido.
Quando Exception in server tick loop aparece no log
Esta mensagem é a mais simples das três, porque traz a causa consigo. Diretamente abaixo ou poucas linhas depois aparece uma linha Caused by: — é aí que está o erro real, geralmente com o nome da mod ou do plugin responsável.
Procedimento:
- Procurar
Caused by:e anotar o nome da classe. - Se contiver o nome de uma mod ou de um plugin, o causador está identificado.
- Se o erro apareceu depois de uma alteração (nova mod, atualização, novo mundo), reverte primeiro essa alteração.
- Se o erro continuar pouco claro, envia a secção completa ao suporte — com a hora.
A análise da consola do teu servidor reconhece estas linhas automaticamente e explica cada mensagem detetada em texto claro, incluindo a frequência. Se só tens um trecho de log de outro sítio, podes colá-lo no nosso analisador de crash reports — mesmo sem servidor connosco.
O que tratamos automaticamente por ti
- Medição de desempenho sem intervenção. O TPS é registado a cada cerca de cinco minutos e mostrado no painel durante 24 horas — não precisas de instalar nenhum plugin.
- Aviso em caso de fraqueza persistente. Se o desempenho ficar baixo durante uma janela fiável, és avisado, em vez de teres de reparar nisso sozinho.
- Linhas de log explicadas. Mensagens reconhecidas recebem causa e solução em texto claro, no teu idioma — e, quando existe um guia adequado, um link para ele.
- Regra de sintoma antes da causa. Se no mesmo trecho do log houver uma mensagem de erro mais significativa do que o encerramento pelo Watchdog, mostramos-te essa.
Resolução de problemas: sintoma, verificação, solução
| Sintoma | Verificação | Solução provável |
|---|---|---|
| Lag só ao explorar áreas novas | Acontece quando jogadores entram em terreno inexplorado? | Geração de mundo; reduzir simulation-distance, mandar pré-gerar o mundo |
| Lag em horas fixas | Comparar a hora com tarefas planeadas | Mudar o horário do backup ou do plano de reinício |
| Servidor para sem erro, log termina abruptamente | A single server tick took está no fim? |
Encerramento pelo Watchdog; ler o minuto anterior |
| TPS mostra 20, mas continua a engasgar | /spark tps — ver MSPT |
O limitador de TPS esconde a carga; decidir com base no MSPT |
| Depois de adicionar uma mod | Remover a mod e medir de novo | Conflito de mod ou mod pesada |
| Serra no histórico de TPS | Verificar garbage collection no profiler | Pressão de memória; aumentar RAM |
| “Dispatched async TPS command” no log | Só esta linha, resto normal | Nada a fazer — é a nossa medição |
FAQ
A partir de que valor de TPS os jogadores notam algo?
Até cerca de 18 TPS, nada se nota no jogo. Abaixo de 15, fica visivelmente pesado. Mas não confies só nisso: verifica também o MSPT, porque o limitador de TPS pode mostrar um número saudável enquanto o servidor já trabalha no limite.
Mais RAM ajuda contra lag?
Só se a memória for realmente o gargalo. Se o profiler mostra garbage collection como item principal, sim. Se mostra um relógio de redstone ou uma mob farm, mais RAM não muda nada. Mede primeiro, compra depois.
Devo desligar o Watchdog?
Não, não de forma permanente. -1 tira-te a única deteção automática de um congelamento real. Um aumento temporário de max-tick-time para um processo lento conhecido, como o primeiro arranque de um modpack, é aceitável — depois repõe o valor.
Porque é que a mensagem do Watchdog aparece depois de “Stopping server”?
Porque o servidor já estava a desligar e ficou preso nesse processo. O Watchdog limpou então um encerramento bloqueado, não matou um servidor ainda em execução. A causa está antes de Stopping server.
Um reinício ajuda?
Contra um atraso agudo, sim; contra a causa, não. Se o lag volta pouco tempo depois de cada reinício, é estrutural — aí só a medição te leva mais longe.
Qual é a diferença entre view-distance e simulation-distance?
view-distance define até onde os jogadores veem; simulation-distance define até onde o mundo é realmente calculado. Ambos ficam por padrão em 10 chunks. Como só os chunks simulados consomem tempo de CPU, baixar simulation-distance alivia mais carga com menos perda visível.
Se continuar com lag
Antes de contactares o suporte, junta três coisas: a hora exata do último incidente, o link do teu relatório do spark profiler e a indicação de quais mods ou plugins foram adicionados por último. Assim dá para verificar diretamente a secção certa do log, em vez de fazer uma ronda genérica de otimização.
Ajustes gerais para todos os jogos — planos de reinício, escolha de plano, rede — encontras no guia melhorar a performance do gameserver. Como instalar e remover mods e plugins corretamente está em instalar mods e plugins do Minecraft.
Queres um servidor com medição de TPS, explicação de logs e avisos sem trabalho extra? Em alugar um servidor Minecraft encontras os planos certos.
Fontes e bancada de testes
max-tick-time, tickrate e distâncias: PaperMC — server.properties. Documenta o valor padrão de 60000 milissegundos, o encerramento forçado ao ultrapassar o limite, a desativação com-1e os valores padrão 10 paraview-distanceesimulation-distance.- spark está incluído no Paper: PaperMC — Profiling. A partir do Paper 1.21, não é necessário download separado.
- MSPT antes de TPS: spark — TPS and MSPT. Explica porque o limitador de TPS pode mostrar 20 lisos enquanto o servidor, na prática, corre mais devagar.
- Comandos do profiler: spark — Command Usage. Fonte para
/spark profiler start --timeout <sekunden>e/spark profiler stop.
Bancada de testes: 24 de agosto de 2026. Valores padrão e comandos podem mudar com novas versões de servidor; em caso de dúvida, consulta a documentação do fabricante ligada acima.