TPS no servidor Minecraft : entenda e corrija as quedas de desempenho

O TPS servidor Minecraft é o indicador mais direto da saúde de uma instância: ele mostra quantos ticks por segundo o mundo consegue processar antes de travar animações, spawns e redstone. Quando esse número cai, jogadores sentem lag, mobs somem e blocos demoram para reagir. Entender a origem técnica da queda é o primeiro passo para corrigir o problema.

O que é TPS e como ele afeta o desempenho do servidor

O Minecraft roda em ciclos chamados "ticks". Em condições ideais, o servidor processa 20 ticks por segundo, o que corresponde a um TPS de 20. Cada tick atualiza física de blocos, movimentação de entidades, redstone, crescimento de plantas e sincronização com os clientes conectados. Quando o processamento de um tick demora mais de 50ms, o servidor não consegue manter o ritmo e o TPS despenca.

Um TPS abaixo de 18 já é perceptível: mobs andam com engasgos, portas demoram para abrir, itens dropados "pulam" na tela. Abaixo de 15, o gameplay fica praticamente injogável em servidores com PvP ou redstone complexo. O valor de TPS não mede apenas performance de hardware, ele reflete o equilíbrio entre a carga do mundo (chunks carregados, entidades, mods) e a capacidade do processador em executar cada tick dentro do prazo.

Para quem administra uma comunidade e quer eliminar de vez o gargalo de hardware antes de otimizar configurações, vale considerar uma hospedagem Minecraft com CPU dedicado de alta frequência, já que o TPS depende diretamente da velocidade de núcleo único do processador.

Principais fatores técnicos que causam queda de TPS

Antes de aplicar qualquer correção, é essencial identificar qual componente está sobrecarregando o tick. Os fatores abaixo são responsáveis pela grande maioria dos casos de queda de TPS em servidores Minecraft, tanto vanilla quanto com Paper, Spigot ou Forge.

Carga de entidades e mobs

Fazendas de mobs mal dimensionadas, acúmulo de itens dropados e criadores automáticos geram um número excessivo de entidades vivas simultaneamente. Cada entidade precisa de cálculo de IA, colisão e pathfinding a cada tick, o que consome CPU de forma cumulativa.

Chunks carregados além do necessário

Um view-distance alto ou chunks "forçados" (chunk loaders) mantêm regiões do mapa ativas mesmo sem jogadores por perto. Isso multiplica a quantidade de blocos, redstone e entidades processados a cada ciclo.

Redstone e mecanismos automatizados

Circuitos de redstone complexos, especialmente clocks rápidos e portas lógicas encadeadas, geram atualizações em cascata. Máquinas de farm automatizadas mal otimizadas são uma causa recorrente de lag de tick.

Plugins e mods mal otimizados

Plugins que executam tarefas pesadas de forma síncrona (leitura de banco de dados, verificação de permissões, scans de inventário) bloqueiam a thread principal do servidor e atrasam o tick inteiro, mesmo que o restante do mundo esteja leve.

Garbage Collection da JVM

Configurações de memória inadequadas na Java Virtual Machine provocam pausas de Garbage Collection (GC) que congelam o servidor por frações de segundo, gerando picos de queda de TPS visíveis nos gráficos de monitoramento.

Tabela resumo dos gargalos comuns

Fator	Impacto no tick	Sintoma visível
Excesso de entidades	Alto	Mobs travados, lag em áreas de farm
View-distance elevado	Médio a alto	Lag geral no mapa inteiro
Redstone complexo	Médio	Atraso em circuitos e portas
Plugins síncronos	Alto	Micro-freezes intermitentes
GC mal configurado	Alto	Picos curtos de TPS baixo

Como diagnosticar a queda de TPS na prática

Diagnosticar antes de corrigir evita perda de tempo ajustando configurações que não são a causa real. Use os comandos e ferramentas abaixo diretamente no console do servidor.

Comando /tps

Em servidores baseados em Paper ou Spigot, o comando nativo mostra a média de TPS nos últimos 1, 5 e 15 minutos:

/tps

Um resultado como 20.0, 19.8, 19.5 indica estabilidade. Valores consistentemente abaixo de 18 nos três intervalos apontam para um problema estrutural, não pontual.

Plugin Spark para profiling

O Spark é hoje a referência para identificar exatamente qual thread, plugin ou tarefa consome mais tempo de tick. Ele gera um relatório detalhado acessível via navegador:

