Minecraft Performance Flags Benchmarks
1.0.0
Este é um guia para ajustar o Java para Minecraft. Cada sinalizador e ajuste são avaliados individualmente para testar regressões e verificados em relação aos padrões Java para evitar redundância.
Embora esses ajustes reduzam notavelmente algumas falhas de servidor e cliente, espere apenas ganhos modestos de TPS + ganhos mínimos de FPS na melhor das hipóteses, e um pouco maior uso de RAM + CPU. E eles não substituem a eliminação de atrasos com mods como Spark ou Observable.
Discord para dúvidas e afins: https://discord.gg/zeFSR9PnUw
Todos os sinalizadores são testados com o script Benchmark.py. Veja o trabalho em andamento Benchmarks.md.
Para Minecraft 1.16.5 e superior, use Java 17. Alguns lançadores como Curseforge e Prism Launcher solicitam que você use Java 8 em 1.16.X, mas Minecraft 1.16.5+, todos os mods 1.18+ e a maioria dos mods 1.16.5 são compatíveis com Java 17.
Às vezes, o Java 11 funciona onde o Java 17 não.
1.12.2 e abaixo geralmente requerem Java 8.
Os tempos de execução Java da Azul, Microsoft, Adoptium, Amazon e assim por diante são basicamente idênticos. Algumas exceções notáveis:
Oracle GraalVM Enterprise Edition apresenta um compilador Java mais agressivo. É com isso que eu pessoalmente executo o Minecraft, veja a seção GraalVM abaixo.
O Clear Linux OpenJDK da Intel usa o mesmo código que qualquer outro OpenJDK (tornando-o altamente compatível), mas o próprio processo de construção e as dependências são otimizados para CPUs mais recentes. Obtenha-o nos repositórios do Clear Linux via swupd , no Distrobox ou no Docker. Observe que você deve reverter para a versão Java 17 e que o Java 18 reverte algumas das melhorias de desempenho.
O Prime OpenJDK da Azul é muito rápido, pois se conecta ao llvm, mas atualmente é incompatível com a maioria dos mods e é somente Linux. Obtenha aqui: https://docs.azul.com/prime/prime-quick-start-tar
Red Hat Java 8 possui o coletor de lixo Shenandoah. Está protegido por uma inscrição de e-mail gratuita: https://developers.redhat.com/products/openjdk/download
O OpenJ9 da IBM é... muito mais lento no Minecraft e usa sinalizadores totalmente diferentes de qualquer outra compilação Java, mas consome menos memória do que os tempos de execução baseados em OpenJDK. Consulte FAQ, a pasta Benchmarks e este Gist para sinalizadores de baixo consumo de memória.
Se você não sabe o que escolher, recomendo GraalVM EE (veja abaixo) ou o mais recente Adoptium Java 17 JRE: https://adoptium.net/
Couleur mantém uma boa lista de JREs aqui: https://rentry.co/JREs
Esses sinalizadores otimizados são executados com qualquer compilação Java 11+. Eles funcionam em servidores e clientes:
-XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+AlwaysActAsServerClassMachine -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -XX:+UseNUMA -XX:NmethodSweepActivity=1 -XX:ReservedCodeCacheSize=400M -XX:NonNMethodCodeHeapSize=12M -XX:ProfiledCodeHeapSize=194M -XX:NonProfiledCodeHeapSize=194M -XX:-DontCompileHugeMethods -XX:MaxNodeLimit=240000 -XX:NodeLimitFudgeFactor=8000 -XX:+UseVectorCmov -XX:+PerfDisableSharedMem -XX:+UseFastUnorderedTimeStamps -XX:+UseCriticalJavaThreadPriority -XX:ThreadPriorityPolicy=1 -XX:AllocatePrefetchStyle=3
Você deve adicionar sinalizadores de coleta de lixo a esses argumentos java.
-Xmx8G -Xms8G -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -XX:+UseNUMA -XX:NmethodSweepActivity=1 -XX:ReservedCodeCacheSize=400M -XX:NonNMethodCodeHeapSize=12M -XX:ProfiledCodeHeapSize=194M -XX:NonProfiledCodeHeapSize=194M -XX:-DontCompileHugeMethods -XX:MaxNodeLimit=240000 -XX:NodeLimitFudgeFactor=8000 -XX:+UseVectorCmov -XX:+PerfDisableSharedMem -XX:+UseFastUnorderedTimeStamps -XX:+UseCriticalJavaThreadPriority -XX:ThreadPriorityPolicy=1 -XX:AllocatePrefetchStyle=3 -XX:+UseG1GC -XX:MaxGCPauseMillis=37 -XX:+PerfDisableSharedMem -XX:G1HeapRegionSize=16M -XX:G1NewSizePercent=23 -XX:G1ReservePercent=20 -XX:SurvivorRatio=32 -XX:G1MixedGCCountTarget=3 -XX:G1HeapWastePercent=20 -XX:InitiatingHeapOccupancyPercent=10 -XX:G1RSetUpdatingPauseTimePercent=0 -XX:MaxTenuringThreshold=1 -XX:G1SATBBufferEnqueueingThresholdPercent=30 -XX:G1ConcMarkStepDurationMillis=5.0 -XX:G1ConcRSHotCardLimit=16 -XX:G1ConcRefinementServiceIntervalMillis=150 -XX:GCTimeRatio=99 -XX:+UseLargePages -XX:LargePageSizeInBytes=2m
A memória mínima e máxima ( -xms e -xmx ) deve ser definida com o mesmo valor, conforme explicado aqui: https://dzone.com/articles/benefits-of-setting-initial-and-maximum-memory-siz
Uma exceção: se você estiver em um sistema com pouca memória e o Minecraft ocupar quase toda a sua RAM, defina a memória mínima abaixo da memória máxima para economizar o máximo possível.
Os tamanhos são definidos em megabytes ( -Xms4096M ) ou gigabytes ( -Xmx8G )
Alocar muita memória pode quebrar o GC ou apenas deixar o Minecraft lento, mesmo se você tiver bastante de sobra. Alocar muito pouco também pode desacelerar ou interromper o jogo. Fique de olho no gerenciador de tarefas do Windows (ou no monitor do sistema do seu DE) enquanto o Minecraft está em execução e aloque apenas o necessário (que geralmente é inferior a 8G). sparkc gcmonitor informará se sua alocação é muito alta (as pausas serão muito longas) ou muito baixa (GC frequente com um aviso de pouca memória na notificação).
Sinalizadores de coleta de lixo devem ser adicionados aos servidores e clientes do Minecraft , já que o padrão "pausa" para parar e coletar o manifesto de lixo como travamentos no cliente e atrasos nos servidores. Use o comando /sparkc gcmonitor no mod Spark para observar pausas no jogo. Quaisquer pausas da geração antiga são ruins, e as coletas do G1GC da geração mais jovem devem ser pouco frequentes, mas curtas o suficiente para serem imperceptíveis.
Escolha um conjunto de bandeiras. Eu recomendo Shenandoah em clientes , ZGC em servidores Java 17 poderosos e G1GC em Graal ou em servidores/clientes com menos RAM e menos núcleos:
ZGC é ótimo para servidores com alta memória/alta contagem de núcleos. Ele não tem nenhum impacto na taxa de transferência do servidor que eu possa medir e absolutamente não gagueja. No entanto, requer mais RAM e mais núcleos do que outros coletores de lixo.
Infelizmente, ele tem um impacto significativo no FPS do cliente no meu laptop (8 núcleos/16 threads). Veja o benchmark "ZGC" na pasta benchmarks. Não está disponível no Java 8 e tem muito menos desempenho no Java 11 do que no Java 17.
-XX:+UseZGC -XX:AllocatePrefetchStyle=1 -XX:-ZProactive habilita isso, mas aloca mais RAM e mais ConcGCThreads do que normalmente faria para outro GC. Observe que ZGC não gosta de AllocatePrefetchStyle=3, portanto, defini-lo como 1 substitui a entrada anterior. Você
Shenandoah tem um bom desempenho em clientes, mas mata o rendimento do servidor em meus testes. Habilite-o com -XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu -XX:ShenandoahGuaranteedGCInterval=1000000 -XX:AllocatePrefetchStyle=1
Veja mais opções de ajuste aqui. As opções “herústico” e “modo” não mudam muito para mim (exceto “compacto”, que você não deve usar). Assim como o ZGC, Shenandoah não gosta de AllocatePrefetchStyle=3.
Observe que Shenandoah não está no Java 8. Também não está em nenhuma versão do Oracle Java! Se você for um usuário Java 8, deverá usar o Red Hat OpenJDK para usar o Shenandoah: https://developers.redhat.com/products/openjdk/download
G1GC é o coletor de lixo padrão e é o único coletor de lixo disponível para usuários do GraalVM. Os famosos argumentos G1GC do servidor Minecraft de Aikar funcionam muito bem em clientes, com duas ressalvas: eles efetivamente limitam o parâmetro MaxGCPauseMillis definindo G1NewSizePercent tão alto, produzindo travamentos longos em alguns clientes, e eles coletam lixo antigo de forma muito agressiva (já que o cliente produz muito menos do que um servidor preenchido).
Eles são semelhantes aos sinalizadores aikar, mas com pausas mais curtas e frequentes, coleta mista G1 menos agressiva e coleta de fundo mais agressiva: -XX:+UseG1GC -XX:MaxGCPauseMillis=37 -XX:+PerfDisableSharedMem -XX:G1HeapRegionSize=16M -XX:G1NewSizePercent=23 -XX:G1ReservePercent=20 -XX:SurvivorRatio=32 -XX:G1MixedGCCountTarget=3 -XX:G1HeapWastePercent=20 -XX:InitiatingHeapOccupancyPercent=10 -XX:G1RSetUpdatingPauseTimePercent=0 -XX:MaxTenuringThreshold=1 -XX:G1SATBBufferEnqueueingThresholdPercent=30 -XX:G1ConcMarkStepDurationMillis=5.0 -XX:G1ConcRSHotCardLimit=16 -XX:G1ConcRefinementServiceIntervalMillis=150 -XX:GCTimeRatio=99
G1NewSizePercent e MaxGCPauseMillis podem ser usados para ajustar a frequência/duração de suas coleções da geração mais jovem. G1HeapWastePercent=18 deve ser removido se você estiver tendo alguma pausa da geração antiga em sua configuração. Como alternativa, você pode aumentá-lo e definir G1MixedGCCountTarget como 2 ou 1 para tornar a coleta de lixo mista ainda mais lenta (ao custo de maior uso de memória).
Pausas mais longas são mais aceitáveis em servidores. Esses sinalizadores estão muito próximos dos padrões do aikar:
-XX:+UseG1GC -XX:MaxGCPauseMillis=130 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=28 -XX:G1HeapRegionSize=16M -XX:G1ReservePercent=20 -XX:G1MixedGCCountTarget=3 -XX:InitiatingHeapOccupancyPercent=10 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=0 -XX:SurvivorRatio=32 -XX:MaxTenuringThreshold=1 -XX:G1SATBBufferEnqueueingThresholdPercent=30 -XX:G1ConcMarkStepDurationMillis=5 -XX:G1ConcRSHotCardLimit=16 -XX:G1ConcRefinementServiceIntervalMillis=150
-XX:ConcGCThreads=[Some Number] controla o número máximo de threads de segundo plano que o coletor de lixo pode usar e o padrão é logical (hyperthreaded) cores / 4 . Versões recentes do Java reduzirão o número de threads gc, se necessário.
Em alguns casos (especialmente com ZGC ou Shenandoh) você deseja aumentar esse limite de thread além do padrão. Eu recomendo "2" em CPUs com 4 threads e [number of real cores - 2] na maioria das outras CPUs, mas você pode precisar brincar com este parâmetro. Se estiver muito baixo, a coleta de lixo não conseguirá acompanhar o Minecraft, e o jogo irá gaguejar e/ou começar a consumir muita RAM e travar. Se for muito alto, poderá tornar o jogo mais lento, especialmente se você estiver executando o Java 8.
Nenhum outro sinalizador de "threading" como ParallelGCThreads ou JVMCIThreads é necessário, pois eles são habilitados por padrão com boas configurações automáticas em Java 8+.
NOTA: Páginas grandes requerem privilégios de administrador no Windows. Este é um risco à segurança e você deve pular esta seção se não se sentir confortável com isso.
A ativação de páginas grandes melhora o desempenho dos servidores e clientes do Minecraft. Aqui estão alguns ótimos tutoriais para habilitá-lo:
No Windows, você deve executar o java e seu inicializador como administrador. Isso significa marcar a caixa de seleção de compatibilidade "executar como administrador" para javaw.exe , java.exe e your launcher.exe , caso contrário, as páginas grandes falharão silenciosamente. Adicione -XX:+UseLargePages -XX:LargePageSizeInBytes=2m aos seus argumentos.
No Linux, você geralmente deseja usar -XX:+UseTransparentHugePages . Para alocar memória manualmente (para um maior aumento de desempenho), a Red Hat tem um bom tutorial para distros Linux do tipo RHEL, como Fedora, CentOS ou Oracle Linux: https://www.redhat.com/en/blog/optimizing -rhel-8-run-java-implementation-minecraft-server
Verifique e veja se páginas grandes estão funcionando com o argumento -Xlog:gc+init java em Java 17.
Em qualquer versão/plataforma Java, se páginas grandes não estiverem funcionando, você receberá um aviso no log semelhante a este:
Aviso de VM do servidor Java HotSpot(TM) de 64 bits: a JVM não pode usar memória de página grande porque não tem privilégios suficientes para bloquear páginas na memória.
GraalVM é um novo Java VM da Oracle que pode melhorar o desempenho do Minecraft (modded e vanilla). Embora os ganhos de FPS do cliente sejam modestos, as cargas de trabalho do lado do servidor, como a geração de blocos, podem obter um aumento de mais de 20%!
Somente o GraalVM Enterprise Edition vem com o conjunto completo de otimizações. Baixe-o através de links diretos da Oracle:
Windows AMD64 (64 bits): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA17_22_3_1/graalvm-ee-java17-windows-amd64-22.3.1.zip
Linux AMD64 (64 bits): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA17_22_3_1/graalvm-ee-java17-linux-amd64-22.3.1.tar.gz
Linux AARCH64 (ARM 64 bits): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA17_22_3_1/graalvm-ee-java17-linux-aarch64-22.3.1.tar.gz
Mac AMD64 (64 bits): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA17_22_3_1/graalvm-ee-java17-darwin-amd64-22.3.1.tar.gz
Windows AMD64 (64 bits): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA11_22_3_1/graalvm-ee-java11-windows-amd64-22.3.1.zip
Linux AMD64 (64 bits): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA11_22_3_1/graalvm-ee-java11-linux-amd64-22.3.1.tar.gz
Linux AARCH64 (ARM 64 bits): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA11_22_3_1/graalvm-ee-java11-linux-aarch64-22.3.1.tar.gz
Mac AMD64 (64 bits): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA11_22_3_1/graalvm-ee-java11-darwin-amd64-22.3.1.tar.gz
Windows AMD64 (64 bits): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA8_21_3_5/graalvm-ee-java8-windows-amd64-21.3.5.zip
Linux AMD64 (64 bits): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA8_21_3_5/graalvm-ee-java8-linux-amd64-21.3.5.tar.gz
Mac AMD64 (64 bits): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA8_21_3_5/graalvm-ee-java8-darwin-amd64-21.3.5.tar.gz
(Versões selecionadas do GraalVM EE também estão disponíveis no AUR e nos repositórios do Oracle Linux)
Novas versões para Macs ARM exigem registro gratuito na página principal de download da Oracle: https://www.oracle.com/downloads/graalvm-downloads.html
Essas versões não são instaladores Java. Você precisa substituir manualmente a versão do Java do seu inicializador ou usar um inicializador do Minecraft que suporte a especificação do seu caminho Java. Eu recomendo ATLauncher, Prism Launcher ou GDLauncher. Ao especificar um caminho java, navegue até a pasta "bin" no download do GraalVM e use "javaw.exe" ou "java.exe".
Para servidores, você precisa substituir o comando "java" no arquivo start sh/bat do servidor pelo caminho completo para graalvm java, entre aspas.
Alternativamente, você pode instalá-lo em todo o sistema seguindo o guia da Oracle: https://www.graalvm.org/22.2/docs/getting-started/#install-graalvm
Argumentos para GraalVM EE 22+ Java 17 (ou Java 11):
-XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+AlwaysActAsServerClassMachine -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -XX:+UseNUMA -XX:AllocatePrefetchStyle=3 -XX:NmethodSweepActivity=1 -XX:ReservedCodeCacheSize=400M -XX:NonNMethodCodeHeapSize=12M -XX:ProfiledCodeHeapSize=194M -XX:NonProfiledCodeHeapSize=194M -XX:-DontCompileHugeMethods -XX:+PerfDisableSharedMem -XX:+UseFastUnorderedTimeStamps -XX:+UseCriticalJavaThreadPriority -XX:+EagerJVMCI -Dgraal.TuneInlinerExploration=1 -Dgraal.CompilerConfiguration=enterprise
Você deve usar G1GC com estes argumentos. GraalVM atualmente não funciona com ZGC ou Shenandoah.
GraalVM EE 22.3.0 corrige todos os bugs conhecidos do Minecraft
Se você executar uma versão mais antiga do GraalVM baseada em Java 8, existem alguns problemas potenciais:
VectorizeSIMD torna entidades invisíveis com mods de shader como Optifine, Iris ou Occulus... mas apenas sob certas condições. Isso será corrigido no GraalVM EE 22.3.0. Veja: oracle/graal#4849
GraalVM CE e EE quebram a renderização de constelação em 1.16.5 Astral Sorcery. Isso possivelmente está relacionado ao bug do shader. Veja: HellFirePvP/AstralSorcery#1963
Ainda não observei nenhum bug no servidor.
Se você encontrar qualquer outro problema de mod que possa remontar ao GraalVM, crie um problema no Github ou poste no Discord! Geralmente, você pode contorná-los desativando os principais sinalizadores de otimização dgraal ou encontrando a função correta com Dgraal.PrintCompilation=true e contornando-a com -Dgraal.GraalCompileOnly=~... depois de encontrar a função mal compilada.
Um mod "universal" do Windows semelhante ao ReShade, o SpecialK tem dois principais benefícios de desempenho:
Um limitador de quadros "inteligente" que reduz interrupções, elimina tearing, economiza energia e economiza TDP da CPU para aumentar quando necessário. Funciona até em conjunto com VRR ou Nvidia Reflex.
Um wrapper OpenGL para DirectX11 chamado OpenGL-IK que elimina a sobrecarga do modo de janela do Minecraft e permite outros recursos (como HDR automático ou uma janela redimensionável sem borda).
Baixe aqui: https://wiki.special-k.info/en/SpecialK/Tools
Adicione seu iniciador MC e marque a caixa de seleção "serviço elevado". Em seguida, navegue até a pasta java bin onde está o javaw.exe e crie um arquivo vazio chamado SpecialK.OpenGL32 . Inicie o seu iniciador do Minecraft com o iniciador SpecialK, e o iniciador irá “injetar” o SpecialK no Minecraft. 
Você pode criar um atalho na área de trabalho para o iniciador do Minecraft por meio da interface do SpecialK para ainda mais conveniência.
Certifique-se de desligar o VSync e o limitador de quadros do Minecraft no jogo.
Um usuário relatou redução de FPS ao executar SpecialK. Se isso acontecer com você, por favor me avise através do Discord ou Github!
Depois de iniciar o Minecraft, configure o Java para executar com uma prioridade de processo "Acima do Normal" no Windows com o Gerenciador de Tarefas:
Os usuários do Linux podem adicionar sudo nice -n -10 ao início do comando de inicialização, mas observe que níveis agradáveis abaixo de 0 (com o "máximo" sendo -20) exigem a execução do Minecraft como sudo . Alternativamente, use o comando renice após iniciar o Minecraft para evitar esse risco de segurança.
Este é um repositório fantástico para encontrar mods de desempenho: https://github.com/NordicGamerFE/usefulmods
Em vez de Optifine, eu recomendaria alternativas mais compatíveis como Sodium + Iris ou Rubidium + Oculus.
Eu recomendo usar Java 17 ou, na sua falta, Java 11, a menos que 8 seja absolutamente necessário. Mas se for, esses sinalizadores funcionarão com OpenJDK8, junto com Shenandoh GC (para Red Hat OpenJDK em clientes) ou G1GC (para todo o resto):
-XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+AlwaysActAsServerClassMachine -XX:+ParallelRefProcEnabled -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:+PerfDisableSharedMem -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -XX:MaxInlineLevel=15 -XX:MaxVectorSize=32 -XX:+UseCompressedOops -XX:ThreadPriorityPolicy=1 -XX:+UseNUMA -XX:+UseDynamicNumberOfGCThreads -XX:NmethodSweepActivity=1 -XX:ReservedCodeCacheSize=350M -XX:-DontCompileHugeMethods -XX:MaxNodeLimit=240000 -XX:NodeLimitFudgeFactor=8000 -XX:+UseFPUForSpilling -Dgraal.CompilerConfiguration=community
Os usuários x86 Java 8 (também conhecidos como a maioria dos usuários Java 8) podem adicionar estes argumentos adicionais:
-XX:+UseXMMForArrayCopy
Você também pode obter versões Java 8 do GraalVM EE na seção 21.X no site da Oracle e usar estes argumentos:
-XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+AlwaysActAsServerClassMachine -XX:+ParallelRefProcEnabled -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -XX:AllocatePrefetchStyle=1 -XX:ThreadPriorityPolicy=1 -XX:+UseNUMA -XX:+UseDynamicNumberOfGCThreads -XX:NmethodSweepActivity=1 -XX:ReservedCodeCacheSize=350M -XX:-DontCompileHugeMethods -XX:MaxNodeLimit=240000 -XX:NodeLimitFudgeFactor=8000 -XX:+UseFPUForSpilling -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:+EagerJVMCI -Dgraal.TuneInlinerExploration=1 -Dgraal.CompilerConfiguration=enterprise -Dgraal.UsePriorityInlining=true -Dgraal.Vectorization=true -Dgraal.OptDuplication=true -Dgraal.DetectInvertedLoopsAsCounted=true -Dgraal.LoopInversion=true -Dgraal.VectorizeHashes=true -Dgraal.EnterprisePartialUnroll=true -Dgraal.VectorizeSIMD=true -Dgraal.StripMineNonCountedLoops=true -Dgraal.SpeculativeGuardMovement=true -Dgraal.InfeasiblePathCorrelation=true
Certifique-se de definir -Dgraal.VectorizeSIMD como false se você executar shaders.
Execute seus servidores Minecraft no Clear Linux! É de longe a distribuição Linux mais otimizada pronta para uso e possui alguns outros recursos interessantes (como um sistema de configuração sem estado). Ele também executa muito bem clientes em GPUs AMD/Intel: https://web.archive.org/web/20220916090057/https://docs.01.org/clearlinux/latest/tutorials/multi-boot/dual-boot- vencer.html
Oracle Linux também é uma boa escolha para servidores, já que é razoavelmente bem otimizado e tem Graalvm EE disponível através do gerenciador de pacotes. Para os clientes, distros baseadas em Arch como CachyOS ou EndeavorOS são excelentes, pois possuem amplo suporte para a maioria dos hardwares.
Certifique-se de que o cliente Minecraft esteja usando sua GPU discreta! Verifique a guia F3 e force o Minecraft a usá-lo nas " Configurações gráficas do Windows ", não no painel de controle AMD/Nvidia (já que eles parecem não funcionar mais).
Os usuários do cliente Linux do Minecraft devem verificar https://github.com/Admicos/minecraft-wayland
Feche tudo em segundo plano, incluindo Discord, inicializadores de jogos e seu navegador! O Minecraft consome muitos recursos e não gosta que outros aplicativos gerem interrupções de CPU ou consumam E/S de disco, RAM e assim por diante.
Java 18/19 tem algumas incompatibilidades de mod. Eles supostamente funcionam com alguns modpacks, mas não tenho certeza se há algum benefício de desempenho.
Os ajustes de Java melhoram o desempenho do servidor e as falhas do cliente, mas não aumentam muito o FPS médio do cliente (se é que aumentam). Para isso, executar drivers gráficos e mods de desempenho corretos/atualizados é muito mais importante: https://github.com/NordicGamerFE/usefulmods
Este guia pressupõe que você tenha um pouco de RAM extra ao executar o Minecraft. Se sua configuração for restrita em RAM, tente remover os seguintes argumentos em particular: -XX:NmethodSweepActivity=1 -XX:ReservedCodeCacheSize=400M -XX:NonNMethodCodeHeapSize=12M -XX:ProfiledCodeHeapSize=194M -XX:NonProfiledCodeHeapSize=194M e tente o servidor Argumentos do G1GC.
O OpenJ9 da IBM realmente economiza RAM, como sua reputação sugere, mas é 30% mais lento no chunkgen do servidor em meus testes. Se houver alguma sinalização que o torne competitivo com o OpenJDK, por favor me avise no Discord ou aqui: #9
-XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions simplesmente desbloqueia mais sinalizadores para serem usados. Eles podem ser listados com os sinalizadores -XX:+PrintFlagsFinal e -XX:+JVMCIPrintProperties , consulte Flag Dumps-XX:G1MixedGCCountTarget=3 : Este é quantos blocos gc antigos devem ser direcionados no gc "misto". Essas coleções mistas são muito mais lentas e o cliente Minecraft não gera oldgen muito rapidamente, então podemos diminuir esse valor para 3, 2 ou até 1 para pausas mais curtas no GC.-XX:+UseNUMA permite otimizações para sistemas multisocket, se aplicável. Não tenho certeza se isso se aplica a CPUs MCM como Ryzen ou Epyc, mas é desativado automaticamente se não for aplicável.-XX:-DontCompileHugeMethods Permite que métodos enormes sejam compilados. O Minecraft modificado tem alguns deles, e não nos importamos com o maior uso da CPU do compilador em segundo plano.-XX:MaxNodeLimit=240000 -XX:NodeLimitFudgeFactor=8000 Ativa a otimização de métodos maiores. Veja: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8058148-XX:ReservedCodeCacheSize=400M -XX:NonNMethodCodeHeapSize=12M -XX:ProfiledCodeHeapSize=194M -XX:NonProfiledCodeHeapSize=194M reserva mais espaço para código compilado. Todas as seções devem "somar" a ReservedCodeCacheSize . Observei o Minecraft modificado atingir o limite padrão de 250 megabytes com XX:+PrintCodeCache , mas mesmo que não seja preenchido, o tamanho maior torna a remoção do código compilado menos agressiva.-XX:NmethodSweepActivity=1 (padrão 10) mantém o código "frio" no cache por mais tempo. Também não há risco de "encher" o cache de código, pois o código frio é removido de forma mais agressiva à medida que é preenchido.-XX:+UseStringDeduplication-XX:+UseFastUnorderedTimeStamps Evite chamadas do sistema para obter a hora. O impacto disso varia de acordo com o sistema, mas não estamos realmente preocupados com a precisão do registro de data e hora.-XX:+UseCriticalJavaThreadPriority Nada deve impedir os threads do Minecraft. Threads de GC e compilador podem esperar.-XX:ThreadPriorityPolicy=1 Use uma gama mais ampla de prioridades de thread. Requer sudo no Linux para funcionar. Alguns JDKs (como Graal) habilitam isso por padrão, mas outros não.-XX:G1SATBBufferEnqueueingThresholdPercent=30 -XX:G1ConcMarkStepDurationMillis=5 -XX:G1ConcRSHotCardLimit=16 -XX:G1ConcRefinementServiceIntervalMillis=150 : Otimiza os threads de coleta simultânea do G1GC, ainda em teste: https://research.spec.org/icpe_proceedings/2014/p111.pdf-XX:G1RSetUpdatingPauseTimePercent=0 : Queremos que todo esse trabalho seja feito nos threads simultâneos do G1GC, não nas pausas.-XX:G1HeapWastePercent=18 Não se preocupe em coletar da geração antiga até que esteja acima desta porcentagem. Isso evita o acionamento de GCs "mistos" mais lentos da geração jovem, o que é bom, já que o Minecraft (com memória suficiente) não preenche a geração antiga tão rapidamente. Ideia de: https://www.reddit.com/r/Minecraft/comments/k9zb7m/tuning_jvm_gc_for_singleplayer/-XX:GCTimeRatio=99 Como meta, 1% do tempo da CPU deve ser gasto na coleta de lixo. O padrão é 12, o que parece muito baixo. O padrão para Java 8 era 99.-XX:AllocatePrefetchStyle=3 Gere uma instrução de pré-busca por linha de cache. A pré-busca mais agressiva geralmente é útil em CPUs mais recentes com caches grandes. Parece quebrar o ZGC. Consulte: https://github.com/openjdk/jdk/blob/bd90c4cfa63ba2de26f7482ed5d1704f9be9629f/src/hotspot/share/opto/macro.cpp#L1806-Dgraal.LoopRotation=true Uma otimização não padrão, provavelmente será padrão em breve.-Dgraal.TuneInlinerExploration=1 Passe mais tempo tomando decisões inlining. Para o Minecraft, queremos que o compilador C2 seja o mais lento e agressivo possível.-Dgraal são habilitados por padrão e existem como uma verificação de integridade, para depuração ou como proteção contra falhas (se, por exemplo, alguém desabilitar inadvertidamente o JVCMI com algum outro sinalizador).-XX:MaxInlineLevel=15 -XX:MaxVectorSize=32 ) são apenas copiados dos padrões do Java 17. Outros (como +AggressiveOpts ) não são padrão apenas em algumas compilações mais antigas do Java 8.-Dgraal.BaseTargetSpending=160 (padrão 120) no Graal e alguns outros sinalizadores no OpenJDK. CPUs com caches maiores podem se beneficiar com isso.-XX:+AlignVector -XX:+OptoBundling -XX:+OptimizeFill -XX:+AlwaysCompileLoopMethods -XX:+EnableVectorAggressiveReboxing -XX:+EnableVectorSupport -XX:+OptoScheduling -XX:+UseCharacterCompareIntrinsics -XX:+UseCopySignIntrinsic -XX:+UseVectorStubs-Dgraal.LSRAOptimization=true-Dgraal.OptWriteMotion=true e graal.WriteableCodeCache=true , que não parecem estáveis, mas podem ser mais estáveis no GraalVM 22.3.0G1HeapWastePercent .-XX:+PrintFlagsFinal e -XX:+JVMCIPrintProperties para despejar descrições/padrões de sinalizadores.
