Lag em servidor de Minecraft: descubra a causa antes de corrigir

Antes de mudar uma única configuração, descubra qual destes três tipos de lag você tem: o loop de ticks do servidor ficando para trás, a rede entre os jogadores e o servidor, ou o computador do próprio jogador sofrendo para desenhar o jogo. Rode /spark tps no seu horário mais cheio. Se a duração dos ticks ficar abaixo de 50 ms, o servidor está dando conta e o lag que os seus jogadores sentem vem de outro lugar.

A maioria dos "guias de otimização" pula essa etapa e entrega uma lista de configurações. Algumas ajudam, algumas pioram o jogo, e nenhuma resolve um problema que você ainda não encontrou. Este guia começa pelo diagnóstico.

Três tipos de lag (tick do servidor, rede, cliente)

Uma pequena observação técnica sobre os números, porque ela explica por que o TPS mente. O servidor mira 20 ticks por segundo, então cada tick tem um orçamento de 50 ms. O TPS nunca passa de 20, o que significa que um servidor que precisa de 10 ms por tick e outro que precisa de 48 ms marcam ambos 20,0 TPS. O primeiro aguentaria várias vezes a carga atual, o segundo está a uma fazenda de funis de começar a dar lag. O MSPT (milissegundos por tick) mostra essa folga, então acompanhe o MSPT, não o TPS.

Meça antes de mudar qualquer coisa

1. Escolha a hora certa. O lag que acontece no pico não dá para medir às cinco da manhã. As quatro horas mais cheias da nossa rede são das 14:00 UTC às 18:00 UTC no seu fuso horário, e a página pública de estatísticas do seu servidor mostra os seus próprios horários mais cheios.
2. Rode /spark tps. Ele mostra o TPS dos últimos 5 segundos a 15 minutos e a duração dos ticks como mínimo, mediana, percentil 95 e máximo. Uma mediana bem abaixo de 50 ms com percentil 95 acima disso indica picos, não sobrecarga constante. O /mspt do Paper dá a versão curta.
3. Rode /spark health. Ele acrescenta uso de CPU, memória e disco, para você ver de relance se a própria máquina está sem alguma coisa.
4. Leia o console. O aviso do vanilla Can't keep up! Is the server overloaded? Running 2034ms or 40 ticks behind (o console do servidor sempre o escreve em inglês) significa que o servidor ficou para trás e pulou à frente para se atualizar. Um por dia é ruído. Um por minuto é problema.
5. Anote a referência: horário, jogadores online, mediana e percentil 95 do MSPT, e onde os jogadores estavam (uma área nova, uma fazenda grande, um evento). Você vai comparar com ela depois de cada mudança.

Em um servidor sem spark, o /tick query do vanilla (Java Edition 1.20.3 e posteriores, nível de permissão 3) informa o tempo médio por tick e os seus percentis.

Pico 16:00 UTC

0003060912151821

Horários em UTC

Mais cheio às 16:00 UTC, com cerca de 17.845 jogadores, e mais vazio às 01:00 UTC. A hora mais cheia tem 2,6 vezes os jogadores da mais vazia.

Medido em 19 out. 2026, 22:55 UTCComo medimos

Como ler um perfil do spark

Quando os números dizem que o servidor está lento, o profiler diz por quê. A documentação do PaperMC sugere:

/spark profiler start --timeout 600

Isso amostra todas as threads por dez minutos e entrega um link para o relatório. Duas variações ajudam em problemas específicos:

• /spark profiler start --only-ticks-over 100 registra só os ticks mais lentos que 100 ms, o que separa picos curtos de lag do ruído de fundo normal.
• /spark tickmonitor --threshold-tick 100 imprime uma linha sempre que um tick leva mais de 100 ms, para você relacionar os picos ao que acontecia no jogo.

O perfil precisa rodar enquanto o lag acontece. Um perfil de um servidor vazio às 05:00 não diz nada sobre o lag das 18:00.

No visualizador, abra a thread do servidor e siga a maior porcentagem para baixo. Você procura o ramo para onde vai o tempo:

• O tick de entidades, muitas vezes com a IA dos mobs ou a busca de caminho dos aldeões por baixo, aponta para os mobs (próxima seção).
• As entidades de bloco, com os funis no alto da lista, apontam para cadeias de funis e sistemas de armazenamento.
• O trabalho com chunks (gerar, carregar, salvar) aponta para jogadores explorando terreno novo.
• O nome de um plugin na árvore de chamadas, ou no alto do detalhamento por plugin do visualizador, aponta para esse plugin. Anote o que ele estava fazendo (um tratador de eventos, uma tarefa agendada, uma chamada ao banco de dados) antes de culpá-lo, porque o mesmo plugin pode funcionar bem com outra configuração.

