Você decide que serviços podemos ativar para análise, personalização e conteúdos externos.
Utilizamos cookies e tecnologias semelhantes no nosso site para personalizar conteúdos, integrar conteúdos externos e compreender melhor a uso de cada área.
Cookies necessários
Estas entradas asseguram funções essenciais, como segurança, estabilidade e processamento de formulários.
Seções opcionais
AnálisesMarketingPersonalizaçãoMídia externa
O tratamento de dados pode basear-se no seu consentimento ou em interesses legítimos. Nas configurações de cookies, pode rejeitar ou permitir cada categoria opcional.
Alguns serviços processam dados pessoais em outros países. Ao dar seu consentimento, você também aceita essa transferência. Encontre mais informações em nossa Política de Privacidade.
Pode voltar a abrir e ajustar sua seleção a qualquer momento. · 1.0.2
Descubra como otimizar servidores de Minecraft para melhorar o desempenho e deixar a jogabilidade mais fluida com dicas eficazes de configuração → Saiba mais
10 de novembro de 202621 min de leitura6 visualizações0 útil
O que acontece exatamente durante a otimização?
A otimização é importante para que os servidores de Minecraft funcionem sem travamentos. Por isso, se você tem um servidor público, reserve tempo suficiente para fazer esse processo. Só é possível alcançar o melhor resultado com bastante tempo e testes. Portanto, não é obrigatório seguir este guia à risca: ele serve para ajudar você a seguir na direção certa.
Na maioria dos casos, a otimização envolve alterar várias configurações do servidor, o que pode mudar bastante o comportamento dele. Entre outras coisas, algumas configurações são reduzidas, o que diminui a carga do servidor e pode melhorar o desempenho. Mas, para que a experiência geral dos jogadores não seja muito prejudicada, procure sempre encontrar um equilíbrio.
Vanilla
Infelizmente, as possibilidades de otimização de um servidor Vanilla são bastante limitadas, pois há poucas configurações disponíveis. Vamos tentar dar um pouco mais de potência ao servidor Vanilla com as seguintes medidas:
Distância de renderização
Uma medida bastante comum é reduzir a distância de renderização. O valor padrão é de 10 chunks, mas muitos jogadores usam bem menos, por exemplo, de 6 a 8. Alguns jogadores exageram na quantidade de chunks e a definem, por exemplo, como 32. Isso significa que o servidor precisa carregar e processar todos esses chunks, o que consome bastante desempenho.
Em um servidor Vanilla, é possível ajustar a distância de renderização no arquivo de configuração "server.properties". Para isso, altere o valor "view-distance". Para não limitar demais a experiência dos jogadores, recomendamos definir o valor como 5 ou 6, o que pode reduzir a carga do servidor em até 50%.
Já temos um artigo sobre isso no nosso guia, que você encontra aqui.
Compressão de dados
O servidor e os jogadores conectados trocam dados o tempo todo. Os movimentos dos jogadores são enviados ao servidor, que os encaminha aos demais jogadores. As ações dos jogadores e os eventos no mundo, como explosões, também são dados transmitidos repetidamente.
Para tornar essa troca mais eficiente, é possível dobrar o tamanho dos dados compactados. Assim, o servidor precisa de apenas 50% do esforço para trocar os mesmos dados com os jogadores. Para isso, ajuste o valor "network-compression-threshold" no arquivo de configuração "server.properties". O valor deve ser definido como 512. Também temos um artigo sobre isso no nosso guia, que você encontra aqui.
FAQ
Perguntas frequentes
A distância padrão é de 10 chunks. Reduzi-la para 5 ou 6 em server.properties (valor view-distance) pode diminuir a carga do servidor em até 50%, sem prejudicar muito a experiência dos jogadores.
O artigo aborda otimizações para servidores Vanilla, Forge, Bukkit, Spigot e Paper Spigot. O Paper Spigot oferece mais opções adicionais, incluindo limites de geração, alcance de ativação de entidades, geradores de mobs e redstone.
Em comparação com plataformas como Spigot ou Paper Spigot, o servidor Vanilla oferece poucas opções de configuração. Por isso, as principais otimizações se limitam à distância de renderização e à compressão de dados.
Não. O guia serve como orientação, não como uma receita obrigatória. Como as otimizações podem mudar bastante o comportamento do servidor, reserve tempo para testar e encontrar um bom equilíbrio entre desempenho e experiência dos jogadores.
Feedback
Este artigo foi útil?
Sua opinião nos ajuda a definir prioridades e a melhorar os conteúdos.
0 de 0 As avaliações consideraram este artigo útil.
Ajuda personalizada
As instruções não são suficientes?
A nossa equipe de suporte da ZAP conhece seu produto — descreva brevemente seu problema e ajudaremos pessoalmente.
O Zappy conhece este guia e te responde direto no chat.
Navegação
Minecraft
Hospedagem de servidores a partir de € 2,49 / mês, disponível imediatamente, com proteção DDoS incluída.
Assim como no Vanilla, infelizmente há poucas possibilidades de fazer ajustes diretamente no servidor, pois os arquivos de configuração disponíveis são muito pequenos. No entanto, é possível instalar mods adicionais para reduzir um pouco a carga do servidor.
Pré-carregamento de chunks
Uma forma de reduzir a carga do servidor é pré-carregar chunks. Assim, durante o jogo, o servidor só precisa carregar os dados dos chunks já armazenados, em vez de criar e gerar os chunks do zero. O ideal é iniciar esse processo à noite e deixá-lo rodando durante a madrugada.
Para isso, é necessário instalar um mod adicional. Você pode baixar um mod bastante adequado aqui.
Depois, instale o mod no servidor normalmente, conforme descrito nos nossos guias.
Antes de reiniciar o servidor, verifique se o valor "max-tick-time" no arquivo "server.properties" está definido como "-1". Caso contrário, o servidor pode travar. Também recomendamos disponibilizar pelo menos 8 a 10 GB de RAM, pois o processo consome bastante memória. Se necessário, você pode aumentar temporariamente a RAM durante a noite e reduzi-la novamente depois.
Informações
Observe que o mod mencionado acima talvez não seja compatível com a sua versão do Forge e que o processo pode ser diferente se você usar outro mod.
Depois de iniciar o servidor com o mod, abra o console. Recomendamos definir uma borda do mundo com raio de 16.000 blocos. Para isso, execute os seguintes comandos, um após o outro:
worldborder center 0 0
worldborder set 16000
Informações
Se necessário, substitua as coordenadas pelo centro do seu mundo para evitar que uma área seja "cortada" (por exemplo, se já houver construções nessa área).
Depois de definir a borda, você pode iniciar o pré-carregamento. Para isso, execute o seguinte comando:
pregen gen startWorldBorder
Agora, todos os chunks dentro da borda serão pré-carregados em sequência. Dependendo da quantidade de mods instalados, o processo pode levar até 8 horas. O progresso será informado periodicamente por mensagens no console. Quando o processo terminar, isso também será indicado no console!
Informações
Você pode manter o mod instalado no servidor mesmo depois que o processo terminar. Ele continuará otimizando os chunks durante o funcionamento e também funciona quando não há jogadores no servidor.
Bukkit
Distância de renderização
Uma medida bastante comum é reduzir a distância de renderização. O valor padrão é de 10 chunks, mas muitos jogadores usam bem menos, por exemplo, de 6 a 8. Alguns jogadores exageram na quantidade de chunks e a definem, por exemplo, como 32. Isso significa que o servidor precisa carregar e processar todos esses chunks, o que consome bastante desempenho.
É possível ajustar a distância de renderização de um servidor Bukkit no arquivo de configuração "server.properties". Para isso, altere o valor "view-distance". Para não limitar demais a experiência dos jogadores, recomendamos definir o valor como 5 ou 6, o que pode reduzir a carga do servidor em até 50%.
Já temos um artigo sobre isso no nosso guia, que você encontra aqui.
Compressão de dados
O servidor e os jogadores conectados trocam dados o tempo todo. Os movimentos dos jogadores são enviados ao servidor, que os encaminha aos demais jogadores. As ações dos jogadores e os eventos no mundo, como explosões, também são dados transmitidos repetidamente.
Para tornar essa troca mais eficiente, é possível dobrar o tamanho dos dados compactados. Assim, o servidor precisa de apenas 50% do esforço para trocar os mesmos dados com os jogadores. Para isso, ajuste o valor "network-compression-threshold" no arquivo de configuração "server.properties". O valor deve ser definido como 512. Também temos um artigo sobre isso no nosso guia, que você encontra aqui.
Limites de geração
Nesta etapa, as taxas gerais de geração de mobs no servidor são um pouco reduzidas. Em comparação com os valores padrão, a diferença quase não é perceptível. Ainda assim, em alguns lugares, como nas farms de mobs, a farm pode não funcionar como esperado.
Para ajustar essas configurações, edite o arquivo "bukkit.yml". Altere os seguintes valores em "spawn-limits":
monsters: 50 #Padrão: 70
animals: 10 #Padrão: 15
water-animals: 3 #Padrão: 5
ambient: 4 #Padrão: 15
Informações
Se quiser, você também pode ajustar os valores. Caso contrário, os valores acima são uma boa média.
Para melhorar ainda mais a geração de mobs, altere também o valor "monster-spawns" na seção "ticks-per" do arquivo "bukkit.yml":
Spigot
Distância de renderização
Uma medida bastante comum é reduzir a distância de renderização. O valor padrão é de 10 chunks, mas muitos jogadores usam bem menos, por exemplo, de 6 a 8. Alguns jogadores exageram na quantidade de chunks e a definem, por exemplo, como 32. Isso significa que o servidor precisa carregar e processar todos esses chunks, o que consome bastante desempenho.
Em um servidor Spigot, é possível ajustar a distância de renderização no arquivo de configuração "spigot.yml". Para isso, altere o valor "view-distance". Para não limitar demais a experiência dos jogadores, recomendamos definir o valor como 5 ou 6, o que pode reduzir a carga do servidor em até 50%.
Informações
Se preferir, você também pode definir o valor como 4. Isso pode ajudar bastante a reduzir o lag, por exemplo, em servidores de mundos de farm que executam a versão 1.13 ou superior.
Compressão de dados
O servidor e os jogadores conectados trocam dados o tempo todo. Os movimentos dos jogadores são enviados ao servidor, que os encaminha aos demais jogadores. As ações dos jogadores e os eventos no mundo, como explosões, também são dados transmitidos repetidamente.
Para tornar essa troca mais eficiente, é possível dobrar o tamanho dos dados compactados. Assim, o servidor precisa de apenas 50% do esforço para trocar os mesmos dados com os jogadores. Para isso, ajuste o valor "network-compression-threshold" no arquivo de configuração "server.properties". O valor deve ser definido como 512. Também temos um artigo sobre isso no nosso guia, que você encontra aqui.
Limites de geração
Nesta etapa, as taxas gerais de geração de mobs no servidor são um pouco reduzidas. Em comparação com os valores padrão, a diferença quase não é perceptível. Ainda assim, em alguns lugares, como nas farms de mobs, a farm pode não funcionar como esperado.
Para ajustar essas configurações, edite o arquivo "bukkit.yml". Altere os seguintes valores em "spawn-limits":
monsters: 50 #Padrão: 70
animals: 10 #Padrão: 15
water-animals: 3 #Padrão: 5
ambient: 4 #Padrão: 15
Informações
Se quiser, você também pode ajustar os valores. Caso contrário, os valores acima são uma boa média.
Paper Spigot
Informações
Desde o Paper 1.19, não existe mais um único arquivo "paper.yml". O arquivo anterior foi dividido em vários arquivos na pasta "config": "paper-global.yml" (configurações de todo o servidor) e "paper-world-defaults.yml" (valores padrão para todos os mundos, que podem ser substituídos em cada mundo por um arquivo "paper-world.yml" próprio). Os arquivos "bukkit.yml" e "spigot.yml" não são afetados e continuam sendo usados da mesma forma. Como o Paper altera alguns nomes e caminhos de configurações de tempos em tempos, se encontrar diferenças, consulte os comentários no arquivo de configuração correspondente ou a documentação oficial do Paper.
Distância de renderização
Uma medida bastante comum é reduzir a distância de renderização. O valor padrão é de 10 chunks, mas muitos jogadores usam bem menos, por exemplo, de 6 a 8. Alguns jogadores exageram na quantidade de chunks e a definem, por exemplo, como 32. Isso significa que o servidor precisa carregar e processar todos esses chunks, o que consome bastante desempenho.
Em um servidor (Paper) Spigot, é possível ajustar a distância de renderização no arquivo de configuração "spigot.yml". Para isso, altere o valor "view-distance". Para não limitar demais a experiência dos jogadores, recomendamos definir o valor como 5 ou 6, o que pode reduzir a carga do servidor em até 50%.
Informações
Se preferir, você também pode definir o valor como 4. Isso pode ajudar bastante a reduzir o lag, por exemplo, em servidores de mundos de farm que executam a versão 1.13 ou superior.
Compressão de dados
O servidor e os jogadores conectados trocam dados o tempo todo. Os movimentos dos jogadores são enviados ao servidor, que os encaminha aos demais jogadores. As ações dos jogadores e os eventos no mundo, como explosões, também são dados transmitidos repetidamente.
Para tornar essa troca mais eficiente, é possível dobrar o tamanho dos dados compactados. Assim, o servidor precisa de apenas 50% do esforço para trocar os mesmos dados com os jogadores. Para isso, ajuste o valor "network-compression-threshold" no arquivo de configuração "server.properties". O valor deve ser definido como 512. Também temos um artigo sobre isso no nosso guia, que você encontra aqui.
Limites de geração
Distância de renderização
Uma medida bastante comum é reduzir a distância de renderização. O valor padrão é de 10 chunks, mas muitos jogadores usam bem menos, por exemplo, de 6 a 8. Alguns jogadores exageram na quantidade de chunks e a definem, por exemplo, como 32. Isso significa que o servidor precisa carregar e processar todos esses chunks, o que consome bastante desempenho.
É possível ajustar a distância de renderização de um servidor Forge no arquivo de configuração "server.properties". Para isso, altere o valor "view-distance". Para não limitar demais a experiência dos jogadores, recomendamos definir o valor como 5 ou 6, o que pode reduzir a carga do servidor em até 50%.
Já temos um artigo sobre isso no nosso guia, que você encontra aqui.
Compressão de dados
O servidor e os jogadores conectados trocam dados o tempo todo. Os movimentos dos jogadores são enviados ao servidor, que os encaminha aos demais jogadores. As ações dos jogadores e os eventos no mundo, como explosões, também são dados transmitidos repetidamente.
Para tornar essa troca mais eficiente, é possível dobrar o tamanho dos dados compactados. Assim, o servidor precisa de apenas 50% do esforço para trocar os mesmos dados com os jogadores. Para isso, ajuste o valor "network-compression-threshold" no arquivo de configuração "server.properties". O valor deve ser definido como 512. Também temos um artigo sobre isso no nosso guia, que você encontra aqui.
monster-spawns: 2 #Padrão: 1
Se houver um problema geral com os monstros, por exemplo, identificado no relatório de timing, o valor pode ser definido como até 5. Observe o comportamento do servidor após cada ajuste para encontrar o melhor valor para o seu servidor.
Processamento de chunks
Minecraft funciona com os chamados chunks. Cada chunk é formado por 16x16 blocos agrupados, que representam visualmente o mundo para o cliente. Assim, o servidor trabalha apenas com chunks e carrega na RAM os chunks necessários. Quanto mais chunks são carregados e processados continuamente pelo servidor, mais recursos ele precisa disponibilizar, o que pode sobrecarregá-lo em alguns momentos.
Com as configurações padrão, os servidores nunca descarregam os chunks carregados. Isso significa que, em alguns momentos, o uso de RAM fica muito alto e é necessária uma grande quantidade de memória. Infelizmente, isso reduz bastante o desempenho do servidor, pois cada vez mais dados precisam ser processados.
Para que o servidor carregue apenas os chunks necessários no momento, ajuste a seguinte opção em "chunk-gc", no arquivo "bukkit.yml":
period-in-ticks: 300 #Padrão: 600
Informações
O antigo valor adicional "load-threshold" não existe mais nas versões atuais do Paper/Spigot/Bukkit, e o Paper já limita "period-in-ticks" a no máximo 20 ticks (1 segundo) no servidor. Por isso, um valor maior praticamente não tem efeito em um servidor baseado em Paper (por exemplo, Paper Spigot).
A opção "period-in-ticks" define os intervalos, em segundos, em que os chunks devem ser descarregados. Se quiser, você pode reduzir ainda mais esse valor, mas tenha em mente que isso pode causar um efeito indesejado: um ciclo repetitivo.
Nesse ciclo, o chunk seria descarregado mesmo que fosse necessário novamente pouco depois. Isso significa que o servidor teria de gastar mais recursos e tempo para carregá-lo outra vez. O processo se repetiria, sobrecarregando mais o servidor do que se os chunks permanecessem carregados, por exemplo, por mais um minuto.
Para melhorar ainda mais a geração de mobs, altere também o valor "monster-spawns" na seção "ticks-per" do arquivo "bukkit.yml":
monster-spawns: 2 #Padrão: 1
Se houver um problema geral com os monstros, por exemplo, identificado no relatório de timing, o valor pode ser definido como até 5. Observe o comportamento do servidor após cada ajuste para encontrar o melhor valor para o seu servidor.
Processamento de chunks
Minecraft funciona com os chamados chunks. Cada chunk é formado por 16x16 blocos agrupados, que representam visualmente o mundo para o cliente. Assim, o servidor trabalha apenas com chunks e carrega na RAM os chunks necessários. Quanto mais chunks são carregados e processados continuamente pelo servidor, mais recursos ele precisa disponibilizar, o que pode sobrecarregá-lo em alguns momentos.
Com as configurações padrão, os servidores nunca descarregam os chunks carregados. Isso significa que, em alguns momentos, o uso de RAM fica muito alto e é necessária uma grande quantidade de memória. Infelizmente, isso reduz bastante o desempenho do servidor, pois cada vez mais dados precisam ser processados.
Para que o servidor carregue apenas os chunks necessários no momento, ajuste a seguinte opção em "chunk-gc", no arquivo "bukkit.yml":
period-in-ticks: 300 #Padrão: 600
Informações
O antigo valor adicional "load-threshold" não existe mais nas versões atuais do Paper/Spigot/Bukkit, e o Paper já limita "period-in-ticks" a no máximo 20 ticks (1 segundo) no servidor. Por isso, um valor maior praticamente não tem efeito em um servidor baseado em Paper (por exemplo, Paper Spigot).
A opção "period-in-ticks" define os intervalos, em segundos, em que os chunks devem ser descarregados. Se quiser, você pode reduzir ainda mais esse valor, mas tenha em mente que isso pode causar um efeito indesejado: um ciclo repetitivo.
Nesse ciclo, o chunk seria descarregado mesmo que fosse necessário novamente pouco depois. Isso significa que o servidor teria de gastar mais recursos e tempo para carregá-lo outra vez. O processo se repetiria, sobrecarregando mais o servidor do que se os chunks permanecessem carregados, por exemplo, por mais um minuto.
Alcance de geração
Os mobs podem surgir a determinadas distâncias dos jogadores. Vamos reduzir um pouco esse alcance para evitar problemas com a geração de mobs. Essa configuração é muito importante, pois algumas das configurações de geração já foram explicadas acima.
Altere a seguinte configuração em "world-settings", no arquivo "spigot.yml":
mob-spawn-range: 3 #Padrão: 4
Alcance de ativação de entidades
Aqui definimos quando as entidades — ou seja, os animais e monstros — são ativadas. Isso significa, por exemplo, que os animais podem se movimentar ou que os monstros podem detectar jogadores. Em geral, todos os mobs estão ativados, mas ficam em uma espécie de modo de espera. Nesse modo, eles ainda podem se movimentar e detectar jogadores, mas, por exemplo, fazem isso bem mais devagar, reduzindo o esforço exigido do servidor.
Faça essas alterações em "entity-activation-range", no arquivo "spigot.yml". Recomendamos os seguintes valores:
animals: 6 #Padrão: 32
monsters: 16 #Padrão: 32
misc: 2 #Padrão: 16
water: 6 #Padrão: 6
tick-inactive-villagers: true #Padrão: true
Otimização de funis
Os funis são uma parte muito importante do Minecraft, mas podem ser um verdadeiro problema para os servidores! Para cada funil colocado, o servidor precisa verificar 20 vezes por segundo se há um item disponível para coletar. Mover itens de um funil para outro ou para um baú também consome recursos valiosos!
Para melhorar um pouco essa situação, aumentamos os intervalos em que o servidor executa essas ações. Com os valores abaixo, a ação é executada e verificada a cada 3 segundos. As taxas de transferência não mudam. No entanto, relógios de redstone construídos com funis podem deixar de funcionar corretamente.
Para ajustar as configurações, altere os seguintes valores no arquivo "spigot.yml":
hopper-transfer: 24 #Padrão: 8
hopper-check: 24 #Padrão: 8
hopper-amount: 3 #Padrão: 1
Colisões
Desde a versão 1.9 de Minecraft, existem colisões. Por exemplo, um jogador não pode mais ficar dentro de outro jogador. Aqui definimos com que frequência as entidades podem colidir. Isso pode sobrecarregar bastante o servidor, especialmente em farms de mobs, onde muitos mobs ficam em um espaço pequeno.
Para ajustar essa configuração, altere o seguinte valor no arquivo "spigot.yml":
max-entity-collisions: 1 #Padrão: 8
Como as colisões entre mobs não têm efeitos relevantes, você pode reduzir esse valor. Ele não se aplica aos jogadores, apenas aos mobs!
Raio de agrupamento
O raio de agrupamento determina quais itens e pontos de experiência serão reunidos, reduzindo a quantidade de entidades que o servidor precisa processar. Aumentar esse raio pode beneficiar os jogadores, principalmente em servidores onde há muitos itens no chão. Aqui também é importante encontrar um bom equilíbrio. Caso contrário, pode surgir outro tipo de lag, pois o servidor precisará verificar uma área maior, o que consome muitos recursos!
Para ajustar as configurações, altere os seguintes valores em "merge-radius", no arquivo "spigot.yml":
item: 4.0 #Padrão: 2.5
exp: 6.0 #Padrão: 3.0
Informações
Os valores não devem ser superiores a 8, caso contrário, pode ocorrer o efeito de lag mencionado acima!
Nesta etapa, as taxas gerais de geração de mobs no servidor são um pouco reduzidas. Em comparação com os valores padrão, a diferença quase não é perceptível. Ainda assim, em alguns lugares, como nas farms de mobs, a farm pode não funcionar como esperado.
Para ajustar essas configurações, edite o arquivo "bukkit.yml". Altere os seguintes valores em "spawn-limits":
monsters: 50 #Padrão: 70
animals: 10 #Padrão: 15
water-animals: 3 #Padrão: 5
ambient: 4 #Padrão: 15
Informações
Se quiser, você também pode ajustar os valores. Caso contrário, os valores acima são uma boa média. Em um servidor Paper Spigot, você também pode definir os mesmos valores (com prioridade) em "entities.spawning.spawn-limits", no arquivo "paper-world-defaults.yml".
Para melhorar ainda mais a geração de mobs, altere também o valor "monster-spawns" na seção "ticks-per" do arquivo "bukkit.yml":
monster-spawns: 2 #Padrão: 1
Se houver um problema geral com os monstros, por exemplo, identificado no relatório de timing, o valor pode ser definido como até 5. Observe o comportamento do servidor após cada ajuste para encontrar o melhor valor para o seu servidor.
Processamento de chunks
Minecraft funciona com os chamados chunks. Cada chunk é formado por 16x16 blocos agrupados, que representam visualmente o mundo para o cliente. Assim, o servidor trabalha apenas com chunks e carrega na RAM os chunks necessários. Quanto mais chunks são carregados e processados continuamente pelo servidor, mais recursos ele precisa disponibilizar, o que pode sobrecarregá-lo em alguns momentos.
Com as configurações padrão, os servidores nunca descarregam os chunks carregados. Isso significa que, em alguns momentos, o uso de RAM fica muito alto e é necessária uma grande quantidade de memória. Infelizmente, isso reduz bastante o desempenho do servidor, pois cada vez mais dados precisam ser processados.
Para que o servidor carregue apenas os chunks necessários no momento, ajuste a seguinte opção em "chunk-gc", no arquivo "bukkit.yml":
period-in-ticks: 300 #Padrão: 600
Informações
O antigo valor adicional "load-threshold" não existe mais nas versões atuais do Paper/Spigot/Bukkit, e o Paper já limita "period-in-ticks" a no máximo 20 ticks (1 segundo) no servidor. Por isso, um valor maior praticamente não tem efeito em um servidor baseado em Paper (por exemplo, Paper Spigot).
A opção "period-in-ticks" define os intervalos, em segundos, em que os chunks devem ser descarregados. Se quiser, você pode reduzir ainda mais esse valor, mas tenha em mente que isso pode causar um efeito indesejado: um ciclo repetitivo.
Nesse ciclo, o chunk seria descarregado mesmo que fosse necessário novamente pouco depois. Isso significa que o servidor teria de gastar mais recursos e tempo para carregá-lo outra vez. O processo se repetiria, sobrecarregando mais o servidor do que se os chunks permanecessem carregados, por exemplo, por mais um minuto.
Alcance de geração
Os mobs podem surgir a determinadas distâncias dos jogadores. Vamos reduzir um pouco esse alcance para evitar problemas com a geração de mobs. Essa configuração é muito importante, pois algumas das configurações de geração já foram explicadas acima.
Altere a seguinte configuração em "world-settings", no arquivo "spigot.yml":
mob-spawn-range: 3 #Padrão: 4
Geradores de mobs
Os geradores de mobs são usados com muita frequência, especialmente em servidores CityBuild, e às vezes em grande quantidade. Eles geram cada vez mais mobs no servidor, o que pode causar diversos problemas.
Esta opção ajusta um pouco o comportamento de geração dos spawners, fazendo com que o servidor os ative em intervalos curtos. Para isso, ajuste o seguinte valor em "tick-rates", no arquivo "paper-world-defaults.yml":
mob-spawner: 3 #Padrão: 1
Informações
O valor usado acima não altera muito o comportamento nem afeta significativamente a experiência dos jogadores.
Alcance de ativação de entidades
Aqui definimos quando as entidades — ou seja, os animais e monstros — são ativadas. Isso significa, por exemplo, que os animais podem se movimentar ou que os monstros podem detectar jogadores. Em geral, todos os mobs estão ativados, mas ficam em uma espécie de modo de espera. Nesse modo, eles ainda podem se movimentar e detectar jogadores, mas, por exemplo, fazem isso bem mais devagar, reduzindo o esforço exigido do servidor.
Faça essas alterações em "entity-activation-range", no arquivo "spigot.yml". Recomendamos os seguintes valores:
animals: 6 #Padrão: 32
monsters: 16 #Padrão: 32
misc: 2 #Padrão: 16
water: 6 #Padrão: 6
tick-inactive-villagers: true #Padrão: true
Otimização de funis
Os funis são uma parte muito importante do Minecraft, mas podem ser um verdadeiro problema para os servidores! Para cada funil colocado, o servidor precisa verificar 20 vezes por segundo se há um item disponível para coletar. Mover itens de um funil para outro ou para um baú também consome recursos valiosos!
Para melhorar um pouco essa situação, aumentamos os intervalos em que o servidor executa essas ações. Com os valores abaixo, a ação é executada e verificada a cada 3 segundos. As taxas de transferência não mudam. No entanto, relógios de redstone construídos com funis podem deixar de funcionar corretamente.
Para ajustar as configurações, altere os seguintes valores no arquivo "spigot.yml":
hopper-transfer: 24 #Padrão: 8
hopper-check: 24 #Padrão: 8
hopper-amount: 3 #Padrão: 1
Colisões
Desde a versão 1.9 de Minecraft, existem colisões. Por exemplo, um jogador não pode mais ficar dentro de outro jogador. Aqui definimos com que frequência as entidades podem colidir. Isso pode sobrecarregar bastante o servidor, especialmente em farms de mobs, onde muitos mobs ficam em um espaço pequeno.
Em um servidor Paper Spigot, esse valor não fica mais no arquivo "spigot.yml". Você pode encontrá-lo em "collisions", no arquivo "paper-world-defaults.yml":
max-entity-collisions: 1 #Padrão: 8
Como as colisões entre mobs não têm efeitos relevantes, você pode reduzir esse valor. Ele não se aplica aos jogadores, apenas aos mobs!
Raio de agrupamento
O raio de agrupamento determina quais itens e pontos de experiência serão reunidos, reduzindo a quantidade de entidades que o servidor precisa processar. Aumentar esse raio pode beneficiar os jogadores, principalmente em servidores onde há muitos itens no chão. Aqui também é importante encontrar um bom equilíbrio. Caso contrário, pode surgir outro tipo de lag, pois o servidor precisará verificar uma área maior, o que consome muitos recursos!
Para ajustar as configurações, altere os seguintes valores em "merge-radius", no arquivo "spigot.yml":
item: 4.0 #Padrão: 2.5
exp: 6.0 #Padrão: 3.0
Informações
Os valores não devem ser superiores a 8, caso contrário, pode ocorrer o efeito de lag mencionado acima!
Explosões
Muitas partes dos servidores de Minecraft foram reprogramadas no Paper Spigot para melhorar o desempenho. Isso também se aplica às explosões! O software lida melhor com elas, evitando grandes problemas de lag no servidor.
Para isso, ajuste o seguinte valor em "environment", no arquivo "paper-world-defaults.yml":
optimize-explosions: true #Padrão: false
Baús
Também é possível otimizar um pouco os baús! Quando um gato está sentado em cima de um baú, ele não pode ser aberto. Para verificar isso, o servidor precisa percorrer todos os mobs dentro de determinado raio e conferir se algum deles está sentado no baú. Infelizmente, isso consome bastante tempo e acontece toda vez que alguém abre um baú!
Você pode desativar essa opção com a seguinte alteração em "entities.behavior", no arquivo "paper-world-defaults.yml":
disable-chest-cat-detection: true #Padrão: false
Inventários
Os inventários são usados com frequência, mas nem todos são iguais. Um baú ou uma bancada, por exemplo, também são inventários. Com essa alteração, você pode dar um pequeno descanso ao servidor sem que ninguém perceba! Basicamente, ela define quantos ticks devem passar antes que o servidor atualize cada inventário.
Para isso, ajuste o seguinte valor em "tick-rates", no arquivo "paper-world-defaults.yml":
container-update: 3 #Padrão: 1
Informações
O valor não deve ser superior a 5, caso contrário, o inventário pode apresentar bugs! Em modos de jogo como SurvivalGames, nos quais todos os jogadores acessam os baús no centro para pegar os melhores itens, não altere o valor: mantenha-o como "1".
Salvamento de dados dos chunks
Quando são feitas alterações em um chunk, elas não são gravadas diretamente no disco, mas primeiro são carregadas na RAM. Mesmo assim, todas as alterações são salvas com muita frequência, o que às vezes pode causar muito lag, especialmente quando o servidor precisa salvar mudanças em grande escala.
Com esta alteração, reduzimos a quantidade máxima de chunks que podem ser salvos em uma única operação. Isso pode aumentar o uso de RAM em alguns momentos, pois as alterações permanecem na memória por mais tempo!
Faça a seguinte alteração em "chunks", no arquivo "paper-world-defaults.yml":
max-auto-save-chunks-per-tick: 10 #Padrão: 24
Redstone
A redstone é usada com frequência em circuitos que, às vezes, são extremamente grandes. Em servidores públicos, ela pode ser o ponto mais fraco de quase 90% dos servidores, pois circuitos enormes podem causar muito lag. Aqui, usamos um método alternativo de processamento de redstone do Paper Spigot, que reduz bastante o impacto e mantém a mesma funcionalidade do Vanilla!
Para isso, ajuste a seguinte configuração em "misc", no arquivo "paper-world-defaults.yml":
Além de "VANILLA", as opções disponíveis são "EIGENCRAFT" e "ALTERNATE_CURRENT". Segundo o Paper, "ALTERNATE_CURRENT" é atualmente a opção mais rápida e a que menos se afasta do comportamento do Vanilla.
Informações
Atenção! Em algumas situações, isso pode alterar bastante o comportamento da redstone!
Fonte preferida no Google
