Desempenho de servidor Minecraft : entenda TPS, RAM e core

Entender o TPS servidor Minecraft é essencial para diagnosticar quedas de desempenho antes que os jogadores comecem a reclamar de lag, teleportes estranhos ou mobs que não se movem direito. TPS, RAM alocada e tipo de core (Vanilla, Spigot ou Paper) formam o trio que decide se o mundo roda liso ou trava a cada explosão de TNT.

Como o TPS servidor Minecraft funciona e por que ele cai

O Minecraft processa o mundo em ciclos chamados ticks. Cada tick atualiza física de blocos, movimento de entidades, redstone, crescimento de plantas e sincronização com os jogadores conectados. O valor ideal é 20 ticks por segundo (TPS), ou seja, um tick a cada 50 milissegundos. Quando o processamento de um tick demora mais que isso, o servidor "atrasa" o relógio interno do jogo para compensar, e é exatamente aí que o TPS cai abaixo de 20.

Um TPS entre 18 e 20 costuma ser imperceptível. Abaixo de 15, jogadores já notam mobs travando, portas demorando para abrir e redstone dessincronizada. Abaixo de 10, o mundo praticamente congela: colheitas param de crescer, drops de itens ficam suspensos no ar, e comandos com delay (como /tp em massa) começam a falhar silenciosamente.

A causa raiz quase nunca é uma única coisa. Geralmente é uma combinação de: número de entidades vivas (mobs, itens dropados, armadillos de fazenda de mobs), quantidade de chunks carregados, redstone complexa rodando em loop, e plugins ou mods mal otimizados que executam tarefas pesadas dentro do tick principal em vez de rodar de forma assíncrona.

Se você está migrando de um mundo pequeno para uma comunidade maior e sente que o hardware atual já não acompanha o crescimento, vale considerar uma hospedagem Minecraft com CPU de alta frequência e NVMe, já que ambos afetam diretamente quantos ticks por segundo o servidor consegue sustentar sob carga real.

RAM alocada e garbage collection: o que realmente pesa no desempenho

Um erro comum é achar que "mais RAM sempre resolve". A RAM alocada ao Minecraft não acelera o processamento de ticks diretamente — ela evita que o servidor precise descartar chunks e dados em cache com frequência. O problema real costuma estar no garbage collection (GC) da JVM: quando a memória alocada é insuficiente ou mal configurada, o Java para o mundo inteiro por alguns milissegundos (ou segundos) para limpar objetos não utilizados, e isso aparece como um pico de lag repentino, mesmo com TPS estável no restante do tempo.

Alocação recomendada por tamanho de comunidade

Perfil do servidor	RAM sugerida	Observação
Vanilla, 1 a 10 jogadores	2 a 4 GB	Mundo pequeno, poucos plugins
Paper com plugins leves, 10 a 30 jogadores	4 a 8 GB	Economia, RPG básico, permissões
Paper com modpack ou muitos plugins, 30+ jogadores	8 a 16 GB	Farms de mobs, redstone complexa

Flags de JVM que reduzem pausas de GC

As flags conhecidas como "Aikar's flags" reduzem a frequência e a duração das pausas de garbage collection ao usar o coletor G1GC de forma mais agressiva. Um exemplo de linha de inicialização:

java -Xms4G -Xmx4G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
-XX:+DisableExplicitGC -XX:G1NewSizePercent=30 \
-XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M \
-jar paper.jar --nogui

Note que -Xms e -Xmx devem ter o mesmo valor. Alocar uma faixa variável (por exemplo, 2G a 8G) obriga a JVM a redimensionar o heap em tempo real, o que gera picos de latência justamente nos momentos de maior carga.

Paper, Spigot ou Vanilla: o core muda o comportamento dos ticks

O core (a implementação do servidor) determina como o Minecraft distribui o trabalho de cada tick entre CPU e mundo. Vanilla é fiel ao comportamento oficial da Mojang, mas não tem nenhuma otimização de carregamento de entidades ou de visão de mob. Spigot já introduz otimizações de rede e configuração. Paper vai além: reescreve partes do motor de física, IA de mobs e carregamento de chunks para reduzir o custo por tick sem alterar a jogabilidade percebida.

Core	Compatibilidade com plugins	Otimização de ticks	Uso recomendado
Vanilla	Nenhuma	Baixa	Fidelidade total às regras oficiais
Spigot	Plugins Bukkit	Média	Servidores simples com poucos plugins
Paper	Plugins Bukkit/Spigot	Alta	Comunidades com muitos jogadores e mods de gameplay

