TPS no Minecraft: entenda as quedas de desempenho do servidor

O TPS servidor Minecraft é o indicador que define se o mundo roda fluido ou aos trancos: ele mede quantos ticks o mundo consegue processar por segundo. O valor ideal é 20, e qualquer coisa abaixo disso significa mobs travando, redstone atrasada e blocos voltando ao lugar. Este guia mostra como medir, diagnosticar e corrigir essas quedas com RAM, plugins e chunks sob controle.

O que é TPS e por que ele manda no desempenho do mundo

O jogo processa o mundo em ciclos chamados ticks. A cada tick, o motor calcula movimento de mobs, crescimento de plantações, propagação de redstone, física de água e lava, entidades de item, hoppers, pathfinding e sincronização com os jogadores. O alvo é 20 ticks por segundo, ou seja, um tick a cada 50 milissegundos.

Se o cálculo de um tick levar mais de 50 ms, o motor não pula trabalho: ele simplesmente atrasa. Resultado, o TPS cai. A métrica gêmea do TPS é o MSPT (milissegundos por tick), que é ainda mais útil no diagnóstico: o TPS só cai depois que o MSPT estoura 50 ms, então o MSPT avisa antes.

Tabela de leitura prática

TPS	MSPT médio	O que o jogador sente
20	abaixo de 40 ms	Mundo fluido, folga para crescer
20	40 a 50 ms	Limite. Qualquer pico gera microtravadas
18 a 19	50 a 56 ms	Mobs "escorregando", redstone levemente atrasada
14 a 17	60 a 70 ms	Hoppers lentos, farms perdendo rendimento
8 a 13	75 a 125 ms	Blocos voltando ao lugar, dano atrasado, PvP injogável
abaixo de 8	acima de 130 ms	Rubber banding forte, timeouts e desconexões

TPS baixo não é a mesma coisa que ping alto

Essa confusão é a causa de metade dos diagnósticos errados. O ping (latência) é o tempo de ida e volta do pacote entre o jogador e a máquina. O TPS é a velocidade interna de simulação do mundo. Dá para ter 15 ms de ping e 9 de TPS, e dá para ter 20 de TPS com 180 ms de ping.

• Sintoma de ping alto: só você trava, os outros jogadores estão normais, o chat demora a aparecer.
• Sintoma de TPS baixo: todos travam ao mesmo tempo, mobs congelam, plantações param de crescer, o relógio do dia/noite fica lento.

Vale lembrar que TPS é, na prática, uma métrica de frequência de CPU em uma única thread. O tick principal do Minecraft é majoritariamente monothread, então processadores Ryzen de alta frequência e disco NVMe para leitura e escrita de chunks pesam muito mais que uma contagem absurda de núcleos. Se quiser ver as configurações de máquina usadas para esse tipo de carga, dá uma olhada na página de hospedagem Minecraft antes de decidir qualquer ajuste de hardware. Para outros títulos com lógica de tick parecida, a lista completa está em Todos os nossos servidores de jogos.

Como diagnosticar quedas de TPS servidor Minecraft sem chutar

Mexer em configuração antes de medir é perda de tempo. A regra é simples: primeiro capture dados, depois altere uma variável por vez e compare. Todos os comandos abaixo rodam no console ao vivo do painel Pterodactyl ou dentro do jogo com permissão de operador.

Passo 1: leitura rápida com /tps e /mspt

# Paper, Purpur e derivados
/tps
# saída: TPS from last 1m, 5m, 15m: 19.98, 19.87, 18.42

/mspt
# saída: 41.2/58.7 (média/pico dos últimos ticks)

O que interessa aqui é o padrão. TPS de 15 minutos bom e TPS de 1 minuto ruim indica evento pontual (alguém abriu um portal do Nether, ligou uma farm, colou um build gigante). TPS ruim nos três intervalos indica carga estrutural: chunks demais, entidades demais ou plugin pesado em loop.

Passo 2: perfilamento com spark

O spark é a ferramenta padrão hoje para achar a origem do lag, tanto em Paper/Spigot quanto em Fabric e Forge. Instale o jar em plugins/ (ou mods/), reinicie e rode:

# perfil de 60 segundos, com o servidor sob carga real
/spark profiler start --timeout 60

# relatório de saúde: TPS, MSPT, CPU, memória e GC
/spark health --memory

# quem está consumindo tick: entidades e chunks por mundo
/spark tps

O relatório gera um link com a árvore de chamadas. Procure o que ocupa mais porcentagem dentro do ServerLevel.tick: normalmente cai em um destes grupos.

Bloco no relatório	Causa típica
EntityTickList / Mob.aiStep	Excesso de mobs, farms de spawner, pathfinding em massa
HopperBlockEntity.tickHopper	Linhas longas de hoppers, sistemas de sorting sem trava
RedStoneWireBlock	Clocks de redstone permanentes, elevadores de itens
ChunkMap / ChunkHolder	Geração de terreno, view distance alto, chunk loaders
Nome de um plugin no stack	Tarefa síncrona, consulta de banco na thread principal
G1 Young Generation longo	Problema de memória e coleta de lixo, não de lógica

