Como resolver o lag em um servidor de Minecraft

Lag do servidor, da rede ou do cliente?

O teste mais rápido é perguntar se todo mundo está lagando no mesmo momento. Um servidor que fica para trás congela todos os jogadores juntos; uma conexão ruim ou um PC lento afetam só o próprio dono. O resto deste guia trata do lag do servidor.

Primeiro meça: TPS, MSPT e spark

Um servidor de Minecraft roda a 20 ticks por segundo, então cada tick tem 50 ms para terminar. Dois números mostram como ele está se saindo:

• TPS (ticks por segundo): 20 significa que o servidor está dando conta; abaixo de 20 o mundo fica mais lento.
• MSPT (milissegundos por tick): quanto tempo cada tick leva. Abaixo de 50 ms sobra tempo; acima de 50 ms o servidor fica para trás.

O Paper tem /tps e /mspt, mas a própria documentação dele indica o spark, que vem embutido no Paper desde a 1.21 e está disponível como mod para Fabric, Forge e NeoForge:

/spark tps
/spark health
/spark ping

/spark tps mostra o TPS dos últimos segundos e minutos e, o que é mais útil, a duração dos ticks em mínimo, mediana, percentil 95 e máximo. /spark ping mostra o ping dos jogadores, o que resolve a dúvida "servidor ou rede". /spark health acrescenta CPU, memória e disco.

Encontre a causa com um perfil do spark

Os números dizem que o servidor está com lag; um perfil diz por quê. Inicie um enquanto o lag está acontecendo e deixe rodar por alguns minutos:

/spark profiler start --timeout 300

Quando termina, o spark publica um link para o visualizador web dele. Nele:

1. Abra o Server thread, a thread principal que roda o mundo. É ali que o lag mora.
2. Expanda as entradas com as maiores porcentagens: é para lá que vai o tempo de tick.
3. Mude para a visualização Sources para ver o tempo dividido por plugin ou mod. Um plugin ou mod ocupando uma grande parte da thread principal costuma ser a resposta.

Mais duas ferramentas ajudam com o lag que vai e volta: /spark tickmonitor avisa sobre cada tick que demora demais, e /spark profiler start --only-ticks-over 100 grava só os ticks lentos, para que um pico raro não se perca na média.

As correções que importam, em ordem

1. Distância de visão e de simulação

No server.properties, simulation-distance define até que distância dos jogadores o mundo é realmente simulado (mobs, plantações, redstone) e view-distance até onde os chunks são enviados aos jogadores. As duas têm 10 como padrão. Baixar simulation-distance costuma ser o maior ganho isolado: teste entre 6 e 8, e deixe view-distance um pouco mais alta para o mundo continuar parecendo aberto. São pontos de partida, não valores oficiais; meça antes e depois.

2. Pré-gere o mundo

Gerar chunks novos é uma das tarefas mais pesadas de um servidor, e jogadores explorando em direções diferentes fazem isso acontecer o tempo todo. O plugin (ou mod) Chunky gera o mapa com antecedência:

chunky radius 5000
chunky start
chunky pause
chunky continue

Rode quando ninguém estiver jogando (uma pré-geração em andamento faz o servidor mostrar "Can't keep up", e isso é esperado) e pause quando os jogadores entrarem.

3. Entidades e farms

Farms de mobs, salões de aldeões e pilhas de itens são o consumo constante mais comum. No Paper e no Spigot, entity-activation-range no spigot.yml controla o quão perto um jogador precisa estar para uma entidade receber ticks completos, e merge-radius junta itens dropados e orbes de experiência. Limite as farms de mobs com um plugin ou uma regra, e limpe as pilhas de itens esquecidas.

4. Funis e redstone

Cadeias grandes de funis são pesadas. No spigot.yml, ticks-per.hopper-transfer define com que frequência eles movem itens, e o hopper.disable-move-event do Paper os acelera bastante, mas quebra plugins de proteção que dependem desse evento. Para redstone, o misc.redstone-implementation: ALTERNATE_CURRENT do Paper pode reduzir muito o lag do pó de redstone, mas muda o comportamento do pó, então teste suas máquinas antes.

5. O plugin ou mod do seu perfil

Se o perfil do spark aponta para um plugin ou mod, a correção é essa: atualize, reduza a configuração dele ou troque por outro. Nenhuma quantidade de RAM deixa mais rápido um plugin mal escrito.

"O TPS está em 20, mas continua lagando"

Esse é o caso mais confuso, e quase sempre é uma travada de tick: a maioria dos ticks é rápida, mas de vez em quando um leva centenas de milissegundos. A média fica em 20, mas todo mundo sente o congelamento.

• Confira o tempo de tick máximo em /spark tps, ou rode /spark tickmonitor. Picos de várias centenas de milissegundos confirmam.
• A causa comum é um plugin esperando na thread principal: buscando skins ou cabeças de jogadores na internet, enviando para um webhook, procurando atualizações ou checando uma licença, ou salvando um arquivo ou banco de dados de forma síncrona. O servidor não faz nada enquanto espera.
• Faça o perfil da espera, não só do processamento. Um perfil normal mostra trabalho de CPU; uma thread esperando parece ociosa. Use /spark profiler start --thread * para capturar onde o tempo é gasto, incluindo esperas, e procure chamadas de rede ou de arquivo no Server thread.

A correção está no plugin: chamadas assíncronas, ou outro plugin. Mais RAM, uma CPU mais rápida ou uma conexão melhor não vão ajudar, porque não falta nada ao servidor; ele está esperando.

Quando a resposta é mesmo RAM ou CPU

O Minecraft simula o mundo em uma única thread principal. Isso tem duas consequências:

• A velocidade da CPU por núcleo é o que mais importa. Se o spark mostra o Server thread ocupado com o trabalho normal do mundo (entidades, chunks, ticks de blocos) e o MSPT está alto, uma CPU mais rápida ajuda onde mais núcleos não ajudariam.
• RAM só ajuda quando está faltando. Sinais: o servidor reinicia ao bater no limite de memória, ou as pausas da coleta de lixo dominam o perfil. Além do que o mundo e os mods precisam, mais RAM não faz nada pela velocidade dos ticks, e um heap superdimensionado e sem ajuste pode deixar as pausas da coleta de lixo mais longas.

Quanta RAM um servidor precisa, e as flags de inicialização que mantêm a coleta de lixo curta, estão em quanta RAM um servidor de Minecraft precisa. A escolha entre Paper, Purpur e os demais está em o melhor software para servidor de Minecraft.

O lag e o seu servidor HytHost

Todos os planos de Minecraft da HytHost rodam no mesmo hardware: CPUs Ryzen 7 e Intel i9 com boost de até 5.0 GHz, memória DDR4 e armazenamento NVMe, ou seja, a velocidade single-thread de que o Minecraft depende. O spark já faz parte do Paper, então você pode fazer perfis pelo console desde o começo.

Se o perfil mostrar que o servidor realmente está sem memória para o mundo e os mods, suba de plano pelo painel; o mundo continua onde está. Se mostrar um plugin ou uma farm, resolva isso primeiro: é de graça e funciona em qualquer plano. Veja hospedagem de Minecraft, ou os planos maiores em hospedagem de Minecraft premium a partir de €11.65/mês.