O spark também registra a coleta de lixo. Pausas frequentes de centenas de milissegundos apontam para pressão de memória, que /spark gc mostra ao longo do tempo. Faça também um perfil uma vez quando o servidor estiver bem, para saber como é o normal na sua configuração.

Os suspeitos de sempre (entidades, geração de chunks, redstone, plugins, coleta de lixo)

Entidades

Fazendas de mobs, salões de troca com aldeões, pilhas de itens largados, sistemas de carrinhos de minério e decorações com suportes de armadura, tudo isso faz tick. No Paper, /paper entity list mostra as entidades que fazem tick por tipo, e um filtro como /paper entity list minecraft:villager restringe a lista para você achar onde elas se acumulam. /paper mobcaps mostra o quanto os limites de mobs estão cheios, e /paper chunkinfo quantos chunks estão carregados e fazendo tick. As soluções são limites, não proibições: um teto de entidades por chunk, regras de fazenda com as quais os seus jogadores concordem e uma conversa com quem construiu o salão de 400 aldeões.

Geração de chunks

Gerar um chunk novo é uma das coisas mais caras que um servidor faz, e jogadores com elytra podem exigir dezenas por minuto. Pré-gere o mundo uma vez, com um plugin como o Chunky (/chunky radius 5000, depois /chunky start), nos horários vazios, e defina uma borda do mundo equivalente com /worldborder set 10000. A borda recebe um diâmetro e o raio do Chunky é a metade, então esses dois números descrevem o mesmo quadrado. Depois disso, explorar só carrega chunks do disco, o que é bem mais barato.

Redstone e funis

Relógios de redstone rápidos e cadeias longas de funis se acumulam. O Paper oferece duas alavancas em config/paper-world-defaults.yml. misc.redstone-implementation: ALTERNATE_CURRENT troca o pó de redstone por uma implementação mais rápida. hopper.disable-move-event: true deixa os funis mais baratos, mas quebra plugins que dependem desse evento, como alguns plugins de proteção e de filtro de funil, então teste antes. hopper.cooldown-when-full já vem ligado por padrão.

Plugins

Um plugin pesado aparece pelo nome no perfil. Os padrões comuns são placares, hologramas ou listas de jogadores que se refazem a cada tick, consultas a banco de dados ou à web feitas na thread principal, renderizadores de mapa percorrendo um mundo grande e verificações de anticheat sob carga. A solução costuma ser, primeiro, a configuração (intervalos de atualização, limites de renderização), depois uma atualização e por fim uma substituição.

Coleta de lixo

Se o spark mostra pausas de coleta longas ou frequentes, confira a memória antes de qualquer coisa: o -Xmx está pequeno demais para o mundo e os plugins, e o -Xms está com o mesmo valor? As flags recomendadas pelo PaperMC são um bom ponto de partida. Mais memória só ajuda quando o problema é a coleta, e num host compartilhado, alocar toda ela deixa o sistema operacional sem recursos.

Soluções que funcionam

Quando você sabe a causa, estas são as mudanças que costumam compensar, mais ou menos na ordem em que as tentaríamos:

A mudança de simulation-distance é maior do que parece. Em volta de cada jogador, o servidor faz tick de aproximadamente um quadrado de chunks, então ir de 10 para 6 o reduz de cerca de 21 por 21 chunks para 13 por 13, de uns 441 chunks para uns 169, enquanto os jogadores continuam vendo tão longe quanto o view-distance permitir.

Alguns conselhos populares não ajudam. Plugins que apagam todos os itens largados a cada poucos minutos tratam um sintoma e irritam os jogadores. Plugins de "otimização" que prometem mais TPS sem dizer o que mudam merecem um perfil antes e outro depois. E reiniciar a cada duas horas esconde os problemas em vez de achá-los.

Lag de rede visto de fora

Um detalhe surpreende muitos donos. O ping de status que as listas de servidores usam é respondido pelas threads de rede do servidor, não pelo loop de ticks, então um servidor pode ter muito lag no jogo e ainda assim responder ao nosso pinger em alguns milissegundos. Não conseguimos enxergar o lag de tick de fora, e é justamente por isso que o spark existe. Atrás de um Velocity, o pinger só conversa com o proxy.

O que o nosso pinger consegue ver é a rede. A página pública de estatísticas do seu servidor (/server/your-server/stats) mostra três coisas que valem a leitura:

