Como resolver o lag num servidor de Minecraft

Lag do servidor, da rede ou do cliente?

O teste mais rápido é perguntar se todos têm lag no mesmo momento. Um servidor que fica para trás congela todos os jogadores ao mesmo tempo; uma má ligação ou um PC lento só afetam o seu dono. O resto deste guia trata do lag do servidor.

Primeiro meça: TPS, MSPT e spark

Um servidor de Minecraft corre a 20 ticks por segundo, por isso cada tick tem 50 ms para terminar. Dois números descrevem como está a aguentar:

• TPS (ticks por segundo): 20 significa que o servidor acompanha; abaixo de 20 o mundo abranda.
• MSPT (milissegundos por tick): quanto demora cada tick. Abaixo de 50 ms há folga; acima de 50 ms o servidor fica para trás.

O Paper tem /tps e /mspt, mas a sua própria documentação aponta para o spark, que vem integrado 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, mais útil ainda, 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 tem lag; um perfil diz porquê. Inicie um enquanto o lag está a acontecer e deixe-o correr alguns minutos:

/spark profiler start --timeout 300

Quando termina, o spark publica uma ligação para o seu visualizador web. Nele:

1. Abra o Server thread, a thread principal que faz correr o mundo. É lá que vive o lag.
2. Expanda as entradas com as percentagens mais altas: é para lá que vai o tempo de tick.
3. Mude para a vista Sources para ver o tempo dividido por plugin ou mod. Um plugin ou mod que ocupa uma grande fatia da thread principal costuma ser a resposta.

Há mais duas ferramentas úteis para o lag que vai e vem: /spark tickmonitor assinala cada tick que demora demasiado, e /spark profiler start --only-ticks-over 100 regista apenas os ticks lentos, para que um pico raro não se perca na média.

As soluções que contam, por ordem

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

Em server.properties, simulation-distance define até que distância dos jogadores o mundo é realmente simulado (mobs, culturas, redstone) e view-distance até onde os chunks são enviados aos jogadores. Ambas são 10 por predefinição. Baixar simulation-distance é muitas vezes o maior ganho isolado: experimente entre 6 e 8, e mantenha view-distance um pouco mais alta para que o mundo continue a parecer 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 a explorar em direções diferentes obrigam-no a fazê-lo constantemente. O plugin (ou mod) Chunky gera o mapa antecipadamente:

chunky radius 5000
chunky start
chunky pause
chunky continue

Execute-o quando ninguém estiver a jogar (uma pré-geração em curso faz o servidor mostrar "Can't keep up", e isso é normal) e coloque-o em pausa quando entrarem jogadores.

3. Entidades e farms

Farms de mobs, salas de aldeões e montes de itens são o desgaste constante mais comum. No Paper e no Spigot, entity-activation-range em spigot.yml controla quão perto um jogador tem de estar para que uma entidade receba ticks completos, e merge-radius junta itens largados e orbes de experiência. Limite as farms de mobs com um plugin ou uma regra, e limpe os montes de itens esquecidos.

4. Funis e redstone

Cadeias grandes de funis são pesadas. Em spigot.yml, ticks-per.hopper-transfer define com que frequência movem itens, e hopper.disable-move-event do Paper acelera-os bastante, mas estraga os plugins de proteção que dependem desse evento. Para a redstone, misc.redstone-implementation: ALTERNATE_CURRENT do Paper pode reduzir muito o lag do pó de redstone, mas altera o comportamento do pó, por isso teste primeiro os seus mecanismos.

5. O plugin ou mod do seu perfil

Se o perfil do spark aponta para um plugin ou mod, a solução é essa: atualize-o, reduza a sua configuração ou substitua-o. Nenhuma quantidade de RAM torna mais rápido um plugin mal escrito.

"O TPS está em 20 mas continua com lag"

Este é o caso mais confuso, e quase sempre se trata de um bloqueio de tick: a maioria dos ticks é rápida, mas de vez em quando um demora centenas de milissegundos. A média mantém-se em 20, mas todos sentem uma paragem.

• Verifique o tempo de tick máximo em /spark tps, ou execute /spark tickmonitor. Picos de várias centenas de milissegundos confirmam-no.
• A causa habitual é um plugin à espera na thread principal: a obter skins ou cabeças de jogadores da internet, a publicar num webhook, a procurar atualizações ou a verificar uma licença, ou a gravar um ficheiro ou base 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 à espera parece inativa. Use /spark profiler start --thread * para captar onde vai o tempo, incluindo esperas, e procure chamadas de rede ou de ficheiros no Server thread.

A solução está no plugin: chamadas assíncronas, ou outro plugin. Mais RAM, um CPU mais rápido ou uma ligação melhor não ajudam, porque ao servidor não falta nada; está à espera.

Quando a resposta é mesmo RAM ou CPU

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

• O que mais importa é a velocidade do CPU por núcleo. Se o spark mostra o Server thread ocupado com o trabalho normal do mundo (entidades, chunks, ticks de blocos) e o MSPT está alto, um CPU mais rápido ajuda onde mais núcleos não ajudariam.
• A RAM só ajuda quando falta. Sinais: o servidor reinicia ao atingir o limite de memória, ou as pausas de recolha de lixo dominam o perfil. Acima do que o mundo e os mods precisam, mais RAM não faz nada pela velocidade dos ticks, e um heap sobredimensionado e sem afinação pode tornar as pausas de recolha de lixo mais longas.

Quanta RAM um servidor precisa, e as flags de arranque que mantêm a recolha de lixo curta, estão explicadas em quanta RAM precisa um servidor de Minecraft. A escolha entre Paper, Purpur e os restantes está em o melhor software para servidores de Minecraft.

O lag e o seu servidor HytHost

Todos os planos de Minecraft da HytHost funcionam no mesmo hardware: CPU Ryzen 7 e Intel i9 com boost até 5.0 GHz, memória DDR4 e armazenamento NVMe, ou seja, a velocidade por thread de que o Minecraft depende. O spark já faz parte do Paper, por isso pode fazer perfis a partir da consola desde o início.

Se o perfil mostrar que o servidor tem mesmo falta de memória para o seu mundo e os seus mods, suba de plano a partir do painel; o mundo fica onde está. Se mostrar um plugin ou uma farm, resolva isso primeiro: é gratuito e funciona em qualquer plano. Veja alojamento de Minecraft, ou os planos maiores em alojamento de Minecraft premium a partir de €11.65/mês.