O Spark é um profiler: registra onde o servidor gasta tempo enquanto um problema acontece. No Paper moderno, ele vem integrado; a documentação recomenda começar uma captura durante o sintoma e usar o relatório para analisar métodos, plugins, tarefas e threads. Um perfil coletado quando o servidor está saudável dificilmente explica uma travada que aparece horas depois.

Este guia ajuda a transformar uma URL de relatório numa hipótese verificável. TPS e MSPT são indicadores do estado geral; o profiler mostra o trabalho associado à amostra. Nenhum deles, sozinho, prova que um plugin está defeituoso.

Defina a pergunta antes de gravar

Descreva o sintoma em termos reproduzíveis: “o MSPT sobe quando três jogadores exploram terreno novo”, “o tick degrada após usar determinada arena” ou “a lentidão aparece junto do backup”. Registre horário, quantidade de jogadores, mundo, atividade e versão. Essa moldura ajuda a escolher duração e período da captura.

Uma pergunta delimitada reduz a chance de interpretar qualquer seção grande como culpada. Perfil curto demais pode não capturar uma tarefa rara; perfil muito longo inclui vários cenários e fica difícil de correlacionar. Escolha uma janela suficiente para o problema aparecer e use a documentação do Spark para selecionar a opção apropriada.

Inicie somente durante o problema

Em Paper, a documentação atual mostra o comando /spark profiler start --timeout 600 como início de uma amostra com duração limitada. Use o comando da versão instalada e obtenha a URL quando o profiler concluir. O Spark tem outras opções; leia a ajuda e a referência oficial antes de alterar flags para uma pergunta diferente.

Avise a equipe que uma captura será feita e evite combinar com mudanças de configuração durante a janela. Anote o momento exato e o que os jogadores faziam. Se o sintoma não ocorrer, descarte a amostra como inconclusiva e programe outra sob as condições certas. Não use um perfil de baixo tráfego para concluir sobre carga de pico.

Observe MSPT e TPS com contexto

TPS informa a cadência efetiva do servidor em relação ao alvo, enquanto MSPT mede quanto tempo o tick consome. Um servidor pode sustentar o alvo enquanto o tempo médio fica abaixo do orçamento por tick, mas picos ainda causar atraso percebido. Compare valor, distribuição ao longo do tempo e momento do sintoma, não somente uma média final.

O profiler amostra execução; seu resultado depende da janela e da frequência de amostragem. Um trabalho pequeno pode ser importante se ocorrer em todos os ticks. Um trabalho grande e raro pode explicar um pico isolado, mas não o lag contínuo. Correlacione gráfico temporal e seções detalhadas do relatório.

Leia as áreas de execução com cautela

Procure por pacotes, plugins ou caminhos de chamada que ocupem tempo significativo durante a amostra. Se o relatório organiza resultados em árvore, expanda do trabalho geral até a seção específica e observe os pais: um método filho aparece por causa do chamador. Um nome visível dentro de um plugin não significa automaticamente que esse plugin originou a solicitação.

Tempo associado ao scheduler, entidade, mundo, chunk ou rede precisa ser interpretado com o que acontecia. Várias entidades podem refletir uma fazenda em uso, um evento ou comportamento normal. Um plugin pode receber custo herdado do servidor quando realiza uma operação; compare amostras e reproduza com um caso controlado antes de atribuir culpa.

Separe trabalho da thread principal de tarefas assíncronas. Trabalho assíncrono pode pressionar CPU e armazenamento sem ocupar o tick do mesmo modo, e uma tarefa fora da thread principal ainda pode competir por recursos do processo. Use as vistas do Spark e a documentação para distinguir essas situações.

Investigue geração, entidades e plugins como hipóteses

Quando geração de chunks coincide com o atraso, compare uma área já explorada com uma região nova em cópia isolada. Se o custo se concentra em plugin, identifique qual funcionalidade estava ativa e confira a versão e a configuração. Se entidades predominam, localize o mundo, a região e a atividade que as criou antes de reduzir limites globais.

Desabilitar plugins em produção altera funcionalidades e pode afetar dados. Reproduza uma suspeita numa instância de teste com backup e dependências preservadas. Se a comunidade do plugin oferece suporte, compartilhe o relatório somente depois de conferir se sua publicação não expõe informações sensíveis e inclua o contexto do cenário.

Compare perfis de forma justa

Para comparar uma configuração antes e depois, mantenha a carga e a duração parecidas: mesmos mundos, jogadores de teste e ações. Registre uma mudança por vez, a versão da JVM, a configuração relevante e as métricas do intervalo. Mudanças simultâneas de distância, plugin e hardware impossibilitam saber o que afetou o resultado.

Uma segunda captura deve responder à primeira hipótese. Se retirar uma operação suspeita não altera o perfil ou o sintoma, reavalie a hipótese em vez de insistir nela. Perfis são amostras; repetição e reprodução aumentam confiança. Para eventos raros, registre também logs e métricas por mais tempo e capture quando ocorrer.

Proteja e compartilhe o relatório

Uma URL de perfil pode revelar plugins, nomes de métodos, estrutura e configuração técnica. Trate-a como informação operacional: compartilhe somente com pessoas que estão ajudando e siga as políticas da comunidade. Evite incluir dados pessoais de jogadores ou credenciais; nunca publique tokens, senhas ou dumps relacionados.

Se precisar de suporte do mantenedor, entregue a menor evidência útil: URL ou recorte relevante, versão, reprodução, horário e resultado esperado. O relatório sem uma pergunta explícita força outra pessoa a inferir o contexto. Explique também se a captura veio de produção ou homologação.

Transforme a conclusão numa ação pequena

Feche com uma hipótese, próximo teste e critério de sucesso. Exemplo: “a captura durante exploração apontou geração de chunks como parte do trabalho; vou pré-gerar uma área limitada em homologação, repetir a rota e comparar MSPT antes de decidir”. Isso é verificável e reversível. “O servidor precisa de mais RAM” não decorre automaticamente de um relatório de CPU.

A documentação do Paper descreve o fluxo de profiling com Spark e recomenda capturar durante o problema. Consulte também a documentação oficial do Spark para opções de relatório e o guia de diagnóstico do Paper para coletar contexto antes de pedir ajuda.

Fontes e referências

Documentação consultada em 2026-10-08. Os exemplos precisam ser conferidos na versão instalada; este guia não afirma que a configuração foi testada no seu ambiente.