Baixar a simulation-distance não é o mesmo que baixar a view-distance. Uma altera a área, centrada no jogador, que o servidor simula; a outra controla a quantidade de dados de terreno que envia aos jogadores. Uma paisagem distante pode continuar visível, mesmo que uma farm aí situada já não se comporte como o seu dono espera.
Essa distinção importa mais do que encontrar uma configuração rotulada como “otimizada”. Um servidor mais calmo não é grande melhoria se os aldeões deixarem de reabastecer os seus stocks ou se um local de AFK estabelecido deixar de funcionar. O objetivo é eliminar o trabalho de que a sua comunidade pode prescindir e, depois, verificar se a jogabilidade que queria preservar continua a funcionar.
Este tutorial abrange servidores modernos de Minecraft Java Edition. As definições de distância aplicam-se ao Vanilla, ao Spigot e ao Paper; os comandos de plugins e as definições YAML estão identificados em separado. Não é uma receita universal para Bedrock, modpacks ou Folia. Confirme a documentação para a versão exata do seu servidor: as referências atuais podem descrever versões mais recentes, e nem os valores predefinidos nem a estrutura dos ficheiros se mantêm fixos para sempre.
1. Meça o problema enquanto ele está a acontecer
Registe a sua versão do Minecraft, o software e a build do servidor, o número de jogadores e o que os jogadores estão a fazer quando ocorre a lentidão. Uma sala de trocas movimentada e um grupo a explorar terreno novo são cargas de trabalho diferentes. Fazer profiling a um servidor vazio não explica nenhuma delas; a documentação do Paper exige explicitamente que o problema esteja a ocorrer durante a recolha.
No Paper, o spark vem incluído desde a versão 1.21. No Spigot, instale primeiro um plugin spark autónomo compatível; os comandos seguintes não estão integrados num servidor Vanilla sem modificações.
Execute-os no jogo com as permissões necessárias:
/spark tps
/spark profiler start --timeout 600
O comando do profiler regista durante dez minutos e devolve o URL de um relatório. Guarde esse relatório junto da sua configuração e das notas sobre a carga de trabalho.
À taxa de ticks normal, o Minecraft tem como objetivo 20 TPS, o que deixa 50 milissegundos por tick. O MSPT descreve quanto tempo demoram os ticks, pelo que revela pressões que uma leitura de TPS pode, por si só, esconder. Compare o MSPT mediano e do percentil 95: o segundo ajuda a expor ticks lentos recorrentes, mas pode falhar picos raros. Verifique também o máximo, em vez de tratar um percentil saudável como prova de que nada bloqueou.
Para problemas intermitentes, o tick monitor do spark pode assinalar os ticks que excedem esse orçamento:
/spark tickmonitor --threshold-tick 50
Registe o que aconteceu no mesmo momento. Se os tempos de tick se mantiverem saudáveis durante a queixa, investigue a taxa de fotogramas do cliente ou as condições de rede antes de sacrificar a jogabilidade do servidor.
2. Faça uma cópia de segurança e identifique que definições se aplicam realmente
Antes de editar, pare o servidor de forma limpa e faça uma cópia de segurança dos mundos, dos ficheiros de configuração e dos dados dos plugins. Guarde a cópia fora do diretório do servidor em execução e confirme que a consegue restaurar. Uma cópia da configuração facilita a reversão; uma cópia dos mundos protege o trabalho que está por trás deles.
Utilize um editor de texto, preserve a indentação do YAML e altere uma coisa de cada vez por experiência. Depois, inicie o servidor normalmente e inspecione o registo de arranque à procura de erros de configuração. Não utilize o /reload nem um carregador a quente de plugins como atalho; recarregar plugins pode deixar dependências e estado inconsistentes.
No Vanilla, comece pelo server.properties. No Spigot e no Paper, inspecione também o spigot.yml: as definições de distância por mundo podem substituir o ficheiro de propriedades.
Este fragmento mostra a herança, não uma predefinição de desempenho:
world-settings:
default:
view-distance: default
simulation-distance: default
Aqui, default indica a estas opções que usem o server.properties. Integre as chaves na secção existente; não substitua o ficheiro todo nem adicione um segundo bloco world-settings. Verifique também as secções de mundos com nome, porque um valor específico de um mundo pode substituir a definição partilhada.
Se substituir substituições numéricas por herança, trate isso como uma alteração separada e registe uma nova linha de base. Caso contrário, pode alterar várias distâncias efetivas antes do seu primeiro teste controlado.
3. Separe a visibilidade do terreno da simulação
Ambas as distâncias são medidas em chunks em redor do jogador, e não em blocos nem em diâmetro.
- A view-distance controla a quantidade de dados do mundo enviados ao cliente. Baixá-la troca a visibilidade do terreno distante por menos trabalho associado à manutenção dessa vista.
- A simulation-distance controla a área de ticking centrada no jogador. Reduzi-la pode diminuir o trabalho de simulação, mas também altera a área em que as farms e entidades próximas funcionam.
A view distance não é gratuita só porque parte do terreno está fora da simulation distance. Do mesmo modo, reduzi-la não substitui a correção de um plugin dispendioso. Escolha a primeira experiência com base no perfil e no compromisso de jogabilidade que consegue aceitar.
Experimente uma alteração de distância
Suponha que o seu server.properties atual contém:
view-distance=10
simulation-distance=10
Se o perfil apontar para trabalho de ticking nas áreas carregadas, uma experiência possível é manter a view distance inalterada e reduzir um pouco a simulation distance:
view-distance=10
simulation-distance=8
Estes números são ilustrativos, não são valores predefinidos universais nem uma predefinição testada da SharpHeberg. Se a sua view distance atual for diferente, deixe o seu próprio valor como está. Reinicie de forma limpa, reproduza a carga de trabalho original e recolha outro relatório antes de fazer qualquer redução adicional.
Se, em vez disso, o perfil sugerir que o problema é manter ou enviar terreno distante, teste a view distance em separado. Não baixe as duas definições em conjunto para depois tentar adivinhar qual ajudou.
A simulation distance não é um regulamento completo para farms. Os tickets de chunks, que mantêm chunks carregados por motivos específicos, e os requisitos de proximidade do jogador diferem consoante as mecânicas e as versões. “Carregado” não garante que o spawning, o crescimento de culturas, as entidades e as block entities se comportem todos da mesma forma. Verifique os requisitos da sua farm em particular, em vez de presumir que uma única distância garante o funcionamento.
O spawning e o despawning naturais também têm as suas próprias regras de distância; o mob-spawn-range do Spigot e as definições de despawn do Paper acrescentam mais controlos. Se uma farm deixar de funcionar após a experiência, restaure primeiro a distância anterior. Não compense de imediato alterando várias definições de spawn.
4. No Spigot ou no Paper, inspecione o trabalho das entidades antes de cortar alcances
Se o perfil apontar para o processamento de entidades, inspecione a área afetada. Procure itens largados que se acumulam, currais sobrelotados ou uma sala de trocas a fazer trabalho desnecessário. Coordene-se com os donos antes de alterar construções. É mais fácil avaliar a redução de uma fonte identificada de trabalho excessivo do que enfraquecer o comportamento das entidades em todo o lado.
Duas opções do spigot.yml com nomes semelhantes têm funções diferentes:
| Definição | Unidade | O que controla |
|---|---|---|
entity-activation-range |
Blocos | A que distância dos jogadores as entidades têm de estar para executar ticks normalmente; o comportamento fora do alcance é limitado. |
entity-tracking-range |
Blocos | A que distância as entidades são enviadas aos jogadores, afetando quando se tornam visíveis. |
Estes são controlos de entidades, e não as distâncias em chunks acima descritas. Um alcance de tracking mais baixo pode fazer os mobs aparecerem abruptamente; não equivale a reduzir a carga de trabalho da sua IA.
As alterações à ativação exigem especial cuidado em torno de iron farms e aldeões. Os guias da comunidade documentam farms estragadas e problemas de reabastecimento causados por uma ativação demasiado agressiva ou por alterações aos aldeões inativos. Deixe estas definições em paz, a menos que o profiling justifique o compromisso e, nesse caso, teste a categoria de entidades afetada em vez de copiar uma predefinição completa.
O mesmo cuidado aplica-se ao nerf-spawner-mobs, à temporização dos hoppers e às alterações à fusão de itens: alteram o comportamento, e não apenas o consumo de recursos. Não faça cortes generalizados nos limites de mobs nem instale a eliminação agendada de entidades como primeira resposta ao lag.
5. Trate as definições do Paper como controlos específicos de cada versão
O Paper tem camadas de configuração adicionais. A sua estrutura documentada inclui o config/paper-global.yml para definições globais e o config/paper-world-defaults.yml para definições de mundo partilhadas. O paper-world.yml de um mundo pode substituir essas predefinições de mundo.
Localize esse ficheiro de substituição com a documentação da sua build. As estruturas de diretórios de mundos e dimensões variam; copiar um caminho de um tutorial mais antigo pode levá-lo ao sítio errado. Copie apenas as definições que pretende substituir, e não o ficheiro de predefinições inteiro.
O Paper expõe controlos para spawning, despawning, colisões e comportamento dos hoppers. Estas são opções para um problema identificado, não uma lista de verificação a cumprir. Por exemplo, desativar o evento de movimento do hopper pode estragar plugins de proteção que dependem dele. Uma pequena melhoria de temporização não justificaria contornar silenciosamente uma regra do servidor.
A referência do spigot.yml citada é mantida pelo Paper e inclui comportamento específico do Paper. Não presuma que todas as opções aninhadas que documenta existem ou se comportam de forma idêntica no Spigot puro. Consulte a configuração gerada para a sua implementação e versão antes de adicionar uma chave.
6. Siga o perfil para além das definições de distância
Investigue o trabalho dos plugins
Se o relatório apontar para uma tarefa de um plugin, guarde o relatório e verifique a configuração, a compatibilidade e as notas de lançamento desse plugin. O Paper recomenda explicitamente partilhar um relatório spark relevante com os programadores de plugins ao investigar problemas de desempenho.
Sempre que possível, reproduza o problema numa cópia de teste com backup. Altere uma funcionalidade ou um plugin de cada vez, respeitando as dependências, e depois repita a mesma atividade. Evite desativar plugins de proteção ou de economia no servidor em produção só para ver se os TPS sobem.
Mantenha também a afinação de Java e de memória orientada por evidências. Reveja o comportamento do garbage collection e os requisitos de Java para a build exata do seu servidor antes de alterar as opções de arranque. Uma coleção copiada de flags de GC não é um passo de otimização universal.
Pré-gere apenas quando a geração for o problema
Quando a lentidão coincide com a exploração, compare a deslocação por terreno existente com a deslocação para terreno novo. Se o profiling indicar que a geração de chunks é o gargalo, a pré-geração desloca esse trabalho de geração para antes do jogo normal. O Chunky fornece ferramentas para esse fim.
Escolha a área e as dimensões pretendidas, verifique a capacidade de disco e de cópias de segurança e agende o trabalho para fora das horas de maior movimento. Teste primeiro uma área limitada. A pré-geração não elimina o custo de carregar ou enviar chunks existentes, nem de executar farms dentro deles.
Os guias da comunidade divergem quanto à abrangência com que a pré-geração deve ser recomendada para servidores modernos. Trate-a como uma resposta a uma pressão de geração medida, e não como manutenção obrigatória de qualquer instalação Paper.
7. Verifique a jogabilidade antes de manter a alteração
Repita a carga de trabalho original com um número e uma distribuição de jogadores comparáveis. Mantenha juntos os relatórios spark de antes e depois, a diferença de configuração e as notas. Repita a comparação se as condições tiverem mudado substancialmente.
Depois, teste o servidor tal como os jogadores o utilizam:
- Execute as farms importantes a partir das suas posições de AFK habituais, incluindo a recolha e o transporte.
- Verifique as trocas e o reabastecimento dos aldeões durante um ciclo de trabalho normal.
- Execute os sorters e os clocks de hoppers durante o tempo suficiente para revelar itens perdidos ou temporização alterada.
- Verifique a visibilidade e o comportamento dos mobs durante a deslocação e teste cada mundo afetado.
Mantenha uma alteração apenas se a melhoria medida for útil e o compromisso de jogabilidade for aceitável. Se o benefício não for claro, restaure o valor anterior. Nunca desative a gravação do mundo para que um gráfico de desempenho pareça melhor.
Se o gargalo restante parecer ser a capacidade do alojamento, utilize o relatório para orientar essa conversa. Pode consultar o alojamento Minecraft da SharpHeberg em conjunto com a sua carga de trabalho e os seus requisitos. As escolhas de alojamento e as alterações de configuração merecem o mesmo teste: o servidor funciona melhor preservando a forma como a sua comunidade joga?
Leitura relacionada: O custo real de um servidor Minecraft de alto desempenho em 2025. Trate quaisquer preços desse artigo mais antigo como históricos, e não como tarifas atuais.
Fontes
Paper — referência do spigot.yml
Paper — configuração de mundos
Minecraft optimization — guia da comunidade
spark — encontrar picos de lag