Ajustes de paper.yml e spigot.yml que impactam o TPS

O Paper expõe parâmetros que controlam diretamente quantas entidades são processadas por tick e a que distância. Dois dos mais relevantes:

# paper-world-defaults.yml
entities:
  spawning:
    despawn-ranges:
      soft: 32
      hard: 128
chunks:
  entity-per-chunk-save-limit:
    ambient: 15
    monster: 15

# server.properties
view-distance=8
simulation-distance=6

Reduzir view-distance e simulation-distance costuma trazer o ganho mais imediato de TPS em servidores com muitos jogadores, porque menos chunks precisam ser calculados e enviados a cada ciclo. É um ajuste de custo zero antes de pensar em trocar hardware.

Diagnosticando quedas de TPS: comandos, logs e ferramentas de profiling

Antes de qualquer mudança de configuração, é preciso confirmar onde o tempo do tick está sendo gasto. O comando nativo mostra o TPS médio dos últimos 1, 5 e 15 minutos:

/tps

Para uma análise mais profunda, o plugin Spark gera um relatório detalhado de quais métodos, plugins ou operações do mundo consomem mais tempo de CPU por tick:

/spark profiler start
/spark profiler stop
/spark tps

O relatório do Spark aponta, por exemplo, se o gargalo é uma farm de mobs específica, um plugin de economia rodando queries síncronas no banco de dados, ou o próprio carregamento de chunks. Isso evita o erro comum de "trocar de core" ou aumentar RAM sem saber qual é o problema real.

Checklist de diagnóstico rápido

• Rodar /tps e anotar o valor em horários de pico de jogadores
• Verificar o console em busca de mensagens "Can't keep up!" e o número de ticks perdidos
• Rodar um profiling com Spark durante um pico de lag reportado pelos jogadores
• Checar o número de entidades carregadas com /entitycount (Paper) para identificar farms fora de controle
• Revisar logs de erro recorrentes de plugins que possam estar travando o thread principal

Quando o servidor roda em um ambiente controlado pelo próprio administrador, esse diagnóstico fica mais rápido acessando diretamente os logs e o console via SSH ou painel. Em uma VPS Pterodactyl, por exemplo, é possível acompanhar o uso de CPU em tempo real enquanto o Spark gera o relatório, cruzando os dois dados para confirmar se o gargalo é de processamento ou de I/O em disco:

ssh usuario@ip-da-vps
top -o %CPU
tail -f logs/latest.log

Quando o problema não é o servidor de jogo

Nem toda queda de TPS vem do mundo em si. Latência de rede, disco lento (HDD em vez de SSD/NVMe) e picos de tráfego malicioso também derrubam o desempenho percebido, mesmo com TPS técnico estável. Vale sempre cruzar o /tps com o ping médio dos jogadores e com a atividade de disco antes de concluir que o gargalo está no processamento de ticks.

Para quem administra várias instâncias ou está pensando em reorganizar a infraestrutura, vale conferir Todos os nossos servidores de jogos e comparar recursos como CPU dedicada, NVMe e anti-DDoS incluído, que influenciam diretamente na estabilidade do TPS sob carga. Mais leitura técnica sobre configuração e otimização está disponível no Blog da Fly-Serv.

Conclusão

O TPS de um servidor Minecraft reflete o equilíbrio entre entidades ativas, alocação de memória e eficiência do core escolhido. Diagnosticar antes de otimizar evita mudanças desnecessárias: comece pelo /tps, confirme com profiling e só depois ajuste RAM, flags de JVM ou distância de simulação.

FAQ

Por que o TPS cai mesmo com poucos jogadores online?

Geralmente é causado por farms de mobs ou itens acumulados, redstone em loop constante ou um plugin executando tarefas pesadas de forma síncrona. Rode um profiling com Spark para identificar a origem exata antes de mexer em RAM ou hardware.

Aumentar a RAM alocada resolve quedas de TPS?

Nem sempre. RAM insuficiente pode causar pausas de garbage collection, mas se o gargalo for processamento de entidades ou chunks, adicionar memória não resolve. Use flags de JVM adequadas e confirme a causa com o comando /tps e um profiler antes de aumentar a alocação.

Paper realmente melhora o TPS em relação ao Vanilla?

Sim, o Paper reescreve trechos do carregamento de chunks, física de entidades e IA de mobs para reduzir o custo por tick, mantendo a jogabilidade compatível com o Vanilla. A diferença é mais perceptível em servidores com muitos jogadores ou farms ativas.