Passo 3: correlacionar com o comportamento dos jogadores

Anote o horário das quedas. Se o TPS afunda sempre no pico de jogadores, é escala (chunks carregados simultâneos). Se afunda em horários aleatórios com pouca gente online, suspeite de tarefa agendada: backup mal configurado rodando na thread principal, dynmap renderizando, plugin de estatística salvando tudo de uma vez. Cruze com os logs em logs/latest.log e procure a linha clássica:

[Server thread/WARN]: Can't keep up! Is the server overloaded?
Running 4218ms or 84 ticks behind

Antes de qualquer alteração de configuração, garanta um ponto de restauração. Com backups automáticos ativos no painel, você testa valores agressivos sem medo de corromper região do mundo.

RAM, JVM e coleta de lixo: onde quase todo mundo erra

Existe um mito persistente de que mais RAM significa mais TPS. Não é verdade. A memória evita out of memory e travadas de coleta de lixo, mas o tick é limitado por CPU. RAM em excesso pode até piorar o desempenho, porque o coletor G1 passa a varrer um heap gigantesco e gera pausas longas, que aparecem como quedas bruscas de TPS a cada poucos minutos.

Quanto de memória faz sentido

Cenário	Heap indicado
Vanilla/Paper, até 10 jogadores, poucos plugins	4 GB
Survival com 20 a 40 jogadores e 15 plugins	6 a 8 GB
Modpack médio (100 a 200 mods), 10 jogadores	8 a 10 GB
Modpack grande (300+ mods) ou rede com proxy	10 a 16 GB

Sempre iguale -Xms e -Xmx. Heap variável faz a JVM redimensionar durante o jogo, e cada redimensionamento é uma microtravada.

Flags de inicialização que valem a pena

java -Xms8G -Xmx8G \
 -XX:+UseG1GC \
 -XX:+ParallelRefProcEnabled \
 -XX:MaxGCPauseMillis=200 \
 -XX:+UnlockExperimentalVMOptions \
 -XX:+DisableExplicitGC \
 -XX:+AlwaysPreTouch \
 -XX:G1NewSizePercent=30 \
 -XX:G1MaxNewSizePercent=40 \
 -XX:G1HeapRegionSize=8M \
 -XX:G1ReservePercent=20 \
 -XX:G1HeapWastePercent=5 \
 -XX:G1MixedGCCountTarget=4 \
 -XX:InitiatingHeapOccupancyPercent=15 \
 -XX:G1MixedGCLiveThresholdPercent=90 \
 -XX:G1RSetUpdatingPauseTimePercent=5 \
 -XX:SurvivorRatio=32 \
 -XX:+PerfDisableSharedMem \
 -XX:MaxTenuringThreshold=1 \
 -jar paper.jar nogui

No painel Pterodactyl, esses parâmetros entram na aba de inicialização, no campo de argumentos da JVM, sem precisar editar script algum. Use uma versão de Java compatível com a build do jogo (Java 17 para 1.17 a 1.20.4, Java 21 para 1.20.5 e acima) e confirme com:

java -version

Sinais de que o problema é memória, e não lógica

• /spark health --memory mostra o heap sempre acima de 90% depois de estabilizar.
• Pausas de GC acima de 300 ms aparecendo repetidamente no relatório.
• O TPS cai de 20 para 5 por dois segundos e volta, em intervalos regulares.
• O log traz java.lang.OutOfMemoryError: Java heap space.

Se nada disso aparece e o heap está folgado, pare de mexer em memória. O gargalo está no tick.

Plugins, mods, entidades e chunks: os quatro ladrões de tick

Chunks carregados e distância de visão

Cada chunk carregado é trabalho por tick. Reduzir a distância de visão é o ajuste com a maior relação entre ganho e esforço. Em server.properties:

view-distance=8
simulation-distance=6
max-players=40
network-compression-threshold=256

A distinção é importante: view-distance define o que o jogador vê, simulation-distance define o que é simulado (mobs, redstone, plantações). Dá para manter a paisagem bonita com view 10 e simulação 5, que é a combinação que mais preserva o TPS servidor Minecraft em mundos movimentados.

Outro ponto: exploração em massa gera terreno novo, e geração de terreno é a operação mais pesada do jogo. Pré-gere o mundo com o Chunky, com o servidor vazio:

/chunky world world
/chunky center 0 0
/chunky radius 4000
/chunky start
# acompanhe pelo console e use /chunky pause quando precisar

Depois, fixe um limite de mundo com um plugin de borda ou com o próprio comando vanilla, para que ninguém corra 20 mil blocos em linha reta gerando chunk:

/worldborder center 0 0
/worldborder set 8000

Entidades: o inimigo silencioso

Mobs, itens no chão, armor stands, minecarts, barcos e quadros contam como entidades, e cada um pede cálculo. Em bukkit.yml, corte o limite global de spawn:

spawn-limits:
  monsters: 40
  animals: 8
  water-animals: 3
  ambient: 1
