Spark profiler: encontrar a causa real do lag
TPS 20 e servidor engasgando não são contraditórios. O spark mede quanto tempo cada tick realmente custa e mostra, linha por linha, para onde esse tempo está indo.
PorEquipe StreetHosting·Time de infraestrutura e suporte da StreetHosting
TPS e MSPT: qual número olhar
O servidor de Minecraft processa o mundo em ticks, vinte por segundo. Cada tick tem um orçamento de cinquenta milissegundos para fazer tudo: mover mobs, calcular redstone, crescer plantação, rodar plugin, salvar chunk. Se o trabalho couber nesse orçamento, o tick termina e o servidor espera o próximo. Se não couber, o tick atrasa e o TPS cai.
| MSPT médio | TPS resultante | Como o jogador sente |
|---|---|---|
| Até 25 ms | 20 | Nada. Folga confortável |
| 25 a 40 ms | 20 | Ainda liso, mas sem margem para pico |
| 40 a 50 ms | 20 | Engasgos ocasionais nos picos |
| 50 a 70 ms | 16 a 19 | Mobs travando, blocos demorando a quebrar |
| Acima de 100 ms | Abaixo de 10 | Servidor praticamente injogável |
Repare no que a tabela mostra: entre 25 e 50 milissegundos o TPS marca vinte o tempo todo, e mesmo assim o servidor foi de confortável a quase estourando. É por isso que o MSPT é o número honesto. O TPS só conta a história depois que o estrago já aconteceu.
Olhe também o MSPT máximo, não só o médio. Um único tick de 400 ms no meio de um minuto tranquilo some na média mas é exatamente a travada que o jogador reclamou no Discord. Para a explicação básica do conceito, veja o que é TPS e como melhorar.
Instalar o spark
O spark tem build para cada plataforma, e a instalação é a de qualquer plugin ou mod.
- Baixe a build correspondente à sua plataforma: Bukkit e derivados para Paper, Spigot e Purpur, ou a build de Fabric ou de Forge se for servidor modado.
- Coloque o jar em
plugins/ou emmods/, conforme o caso. - Reinicie o servidor e confirme que ele carregou no log de boot.
- Verifique que a sua conta tem a permissão do plugin, senão os comandos não respondem.
Muitas builds modernas de Paper e vários modpacks já trazem o spark incluído. Rode /spark antes de instalar: se responder, está tudo pronto.
Os comandos que importam
| Comando | O que faz | Quando usar |
|---|---|---|
| /spark tps | Mostra TPS e MSPT em várias janelas de tempo | Primeiro comando sempre. Confirma se existe problema |
| /spark health | Memória, garbage collector, CPU e disco | Quando a suspeita é hardware ou heap, não plugin |
| /spark profiler start | Começa a gravar a amostragem das threads | Com o lag acontecendo, no horário de pico |
| /spark profiler stop | Encerra e devolve o link do resultado | Depois de três a cinco minutos gravando |
| /spark profiler start --timeout 300 | Grava por um tempo fixo e encerra sozinho | Quando você não vai estar online para parar |
| /spark profiler start --thread * | Perfila todas as threads, não só a principal | Investigar tarefa assíncrona ou I/O de disco |
Comece sempre por /spark tps e /spark health. Se o MSPT está confortável e a memória saudável, o lag que os jogadores relatam pode ser de rede e não de servidor, e nenhum profile vai mostrar isso.
Quando e por quanto tempo perfilar
Essa é a parte que a maioria erra. Um profile tirado com o servidor vazio às três da manhã prova apenas que um servidor vazio não tem lag.
- Perfile sob carga real. Com os jogadores que costumam estar online no pior horário, fazendo o que costumam fazer.
- Três a cinco minutos. Abaixo disso a amostragem captura ruído. Muito acima, o pico que você quer investigar se dilui numa média longa e some.
- Comece um pouco antes do evento. Se o lag aparece quando abre a loja, quando alguém liga a fazenda de mobs ou quando o mundo salva, ligue o profiler alguns segundos antes.
- Um profile por hipótese. Guarde o link de cada gravação. Comparar o antes e o depois de uma correção vale mais do que qualquer teoria.
Não tire conclusão de profile com menos de um minuto. O spark trabalha por amostragem: pouco tempo significa poucas amostras, e poucas amostras produzem percentuais que mudam a cada tentativa.
Como ler a árvore de chamadas
O resultado do spark é uma árvore. No topo ficam as threads, e dentro de cada uma as chamadas que consumiram tempo, cada uma com um percentual. A regra de leitura é simples e sempre a mesma.
- Abra a thread principal do servidor. É ela que define o MSPT, e portanto o TPS.
- Ignore os percentuais pequenos. Comece pelo ramo mais gordo, aquele que sozinho leva um pedaço grande do total.
- Expanda esse ramo e repita: dentro dele, siga de novo o filho de maior percentual.
- Continue descendo até o nome do pacote deixar de ser
net.minecraftouorg.bukkit. O primeiro pacote de terceiro que aparecer é o consumidor real. - Se o ramo termina inteiro dentro do código do jogo, o consumo é do próprio mundo: entidades, chunks, redstone. Aí a correção é de configuração ou de conteúdo, não de plugin.
O tickdoc faz esse caminho por você: você cola o link do profile e ele aponta qual plugin, mod ou tarefa está pesando, separa o que é ajuste de configuração do que é limite de hardware e ordena as correções por impacto. Ele fica na página de ferramentas gratuitas junto com os outros utilitários de diagnóstico.
Os padrões clássicos de lag
Depois de ler alguns profiles, você começa a reconhecer as formas. Estas cinco cobrem quase tudo que aparece num servidor comum.
Entidade demais
Ramos ligados ao tick de entidade e a buscas por entidades próximas dominando o percentual. Costuma ser fazenda de mobs, animais acumulados numa fazenda de jogador, itens no chão que ninguém pegou ou armazenamento com centenas de hoppers. A correção é limitar densidade de mobs, ajustar o agrupamento de entidades da build e caçar a construção culpada pelas coordenadas.
Geração de chunk
Ramos de geração e carregamento de terreno pesando muito. Acontece quando alguém está explorando de elytra em terreno novo, ou quando um plugin de mundo dinâmico gera área o tempo todo. Se o mundo tem borda definida, gerar o terreno antes com uma ferramenta de pré geração tira esse custo do horário de pico.
Plugin em tick síncrono
Um pacote de plugin aparecendo alto na thread principal. Quase sempre é uma tarefa que deveria ser assíncrona: consulta a banco de dados, chamada a uma API externa, leitura de arquivo grande. O tick fica parado esperando a resposta. Sem código na mão, a saída é atualizar o plugin, ajustar a frequência da tarefa na configuração dele ou trocar por uma alternativa.
Garbage collector
No /spark health aparecem pausas de coleta longas e frequentes. Aqui o inimigo não é um plugin específico, é a JVM devolvendo memória de forma desajeitada. As Aikar Flags existem exatamente para isso, quebrando a pausa grande em várias pausas curtas.
I/O de disco
Chamadas de escrita e salvamento de região consumindo tick, muitas vezes concentradas de tempos em tempos. É o autosave do mundo em disco lento, ou backup rodando no mesmo volume durante o horário de jogo. Mover o backup para fora do pico resolve grande parte dos casos.
- Profile tirado sob carga real, não com servidor vazio
- Pelo menos três minutos de gravação
- Ramo de maior percentual identificado até o pacote de terceiro
- Uma correção aplicada por vez
- Novo profile no mesmo horário para comparar
Configuração ou limite de máquina
A pergunta que o profile responde melhor do que qualquer outra coisa é se vale a pena continuar ajustando ou se chegou a hora de trocar de hardware. O critério é a forma da árvore.
| O que o profile mostra | Diagnóstico | O que fazer |
|---|---|---|
| Um ramo levando fatia grande do total | Problema pontual e corrigível | Atacar aquele plugin, entidade ou tarefa |
| Tempo espalhado por igual, sem dominante | A máquina está no limite | Reduzir carga ou subir de plano |
| Pausas de coleta de memória frequentes | JVM mal ajustada ou heap curto | Aikar Flags e revisão de memória |
| Picos em horário fixo | Tarefa agendada, backup ou autosave | Mover a tarefa para fora do pico |
Quando a conclusão for capacidade, lembre que Minecraft depende quase tudo de uma thread só. Mais núcleos não ajudam tanto quanto núcleos mais rápidos, e é por isso que uma VPS Ryzen com clock alto rende mais em MSPT do que uma máquina com o dobro de núcleos e clock baixo. Se você prefere não administrar servidor, os planos Minecraft Pro já entregam esse tipo de hardware pronto.
E antes de qualquer troca, passe pela lista de ajustes que costuma devolver MSPT sem custo nenhum, reunida em como reduzir o lag no servidor Paper.
Perguntas frequentes
- Qual a diferença entre TPS e MSPT?
- TPS conta quantos ticks o servidor executou por segundo, com teto de 20. MSPT mede quanto tempo cada tick levou. Como o orçamento de um tick é 50 ms, o TPS só cai depois que o MSPT passa de 50. Um servidor a 45 ms de MSPT marca TPS 20 e já está no limite.
- Meu TPS está 20 mas o servidor engasga. Por quê?
- Porque a média esconde os picos. O TPS é uma média de vários segundos, e um único tick de 400 ms some nessa média enquanto o jogador sente a travada. Olhe o MSPT máximo, não só o médio, e tire um profile durante o engasgo.
- Por quanto tempo devo deixar o profiler rodando?
- De três a cinco minutos, com o servidor sob carga real. Menos que isso captura ruído, e muito mais dilui o pico numa média longa. Se o lag acontece em momentos específicos, comece a gravar pouco antes do momento.
- O spark deixa o servidor mais lento?
- O custo é baixo e aceitável durante uma investigação, porque o spark amostra as threads em vez de instrumentar cada chamada. Ainda assim, encerre o profiler depois de coletar o que precisa em vez de deixar rodando o dia inteiro.
- O profile não aponta nenhum plugin. E agora?
- Quando o tempo está espalhado por igual entre partes do próprio jogo, sem ramo dominante, o problema não é configuração e sim capacidade. Isso aparece em servidores com muita gente, muitas entidades ou modpack pesado numa CPU sem clock suficiente.
- Spark substitui o timings?
- Sim. O timings foi descontinuado nas builds modernas de Paper e o spark é o sucessor recomendado. Ele mostra mais coisa, inclui as threads fora da principal e mede memória e garbage collector no mesmo relatório.
Próximo passo
Ver Minecraft Pro
Host gerenciado com Ryzen, modpacks, Paper otimizado e suporte técnico.
Guias relacionados
Como reduzir lag em servidor Minecraft Paper (TPS e mspt)
Lag não é 'culpa do host' até você medir: mspt alto vem de mundo, configuração e código rodando no tick. Este texto prioriza diagnóstico antes de tunagem agressiva.
O que é TPS no Minecraft e como melhorar (guia completo)
TPS é o relógio do servidor: 20 significa mundo fluido, abaixo disso tudo atrasa. MSPT mostra quanto cada tick custa em milissegundos. Medir antes de tunar separa problema de plugin de host errado.
Aikar Flags: otimizar a JVM do servidor Minecraft
Travadas periódicas costumam ser o garbage collector mal ajustado. As Aikar Flags configuram o G1GC para coletar memória em pequenas pausas, suavizando o TPS em horário de pico.