• O tempo de resposta, quanto o servidor levou para responder ao nosso pinger, com mediana, faixa habitual e um gráfico. O nível é definido principalmente pela distância até o nosso pinger, na Europa Ocidental, então um servidor nos Estados Unidos não vai mostrar 10 ms ali, a menos que uma rede de proteção responda de um ponto próximo. Olhe o formato ao longo do tempo, não o valor.
• Os picos acima da faixa habitual. Se as respostas passam bem da faixa habitual só nos seus horários cheios, a máquina ou o link de rede está saturado nesses momentos. Se a faixa é larga o dia todo, desconfie da rota ou da rede do host.
• O registro de quedas. Lacunas curtas são reinícios ou crashes. As longas merecem uma olhada na página de status do seu host e nos seus relatórios de crash.

Pelo lado do jogador, peça aos afetados um traceroute até o seu endereço (tracert no Windows, traceroute no macOS e no Linux) e a região deles. Se todo mundo de um país tem lag e mais ninguém, é a rota, e mudar de lugar ou adicionar uma rede de proteção com um ponto próximo pode ajudar mais do que qualquer configuração. Jogadores que não conseguem conectar de jeito nenhum têm outros problemas, que o nosso guia de erros de conexão cobre.

Quando reiniciar, e quando não

Reiniciar não é de graça. Todo mundo que está online é expulso, e um jogador que cai no meio de uma luta num domingo à noite se lembra disso. Os nossos dados de quedas mostram como os donos realmente agendam os reinícios.

Nos 30 dias até 16 de outubro de 2026, 90 servidores da nossa lista ficaram jogáveis pelo menos 90% do tempo. 58 deles tiveram pelo menos uma queda, que contamos como três ou mais pings seguidos sem resposta jogável, e juntos somaram 515. Medidas do primeiro ping perdido ao último, metade das quedas acabou em menos de cinco minutos, e o décimo mais longo passou de duas horas. 375 das 515 (73%) duraram 15 minutos ou menos, o tempo de um reinício ou de um crash seguido de reboot.

Quando essas quedas curtas começaram? Um horário se destaca: 04:00 UTC, com 39 das 375, a cara dos reinícios noturnos agendados. Fora dessa hora, elas se distribuem de forma bem uniforme ao longo do dia. 64 das 375 (17%) começaram entre 14:00 e 18:00 UTC, as quatro horas mais cheias da nossa lista, que é mais ou menos a fração esperada se os horários de reinício fossem escolhidos ao acaso.

19%Quedas curtas que começaram nas quatro horas mais cheias da rede, últimos 30 dias

Medido em 19 out. 2026, 21:52 UTCComo medimos

Ao vivo, para os últimos 30 dias: 472 quedas em 83 servidores com 90% ou mais de uptime, com mediana de 5 minutos minutos, e 70% delas com 15 minutos ou menos. O horário de início mais comum das curtas é 04:00 UTC no seu fuso horário, e a hora mais vazia da rede é 01:00 UTC.

O que tirar disso:

1. Reinicie no seu próprio horário vazio, não numa hora redonda. O mapa de calor da sua página de estatísticas mostra qual é, e quando os servidores estão mais cheios mostra como isso muda por região. Se os seus jogadores estão espalhados por vários fusos, escolha o ponto mais baixo da sua curva, não a meia-noite.
2. Avise com uma contagem regressiva no chat, e que seja curta.
3. Reinicie por um motivo. Atualizações, um vazamento de memória que você está investigando, uma mudança de configuração que exige isso. Um reinício diário que não resolve nada continua custando uma expulsão por dia.
4. Ache o vazamento em vez de escondê-lo. Se a memória sobe até o reinício, /spark heapsummary mostra o que a está enchendo.

Reiniciar não resolve lag de tick. Uma fazenda que custa 30 ms por tick continua custando 30 ms por tick cinco minutos depois do reinício. O nosso relatório de uptime tem todos os números de quedas da lista.

Quando melhorar o hardware

Melhore o hardware quando o perfil indicar. Os sinais:

• O MSPT no pico continua acima de uns 40 ms depois de você cuidar dos suspeitos acima.
• O perfil mostra o tempo espalhado em trabalho comum do vanilla (entidades, chunks, atualizações de bloco) sem nenhum culpado restante.
• Em uma VPS, o top mostra o CPU steal (o valor st) subindo nos horários cheios, o que significa que os seus vizinhos estão usando núcleos pelos quais você paga.

Então compre primeiro velocidade por núcleo, porque o loop de ticks roda em um núcleo só. Mais RAM resolve só problemas de memória. Além disso, a resposta é dividir a carga: vários servidores atrás de um proxy Velocity, ou o Folia para um mundo muito grande, ambos tratados no nosso guia de software de servidor. Escolher hospedagem traz as perguntas para fazer antes de pagar pela máquina nova.