Minecraft Performance Flags Benchmarks
1.0.0
Ceci est un guide pour régler Java pour Minecraft. Chaque indicateur et ajustement est évalué individuellement pour tester les régressions et vérifié par rapport aux valeurs par défaut de Java pour éviter la redondance.
Bien que ces ajustements réduisent considérablement certains bégaiements du serveur et du client, attendez-vous au mieux à des gains TPS modestes + des gains FPS minimes et à une utilisation quelque peu accrue de la RAM + du CPU. Et ils ne remplacent pas la suppression des retards avec des mods comme Spark ou Observable.
Discord pour les questions et autres : https://discord.gg/zeFSR9PnUw
Tous les indicateurs sont testés avec le script Benchmark.py. Voir les travaux en cours Benchmarks.md.
Pour Minecraft 1.16.5 et versions ultérieures, utilisez Java 17. Certains lanceurs comme Curseforge et Prism Launcher vous demandent d'utiliser Java 8 sur 1.16.X, mais Minecraft 1.16.5+, tous les mods 1.18+ et la plupart des mods 1.16.5 sont compatibles. avec Java 17.
Parfois, Java 11 fonctionnera là où Java 17 ne le fera pas.
1.12.2 et versions antérieures nécessitent généralement Java 8.
Les environnements d'exécution Java d'Azul, Microsoft, Adoptium, Amazon, etc. sont fondamentalement identiques. Quelques exceptions notables :
Oracle GraalVM Enterprise Edition propose un compilateur Java plus agressif. C'est avec cela que j'exécute personnellement Minecraft, voir la section GraalVM ci-dessous.
Clear Linux OpenJDK d'Intel utilise le même code que n'importe quel autre OpenJDK (ce qui le rend hautement compatible), mais le processus de construction lui-même et les dépendances sont optimisés pour les processeurs plus récents. Récupérez-le dans les dépôts de Clear Linux via swupd , depuis Distrobox ou depuis Docker. Notez que vous devez revenir à la version Java 17 et que Java 18 annule certaines des améliorations de performances.
Le Prime OpenJDK d'Azul est très rapide car il se connecte à llvm, mais il est actuellement incompatible avec la plupart des mods et est uniquement Linux. Obtenez-le ici : https://docs.azul.com/prime/prime-quick-start-tar
Red Hat Java 8 dispose du garbage collector Shenandoah. C'est fermé derrière une inscription gratuite par e-mail : https://developers.redhat.com/products/openjdk/download
OpenJ9 d'IBM est... beaucoup plus lent dans Minecraft et utilise des indicateurs totalement différents de ceux de toute autre version Java, mais il consomme moins de mémoire que les environnements d'exécution basés sur OpenJDK. Voir FAQ, le dossier Benchmarks et ce Gist pour les indicateurs de faible consommation de mémoire.
Si vous ne savez pas quoi choisir, je recommande GraalVM EE (voir ci-dessous) ou le dernier Adoptium Java 17 JRE : https://adoptium.net/
Couleur maintient une bonne liste de JRE ici : https://rentry.co/JREs
Ces indicateurs optimisés fonctionnent avec n'importe quelle version Java 11+. Ils fonctionnent à la fois sur les serveurs et sur les clients :
-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
Vous devez ajouter des indicateurs de garbage collection à ces arguments 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
La mémoire minimale et maximale ( -xms et -xmx ) doit être définie sur la même valeur, comme expliqué ici : https://dzone.com/articles/benefits-of-setting-initial-and-maximum-memory-siz
Une exception : si vous utilisez un système à faible mémoire et que Minecraft occupe presque toute votre RAM, définissez votre mémoire minimale en dessous de votre mémoire maximale pour économiser autant que possible.
Les tailles sont définies en mégaoctets ( -Xms4096M ) ou en gigaoctets ( -Xmx8G )
Allouer trop de mémoire peut interrompre gc ou simplement ralentir Minecraft, même si vous en avez beaucoup à revendre. Allouer trop peu peut également ralentir ou interrompre le jeu. Gardez un œil attentif sur le gestionnaire de tâches Windows (ou sur le moniteur système de votre DE) pendant que Minecraft est en cours d'exécution et allouez uniquement ce dont il a besoin (ce qui est généralement inférieur à 8 Go). sparkc gcmonitor vous dira si votre allocation est trop élevée (les pauses seront trop longues) ou trop faible (GC fréquents avec un avertissement de mémoire faible dans la notification).
Des indicateurs de récupération de place doivent être ajoutés aux serveurs et aux clients Minecraft , car les "pauses" par défaut pour arrêter et collecter les déchets se manifestent sous forme de bégaiements sur le client et de retard sur les serveurs. Utilisez la commande /sparkc gcmonitor dans le mod Spark pour observer les pauses dans le jeu. Toutes les pauses de l’ancienne génération sont mauvaises, et les collectes G1GC de la jeune génération devraient être peu fréquentes, mais suffisamment courtes pour être imperceptibles.
Choisissez un ensemble de drapeaux. Je recommande Shenandoah sur les clients , ZGC sur les puissants serveurs Java 17 , et G1GC sur Graal ou sur les serveurs/clients avec moins de RAM et moins de cœurs :
ZGC est idéal pour les serveurs à mémoire élevée et à nombre de cœurs élevé. Il n’a aucun impact sur le débit du serveur que je puisse mesurer et ne bégaie absolument pas. Cependant, il nécessite plus de RAM et plus de cœurs que les autres ramasse-miettes.
Malheureusement, il a un FPS client important sur mon ordinateur portable (8 cœurs/16 threads). Voir le benchmark "ZGC" dans le dossier benchmarks. Ce n'est pas disponible dans Java 8, et beaucoup moins performant dans Java 11 que dans Java 17.
-XX:+UseZGC -XX:AllocatePrefetchStyle=1 -XX:-ZProactive l'active, mais alloue plus de RAM et plus ConcGCThreads que vous ne le feriez normalement pour un autre GC. Notez que ZGC n'aime pas AllocatePrefetchStyle=3, donc le définir sur 1 remplace l'entrée précédente. U
Shenandoah fonctionne bien sur les clients, mais tue le débit du serveur lors de mes tests. Activez-le avec -XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu -XX:ShenandoahGuaranteedGCInterval=1000000 -XX:AllocatePrefetchStyle=1
Voir plus d’options de réglage ici. Les options "herustic" et "mode" ne changent pas grand chose pour moi (sauf pour "compact", qu'il ne faut pas utiliser). Comme ZGC, Shenandoah n'aime pas AllocatePrefetchStyle=3.
Notez que Shenandoah n'est pas dans Java 8. Ce n'est pas non plus dans aucune version Oracle Java ! Si vous êtes un utilisateur Java 8, vous devez utiliser Red Hat OpenJDK pour utiliser Shenandoah : https://developers.redhat.com/products/openjdk/download
G1GC est le garbage collector par défaut et le seul garbage collector disponible pour les utilisateurs de GraalVM. Les arguments G1GC du célèbre serveur Minecraft d'Aikar fonctionnent très bien sur les clients, avec deux mises en garde : ils bloquent efficacement le paramètre MaxGCPauseMillis en définissant G1NewSizePercent si haut, produisant de longs bégaiements sur certains clients, et ils collectent les déchets d'ancienne génération de manière trop agressive (car le client produit beaucoup moins qu'un serveur peuplé).
Ceux-ci sont similaires aux drapeaux Aikar, mais avec des pauses plus courtes et plus fréquentes, une collection mixte G1 moins agressive et une collection d'arrière-plan plus agressive : -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 et MaxGCPauseMillis peuvent être utilisés pour régler la fréquence/durée de vos collections jeune génération. G1HeapWastePercent=18 doit être supprimé si vous obtenez des pauses d’ancienne génération sur votre configuration. Alternativement, vous pouvez l'augmenter et définir G1MixedGCCountTarget sur 2 ou 1 pour rendre le garbage collection mixte encore plus paresseux (au prix d'une utilisation plus élevée de la mémoire).
Des pauses plus longues sont plus acceptables sur les serveurs. Ces drapeaux sont très proches des valeurs par défaut d'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] contrôle le nombre maximum de threads d'arrière-plan que le garbage collector est autorisé à utiliser et la valeur par défaut est les logical (hyperthreaded) cores / 4 . Les versions récentes de Java réduiront le nombre de threads gc, si nécessaire.
Dans certains cas (notamment avec ZGC ou Shenandoh), vous souhaitez augmenter ce plafond de filetage au-delà de la valeur par défaut. Je recommande "2" sur les processeurs à 4 threads et [number of real cores - 2] sur la plupart des autres processeurs, mais vous devrez peut-être jouer avec ce paramètre. S'il est trop bas, le garbage collection ne peut pas suivre Minecraft, et le jeu bégaie et/ou commence à consommer des quantités de RAM et plante. S'il est trop élevé, cela pourrait ralentir le jeu, surtout si vous utilisez Java 8.
Aucun autre indicateur de "threading" comme ParallelGCThreads ou JVMCIThreads n'est nécessaire, car ils sont activés par défaut avec de bons paramètres automatiques dans Java 8+.
REMARQUE : Les grandes pages nécessitent des privilèges d'administrateur sous Windows. Il s'agit d'un risque de sécurité et vous devez ignorer cette section si vous n'êtes pas à l'aise avec cela.
L'activation de grandes pages améliore les performances des serveurs et des clients Minecraft. Voici quelques excellents tutoriels pour l’activer :
Sous Windows, vous devez exécuter Java et votre lanceur en tant qu'administrateur. Cela signifie cocher la case de compatibilité "Exécuter en tant qu'administrateur" pour javaw.exe , java.exe et your launcher.exe , sinon les grandes pages échoueront silencieusement. Ajoutez -XX:+UseLargePages -XX:LargePageSizeInBytes=2m à vos arguments.
Sous Linux, vous souhaitez généralement utiliser -XX:+UseTransparentHugePages . Pour allouer manuellement de la mémoire (pour une amélioration plus importante des performances), Red Hat propose un bon didacticiel pour les distributions Linux de type RHEL, comme Fedora, CentOS ou Oracle Linux : https://www.redhat.com/en/blog/optimizing -rhel-8-run-java-implementation-minecraft-server
Vérifiez si les grandes pages fonctionnent avec l'argument java -Xlog:gc+init dans Java 17.
Dans n'importe quelle version/plate-forme Java, si les grandes pages ne fonctionnent pas, vous recevrez un avertissement dans le journal similaire à celui-ci :
Avertissement de machine virtuelle de serveur Java HotSpot(TM) 64 bits : JVM ne peut pas utiliser de mémoire de pages volumineuse car elle ne dispose pas de privilèges suffisants pour verrouiller les pages en mémoire.
GraalVM est une nouvelle machine virtuelle Java d'Oracle qui peut améliorer les performances de Minecraft (moddé et vanille). Bien que les gains de FPS client soient modestes, les charges de travail côté serveur, comme la génération de fragments, peuvent bénéficier d'une augmentation de plus de 20 % !
Seule GraalVM Enterprise Edition est livrée avec l'ensemble complet des optimisations. Téléchargez-le via des liens directs depuis 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
(Certaines versions de GraalVM EE sont également disponibles sur l'AUR et sur les dépôts d'Oracle Linux)
Les nouvelles versions pour Mac ARM nécessitent une inscription gratuite sur la page de téléchargement principale d'Oracle : https://www.oracle.com/downloads/graalvm-downloads.html
Ces versions ne sont pas des installateurs Java. Vous devez remplacer manuellement la version de Java de votre lanceur ou utiliser un lanceur Minecraft prenant en charge la spécification de votre chemin Java. Je recommande ATLauncher, Prism Launcher ou GDLauncher. Lorsque vous spécifiez un chemin Java, accédez au dossier « bin » dans le téléchargement GraalVM et utilisez « javaw.exe » ou « java.exe ».
Pour les serveurs, vous devez remplacer la commande "java" dans le fichier de démarrage sh/bat de votre serveur par le chemin complet vers graalvm java, entre guillemets.
Alternativement, vous pouvez l'installer à l'échelle du système en suivant le guide d'Oracle : https://www.graalvm.org/22.2/docs/getting-started/#install-graalvm
Arguments pour 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
Vous devez utiliser G1GC avec ces arguments. GraalVM ne fonctionne actuellement pas avec ZGC ou Shenandoah.
GraalVM EE 22.3.0 corrige tous les bugs connus de Minecraft
Si vous exécutez une ancienne version de GraalVM basée sur Java 8, il existe certains problèmes potentiels :
VectorizeSIMD rend les entités invisibles avec des mods shader comme Optifine, Iris ou Occulus... mais seulement sous certaines conditions. Cela sera corrigé dans GraalVM EE 22.3.0. Voir : oracle/graal#4849
GraalVM CE et EE interrompent tous deux le rendu des constellations dans la version 1.16.5 Astral Sorcery. Ceci est peut-être lié au bug du shader. Voir : HellFirePvP/AstralSorcery#1963
Je n'ai pas encore observé de bugs côté serveur.
Si vous rencontrez d'autres problèmes de mod dont vous pouvez remonter à GraalVM, veuillez créer un problème Github ou publier sur Discord ! Généralement, vous pouvez les contourner en désactivant les principaux indicateurs d'optimisation dgraal , ou en trouvant la bonne fonction avec Dgraal.PrintCompilation=true , et en la contournant avec -Dgraal.GraalCompileOnly=~... une fois que vous avez trouvé la fonction mal compilée.
Un mod Windows « universel » semblable à ReShade, SpecialK présente 2 avantages majeurs en termes de performances :
Un limiteur de trame « intelligent » qui réduit le bégaiement, élimine le déchirement, économise de l'énergie et économise le TDP du processeur pour augmenter en cas de besoin. Il fonctionne même en conjonction avec VRR ou Nvidia Reflex.
Un wrapper OpenGL vers DirectX11 appelé OpenGL-IK qui élimine la surcharge du mode fenêtré de Minecraft et active d'autres fonctionnalités (comme le HDR automatique ou une fenêtre sans bordure redimensionnable).
Téléchargez-le ici : https://wiki.special-k.info/en/SpecialK/Tools
Ajoutez votre lanceur MC et cochez la case « service élevé ». Accédez ensuite à votre dossier java bin où se trouve votre javaw.exe et créez un fichier vide appelé SpecialK.OpenGL32 . Lancez votre lanceur Minecraft avec le lanceur SpecialK, et le lanceur "injectera" ensuite SpecialK dans Minecraft. 
Vous pouvez créer un raccourci sur le bureau vers votre lanceur Minecraft via l'interface utilisateur SpecialK pour encore plus de commodité.
Assurez-vous de désactiver VSync et le limiteur de trame Minecraft dans le jeu.
Un utilisateur a signalé une réduction des FPS lors de l'exécution de SpecialK. Si cela vous arrive, faites-le-moi savoir via Discord ou Github !
Après avoir lancé Minecraft, configurez Java pour qu'il s'exécute avec une priorité de processus « supérieure à la normale » dans Windows avec le Gestionnaire des tâches :
Les utilisateurs de Linux peuvent ajouter sudo nice -n -10 au début de la commande de lancement, mais notez que les niveaux sympas inférieurs à 0 (le "max" étant -20) nécessitent d'exécuter Minecraft en tant que sudo . Vous pouvez également utiliser la commande renice après avoir lancé Minecraft pour éviter ce risque de sécurité.
Il s'agit d'un dépôt fantastique pour trouver des mods de performances : https://github.com/NordicGamerFE/usefulmods
Au lieu d'Optifine, je recommanderais des alternatives plus compatibles comme Sodium + Iris ou Rubidium + Oculus.
Je recommande d'utiliser Java 17 ou, à défaut, Java 11 sauf si 8 est absolument nécessaire. Mais si c'est le cas, ces indicateurs fonctionneront avec OpenJDK8, avec Shenandoh GC (pour Red Hat OpenJDK sur les clients) ou G1GC (pour tout le reste) :
-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
Les utilisateurs x86 Java 8 (c'est-à-dire la plupart des utilisateurs Java 8) peuvent ajouter ces arguments supplémentaires :
-XX:+UseXMMForArrayCopy
Vous pouvez également obtenir les versions Java 8 de GraalVM EE à partir de la section 21.X du site Oracle et utiliser ces arguments :
-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
Assurez-vous de définir -Dgraal.VectorizeSIMD sur false si vous exécutez des shaders.
Exécutez vos serveurs Minecraft sur Clear Linux ! C'est de loin la distribution Linux la plus optimisée prête à l'emploi, et elle possède d'autres fonctionnalités intéressantes (comme un système de configuration sans état). Il exécute également assez bien les clients sur les GPU AMD/Intel : https://web.archive.org/web/20220916090057/https://docs.01.org/clearlinux/latest/tutorials/multi-boot/dual-boot- gagner.html
Oracle Linux est également un bon choix pour les serveurs, car il est raisonnablement bien optimisé et dispose de Graalvm EE disponible via le gestionnaire de packages. Pour les clients, les distributions basées sur Arch comme CachyOS ou EndeavorOS sont excellentes, car elles prennent largement en charge la plupart du matériel.
Assurez-vous que le client Minecraft utilise votre GPU discret ! Vérifiez l'onglet F3 et forcez Minecraft à l'utiliser dans les " Paramètres graphiques Windows ", pas dans le panneau de configuration AMD/Nvidia (car ils ne semblent plus fonctionner).
Les utilisateurs du client Linux Minecraft devraient consulter https://github.com/Admicos/minecraft-wayland
Fermez tout en arrière-plan, y compris Discord, les lanceurs de jeux et votre navigateur ! Minecraft consomme beaucoup de ressources et n'aime pas les autres applications générant des interruptions du processeur ou consommant des E/S de disque, de RAM, etc.
Java 18/19 présente quelques incompatibilités de modules. Ils fonctionneraient apparemment avec certains modpacks, mais je ne sais pas s'il y a des avantages en termes de performances.
Les ajustements Java améliorent les performances du serveur et le bégaiement du client, mais ils n'augmentent pas beaucoup le FPS moyen du client (voire pas du tout). Pour cela, il est bien plus important d'exécuter des pilotes graphiques et des mods de performances corrects/à jour : https://github.com/NordicGamerFE/usefulmods
Ce guide suppose que vous disposez d'un peu de RAM disponible lorsque vous exécutez Minecraft. Si votre configuration est limitée en RAM, essayez de supprimer les arguments suivants en particulier : -XX:NmethodSweepActivity=1 -XX:ReservedCodeCacheSize=400M -XX:NonNMethodCodeHeapSize=12M -XX:ProfiledCodeHeapSize=194M -XX:NonProfiledCodeHeapSize=194M et essayez le serveur. Arguments du G1GC.
L'OpenJ9 d'IBM économise effectivement de la RAM, comme sa réputation le suggère, mais est plus de 30 % plus lent lors de la génération de serveurs lors de mes tests. S'il y a des drapeaux qui le rendent compétitif avec OpenJDK, veuillez me le faire savoir sur Discord ou ici : #9
-XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions déverrouille simplement plus d'indicateurs à utiliser. Ceux-ci peuvent être répertoriés avec les indicateurs -XX:+PrintFlagsFinal et -XX:+JVMCIPrintProperties , voir Flag Dumps-XX:G1MixedGCCountTarget=3 : C'est le nombre de blocs gc oldgen à cibler dans gc "mixte". Ces collections mixtes sont beaucoup plus lentes et le client Minecraft ne génère pas d'oldgen très rapidement, nous pouvons donc réduire cette valeur à 3, 2 ou même 1 pour des pauses GC plus courtes.-XX:+UseNUMA permet des optimisations pour les systèmes multisockets, le cas échéant. Je ne sais pas si cela s'applique aux processeurs MCM comme Ryzen ou Epyc, mais il est automatiquement désactivé s'il n'est pas applicable.-XX:-DontCompileHugeMethods Permet de compiler d'énormes méthodes. Modded Minecraft en possède certains, et nous ne nous soucions pas de l'utilisation plus élevée du processeur du compilateur en arrière-plan.-XX:MaxNodeLimit=240000 -XX:NodeLimitFudgeFactor=8000 Activer l'optimisation de méthodes plus volumineuses. Voir : https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8058148-XX:ReservedCodeCacheSize=400M -XX:NonNMethodCodeHeapSize=12M -XX:ProfiledCodeHeapSize=194M -XX:NonProfiledCodeHeapSize=194M réserve plus d'espace pour le code compilé. Toutes les sections doivent "s'additionner" à ReservedCodeCacheSize . J'ai observé que Minecraft modifié fonctionnait dans la limite par défaut de 250 mégaoctets avec XX:+PrintCodeCache , mais même s'il n'est pas rempli, la taille plus grande rend l'expulsion du code compilé moins agressive.-XX:NmethodSweepActivity=1 (par défaut 10) conserve le code "froid" dans le cache plus longtemps. Il n'y a aucun risque non plus de « remplir » le cache de code, car le code froid est supprimé de manière plus agressive à mesure qu'il se remplit.-XX:+UseStringDeduplication-XX:+UseFastUnorderedTimeStamps Évitez les appels système pour obtenir l'heure. L'impact de cela varie selon le système, mais nous ne nous préoccupons pas vraiment de la précision de l'horodatage de la journalisation.-XX:+UseCriticalJavaThreadPriority Rien ne doit préempter les threads Minecraft. Les threads du GC et du compilateur peuvent attendre.-XX:ThreadPriorityPolicy=1 Utiliser un plus large éventail de priorités de thread. Nécessite sudo sous Linux pour fonctionner. Certains JDK (comme Graal) l'activent par défaut, mais d'autres non.-XX:G1SATBBufferEnqueueingThresholdPercent=30 -XX:G1ConcMarkStepDurationMillis=5 -XX:G1ConcRSHotCardLimit=16 -XX:G1ConcRefinementServiceIntervalMillis=150 : optimise les threads de collecte simultanés de G1GC, toujours en cours de test : https://research.spec.org/icpe_proceedings/2014/p111.pdf-XX:G1RSetUpdatingPauseTimePercent=0 : Nous voulons que tout ce travail soit effectué dans les threads simultanés G1GC, pas dans les pauses.-XX:G1HeapWastePercent=18 Ne vous embêtez pas à collecter l'ancienne génération jusqu'à ce qu'elle soit supérieure à ce pourcentage. Cela évite de déclencher des GC de jeune génération "mixtes" plus lents, ce qui est bien puisque Minecraft (avec suffisamment de mémoire) ne remplit pas l'ancienne génération aussi rapidement. Idée de : https://www.reddit.com/r/Minecraft/comments/k9zb7m/tuning_jvm_gc_for_singleplayer/-XX:GCTimeRatio=99 Comme objectif, 1 % du temps CPU doit être consacré au garbage collection. La valeur par défaut est 12, ce qui semble bien trop bas. La valeur par défaut pour Java 8 était 99.-XX:AllocatePrefetchStyle=3 Génère une instruction de prélecture par ligne de cache. Une prélecture plus agressive est généralement utile sur les processeurs plus récents dotés de caches volumineux. Cela semble casser ZGC. Voir : https://github.com/openjdk/jdk/blob/bd90c4cfa63ba2de26f7482ed5d1704f9be9629f/src/hotspot/share/opto/macro.cpp#L1806-Dgraal.LoopRotation=true Une optimisation non par défaut, qui le sera probablement bientôt.-Dgraal.TuneInlinerExploration=1 Passez plus de temps à prendre des décisions en ligne. Pour Minecraft, nous voulons que le compilateur C2 soit aussi lent et agressif que possible.-Dgraal sont activés par défaut et sont là soit comme contrôle d'intégrité, pour le débogage, soit comme sécurité (si, par exemple, quelqu'un désactive sans le savoir JVCMI avec un autre indicateur).-XX:MaxInlineLevel=15 -XX:MaxVectorSize=32 ) sont simplement copiés à partir des valeurs par défaut de Java 17. D'autres (comme +AggressiveOpts ) ne sont pas par défaut dans certaines anciennes versions de Java 8.-Dgraal.BaseTargetSpending=160 (120 par défaut) dans Graal et quelques autres indicateurs dans OpenJDK. Les processeurs dotés de caches plus importants pourraient en bénéficier.-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 et graal.WriteableCodeCache=true , qui ne semblent pas stables, mais peuvent l'être plus dans GraalVM 22.3.0G1HeapWastePercent .-XX:+PrintFlagsFinal et -XX:+JVMCIPrintProperties pour vider les descriptions/valeurs par défaut des indicateurs.