ticks-per:
  animal-spawns: 400
  monster-spawns: 4
  autosave: 6000

Em spigot.yml, reduza o alcance de ativação para que entidades distantes fiquem "dormindo":

entity-activation-range:
  animals: 16
  monsters: 24
  raiders: 32
  misc: 8
  water: 8
merge-radius:
  item: 3.5
  exp: 4.0
mob-spawn-range: 6
nerf-spawner-mobs: true

E em config/paper-world-defaults.yml, os ajustes que mais rendem:

chunks:
  max-auto-save-chunks-per-tick: 8
entities:
  spawning:
    per-player-mob-spawns: true
    despawn-ranges:
      monster:
        soft: 28
        hard: 72
collisions:
  max-entity-collisions: 2
hopper:
  disable-move-event: false
  ignore-occluding-blocks: true
misc:
  redstone-implementation: ALTERNATE_CURRENT
  alt-item-despawn-rate:
    enabled: true
    items:
      cobblestone: 300
      sand: 300

A opção per-player-mob-spawns distribui o limite de mobs por jogador em vez de por mundo, o que evita que uma farm gigante consuma toda a cota e ainda pese no tick. Já ALTERNATE_CURRENT troca o algoritmo de redstone por uma implementação bem mais barata, sem alterar comportamento na maioria dos circuitos. Os nomes e caminhos dessas chaves mudam entre versões, então confirme na Source oficial antes de colar.

Plugins e mods: menos é mais

Plugins não são todos iguais. O padrão de problema é sempre o mesmo: tarefa síncrona rodando na thread principal. Os suspeitos habituais:

• Proteção de terreno com verificação por bloco: checagem em cada colocação/quebra em regiões enormes.
• Economia e estatísticas com banco remoto: consulta SQL síncrona trava o tick inteiro esperando resposta.
• Mapas dinâmicos: renderização completa no meio do horário de pico.
• Chunk loaders e keep-alive: mantêm dezenas de chunks vivos mesmo sem jogadores.
• Funções sobrepostas: dois plugins tratando o mesmo evento (dois sistemas de chat, dois de home).

O método de eliminação é chato mas funciona: mova metade dos plugins para uma pasta plugins-off/, reinicie, meça 20 minutos, repita por bissecção. Em modpacks, o equivalente é olhar o relatório do spark e desativar mods de geração ou de automação que aparecem no topo do stack.

Checklist de estabilização

1. Medir com /tps, /mspt e /spark profiler em horário de pico.
2. Conferir heap e pausas de GC antes de tocar em qualquer config de mundo.
3. Reduzir simulation-distance e depois view-distance, um por vez.
4. Aplicar limites de spawn e de ativação de entidades.
5. Pré-gerar o terreno e fechar a borda do mundo.
6. Isolar plugins ou mods por bissecção.
7. Agendar reinício diário automático para limpar acúmulo de entidades e memória.

Um reinício programado às 5h da manhã pelo agendador do painel resolve boa parte das degradações lentas, aquelas em que o TPS começa em 20 e termina o dia em 14. Se depois de tudo isso o MSPT continuar colado nos 50 ms com 40 jogadores online, o gargalo passou a ser frequência de CPU, e aí o caminho é hardware com relógio mais alto e disco NVMe, não mais ajuste de YAML. Outros tutoriais de administração e otimização estão no Blog da Fly-Serv, e a visão geral da infraestrutura com anti-DDoS incluído fica em Fly-Serv.

Conclusão

TPS é uma métrica de CPU e de simulação, não de memória. Meça com spark antes de mexer em qualquer arquivo, ajuste uma variável por vez, controle chunks e entidades e mantenha a lista de plugins enxuta. Com reinícios agendados, backups em dia e distâncias de simulação realistas, o mundo se mantém em 20 ticks por segundo mesmo nos horários cheios.

FAQ

Mais RAM aumenta o TPS do meu mundo?

Não diretamente. Memória evita erros de heap e pausas longas de coleta de lixo, mas o tick é limitado por frequência de CPU em uma única thread. Heap exagerado até piora, porque o coletor G1 varre uma área maior e gera pausas visíveis. Iguale -Xms e -Xmx, use 6 a 8 GB para survival com plugins e invista o resto do esforço em reduzir chunks e entidades.

Por que o TPS cai só quando muitos jogadores exploram ao mesmo tempo?

Porque cada jogador em terreno inédito força geração de chunk, a operação mais pesada do jogo. Pré-gere o mapa com o Chunky em um raio definido, feche a borda com /worldborder set e baixe simulation-distance para 5 ou 6. Depois disso, o mesmo número de jogadores passa a custar bem menos MSPT porque o terreno já está escrito no disco.

Como saber se a queda de TPS vem de um plugin específico?

Rode /spark profiler start --timeout 60 em horário de pico e abra o relatório. Se o nome do plugin aparecer dentro do stack do tick principal, o culpado está identificado. Sem isso, faça bissecção: desative metade dos plugins, reinicie, meça 20 minutos, repita. Fique atento a plugins com consultas de banco síncronas e a funções duplicadas entre dois plugins.