/spark profiler --timeout 60
/spark profiler stop

O relatório mostra em porcentagem quanto cada plugin, mod ou sistema nativo (entidades, chunks, redstone) consome do tempo total de tick, permitindo isolar o culpado com precisão.

Monitoramento via console do painel

Servidores gerenciados através do painel Pterodactyl permitem acompanhar em tempo real o uso de CPU e memória da instância, além do console ao vivo, o que ajuda a correlacionar picos de uso de recursos com quedas de TPS reportadas pelos jogadores.

Timings report (Spigot/Paper legado)

/timings on
/timings paste

Embora o Spark tenha substituído o Timings na maioria dos casos, ele ainda funciona como alternativa para gerar um relatório de desempenho compartilhável com a comunidade de desenvolvedores de plugins.

Como corrigir e otimizar o desempenho do servidor

Depois de identificar a causa raiz, aplique as correções específicas para cada tipo de gargalo. Evite alterar tudo de uma vez: mude um parâmetro por vez e observe o TPS antes de seguir para o próximo ajuste.

Ajustar view-distance e simulation-distance

No arquivo server.properties, reduzir a distância de renderização e simulação diminui diretamente a quantidade de chunks processados a cada tick:

view-distance=8
simulation-distance=6

Servidores com muitos jogadores simultâneos costumam ganhar TPS estável reduzindo esses valores de 10 para algo entre 6 e 8, sem prejuízo perceptível de gameplay para a maioria das comunidades.

Limitar entidades e mobs

Em servidores Paper, o arquivo paper-world-defaults.yml permite ajustar limites de mobs por chunk e ativar otimizações de IA para entidades distantes:

entity-per-chunk-save-limit:
  monster: 4
  animal: 4
per-player-mob-spawns: true

Configurar corretamente as flags de JVM

Usar flags de Garbage Collection otimizadas para Minecraft (como as recomendadas pela comunidade Aikar) reduz drasticamente as pausas de GC responsáveis por picos de lag:

java -Xms4G -Xmx4G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
-XX:+DisableExplicitGC -jar server.jar nogui

Definir -Xms e -Xmx com o mesmo valor evita que a JVM precise redimensionar o heap dinamicamente, o que também gera micro-pausas.

Auditar e substituir plugins problemáticos

Depois de identificar via Spark quais plugins consomem mais tempo de tick, avalie se existe uma versão mais recente, uma alternativa mais leve ou se a funcionalidade pode ser configurada para rodar de forma assíncrona.

Reiniciar periodicamente e manter sauvegardas atualizadas

Servidores que rodam por semanas sem reinício acumulam vazamentos de memória e fragmentação de chunks no disco. Um agendamento de reinício diário, combinado com sauvegardas automáticas regulares, evita degradação progressiva do TPS ao longo do tempo:

0 5 * * * systemctl restart minecraft-server.service

Para quem administra a instância via linha de comando em um VPS Pterodactyl, é possível automatizar esse tipo de rotina diretamente via cron, mantendo o painel para gestão de arquivos, plugins e console. Mais tutoriais de configuração e otimização estão disponíveis no Blog da Fly-Serv, e a lista completa de jogos suportados pode ser consultada em Todos os nossos servidores de jogos.

Para aprofundar detalhes técnicos sobre ticks e mecânicas internas do jogo, consulte a documentação oficial do Minecraft Wiki.

Manter o TPS estável exige monitoramento contínuo, ajustes de configuração coerentes com o número de jogadores e revisão periódica de plugins e mecanismos automatizados. Diagnosticar antes de corrigir evita retrabalho e garante que cada mudança realmente resolva a causa da queda de desempenho.

FAQ

Qual é o valor ideal de TPS em um servidor Minecraft?

O ideal é manter o TPS o mais próximo possível de 20, que representa o funcionamento pleno de 20 ticks por segundo. Valores entre 18 e 20 são considerados saudáveis para a maioria das comunidades.

Reduzir o número de jogadores resolve a queda de TPS?

Nem sempre. A queda de TPS costuma estar ligada a chunks carregados, entidades e plugins, não apenas à quantidade de jogadores conectados. Use o Spark para confirmar a causa antes de limitar o acesso.

Vale a pena usar Paper em vez do servidor vanilla para melhorar o TPS?

Sim, o Paper inclui otimizações nativas de processamento de entidades, chunks e redstone que reduzem significativamente a carga de tick em comparação ao servidor vanilla original.