Minecraft Performance Flags Benchmarks
1.0.0
これは、Minecraft 用に Java を調整するためのガイドです。すべてのフラグと微調整は回帰テストのために個別にベンチマークされ、冗長性を避けるために Java のデフォルトに対してチェックされます。
これらの調整により、サーバーとクライアントの一部のスタッターが顕著に軽減されますが、せいぜい控えめな TPS 向上と最小限の FPS 向上のみが期待され、RAM と CPU の使用量が若干増加します。そして、それらは Spark や Observable などの MOD で遅延を解消する代わりにはなりません。
質問などのDiscord：https://discord.gg/zeFSR9PnUw
すべてのフラグは Benchmark.py スクリプトでテストされます。進行中の Benchmarks.md を参照してください。
Minecraft 1.16.5 以降の場合は、Java 17 を使用してください。Curseforge や Prism Launcher などの一部のランチャーでは、1.16.X で Java 8 を使用するように求められますが、Minecraft 1.16.5 以降、1.18 以降のすべての MOD、およびほとんどの1.16.5 MOD は互換性があります。 Java17では。
Java 17 では動作しない場合でも、Java 11 では動作する場合があります。
1.12.2 以下では通常、Java 8 が必要です。
Azul、Microsoft、Adoptium、Amazon などの Java ランタイムは基本的に同一です。いくつかの注目すべき例外:
Oracle GraalVM Enterprise Edition は、より積極的な Java コンパイラを備えています。これは私が個人的に Minecraft を実行しているものです。以下の GraalVM セクションを参照してください。
Intel の Clear Linux OpenJDK は、他の OpenJDK と同じコードを使用します (互換性が高い) が、ビルド プロセス自体と依存関係は新しい CPU 向けに最適化されています。 Clear Linux のリポジトリからswupd経由で、Distrobox、または Docker から取得します。 Java 17 リリースにロールバックする必要があること、および Java 18 ではパフォーマンス強化の一部が元に戻ることに注意してください。
Azul の Prime OpenJDK は、llvm にフックされるため非常に高速ですが、現時点ではほとんどの MOD と互換性がなく、Linux のみに対応しています。ここから入手してください: https://docs.azul.com/prime/prime-quick-start-tar
Red Hat Java 8には Shenandoah ガベージ コレクターが搭載されています。無料の電子メールサインアップの背後にゲートがあります: https://developers.redhat.com/products/openjdk/download
IBM の OpenJ9は Minecraft でははるかに遅く、他の Java ビルドとはまったく異なるフラグを使用しますが、消費するメモリは OpenJDK ベースのランタイムよりも少なくなります。低メモリ消費フラグについては、FAQ、ベンチマーク フォルダー、およびこの要点を参照してください。
何を選択すればよいかわからない場合は、GraalVM EE (以下を参照) または最新の Adoptium Java 17 JRE をお勧めします: https://adoptium.net/
Couleur は、ここで JRE の適切な実行リストを管理しています: https://rentry.co/JREs
これらの最適化されたフラグは、Java 11 以降のビルドで実行されます。これらはサーバーとクライアントの両方で動作します。
-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
これらの 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
ここで説明されているように、最小メモリと最大メモリ ( -xmsと-xmx ) は同じ値に設定する必要があります: https://dzone.com/articles/benefits-of-setting-initial-and-maximum-memory-siz
例外が 1 つあります。メモリの少ないシステムを使用していて、Minecraft が RAM のほぼすべてを占有している場合は、最小メモリを最大メモリよりも低く設定して、可能な限り節約してください。
サイズはメガバイト ( -Xms4096M ) またはギガバイト ( -Xmx8G ) 単位で設定されます。
メモリの割り当てが多すぎると、十分な余裕がある場合でも、GC が壊れたり、Minecraft の速度が低下したりする可能性があります。割り当てが少なすぎると、ゲームが遅くなったり、ゲームが中断されたりする可能性があります。 Minecraft の実行中は Windows タスク マネージャー (または DE のシステム モニター) を注意深く監視し、必要な分だけ (通常は 8G 未満) を割り当てます。 sparkc gcmonitor 、割り当てが多すぎる (一時停止が長すぎる) か、低すぎる (通知でメモリ不足の警告が表示される頻繁な GC) かを通知します。
ガベージ コレクション フラグは、Minecraft サーバーとクライアントに追加する必要があります。デフォルトでは、クライアントでのスタッターやサーバーでの遅れとしてガベージ マニフェストの停止と収集を「一時停止」します。 Spark MOD で/sparkc gcmonitorコマンドを使用して、ゲーム内の一時停止を観察します。古い世代の一時停止は問題があり、若い世代の G1GC コレクションは頻度は低いものの、認識できないほど十分に短い必要があります。
フラグのセットを 1 つ選択します。クライアントでは Shenandoah を、強力な Java 17 サーバーでは ZGC を、 Graal または RAM とコアの少ないサーバー/クライアントでは G1GC をお勧めします。
ZGC は、高メモリ/高コア数のサーバーに最適です。私が測定できるサーバー スループットのヒットはなく、まったく途切れません。ただし、他のガベージ コレクターよりも多くの RAM とより多くのコアが必要です。
残念ながら、私の (8 コア/16 スレッド) ラップトップでは、クライアントの FPS が大幅に低下しました。ベンチマーク フォルダー内の「ZGC」ベンチマークを参照してください。 Java 8 では利用できず、Java 11 では Java 17 よりもパフォーマンスが大幅に低下します。
-XX:+UseZGC -XX:AllocatePrefetchStyle=1 -XX:-ZProactiveこれを有効にしますが、通常の他の GC よりも多くの RAM とより多くのConcGCThreadsを割り当てます。 ZGC は AllocatePrefetchStyle=3 を好まないため、これを 1 に設定すると前のエントリがオーバーライドされることに注意してください。 U
Shenandoah はクライアントでは良好なパフォーマンスを示しますが、テストではサーバーのスループットが低下します。 -XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu -XX:ShenandoahGuaranteedGCInterval=1000000 -XX:AllocatePrefetchStyle=1で有効にします。
その他の調整オプションについては、こちらをご覧ください。 「herustic」オプションと「mode」オプションは、私にとってはあまり変わりません（「compact」を除いて、これは使用しないでください）。 ZGC と同様に、Shenandoah は AllocatePrefetchStyle=3 を好みません。
Shenandoah は Java 8 には含まれていないことに注意してください。また、Oracle Java ビルドにも含まれていません。 Java 8 ユーザーの場合、Shenandoah を使用するには Red Hat OpenJDK を使用する必要があります: https://developers.redhat.com/products/openjdk/download
G1GC はデフォルトのガベージ コレクターであり、GraalVM ユーザーが使用できる唯一のガベージ コレクターです。 Aikar の有名な Minecraft サーバーの G1GC 引数はクライアント上でうまく動作しますが、2 つの注意点があります。1 つはG1NewSizePercent非常に高く設定することでMaxGCPauseMillisパラメータを効果的にクランプし、一部のクライアントで長いスタッターを生成することと、oldgen ガベージを積極的に収集しすぎることです (クライアントが生成するものは 1 つよりもはるかに少ないため)実装されたサーバー)。
これらは aikar フラグに似ていますが、一時停止が短く、頻度が高く、G1 混合コレクションがあまり積極的ではなく、バックグラウンド コレクションがより積極的です: -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とMaxGCPauseMillis使用して、若い世代のコレクションの頻度と期間を調整できます。セットアップで古い世代の一時停止が発生する場合は、 G1HeapWastePercent=18削除する必要があります。あるいは、この値を上げてG1MixedGCCountTarget 2 または 1 に設定して、混合ガベージ コレクションをさらに遅延させることもできます (メモリ使用量が増加します)。
サーバーでは、長い一時停止がより許容されます。これらのフラグは、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]ガベージ コレクターが使用できるバックグラウンド スレッドの最大数を制御し、デフォルトはlogical (hyperthreaded) cores / 4です。 Java の最新バージョンでは、必要に応じて gc スレッドの数が削減されます。
場合によっては (特に ZGC または Shenandoh の場合)、このスレッド キャップをデフォルトを超えて大きくしたいことがあります。 4 スレッドの CPU では「2」を、その他のほとんどの CPU では[number of real cores - 2]をお勧めしますが、このパラメータを調整する必要がある場合があります。この値が低すぎると、ガベージ コレクションが Minecraft に追いつかず、ゲームが途切れたり、RAM を大量に消費し始めてクラッシュしたりします。高すぎると、特に Java 8 を実行している場合、ゲームの速度が低下する可能性があります。
ParallelGCThreadsやJVMCIThreadsなどの他の「スレッド化」フラグは、Java 8 以降の適切な自動設定でデフォルトで有効になっているため、必要ありません。
注: ラージ ページには Windows の管理者権限が必要です。これはセキュリティ上のリスクであるため、これに慣れていない場合は、このセクションをスキップしてください。
大きなページを有効にすると、Minecraft サーバーとクライアントのパフォーマンスが向上します。これを有効にするための優れたチュートリアルをいくつか紹介します。
Windows では、Java とランチャーを管理者として実行する必要があります。つまり、 javaw.exe 、 java.exe 、およびyour launcher.exeの「管理者として実行」互換性チェックボックスをオンにすることを意味します。そうでないと、Large Pages は警告なしに失敗します。引数に-XX:+UseLargePages -XX:LargePageSizeInBytes=2mを追加します。
Linux では、通常-XX:+UseTransparentHugePagesを使用します。代わりに手動でメモリを割り当てるため (パフォーマンスを大幅に向上させるため)、Red Hat には、Fedora、CentOS、Oracle Linux などの RHEL ライクな Linux ディストリビューション向けの優れたチュートリアルがあります: https://www.redhat.com/en/blog/optimizing -rhel-8-run-java-implementation-minecraft-server
Java 17 で-Xlog:gc+init java 引数を使用して大きなページが動作するかどうかを確認してください。
どの Java バージョン/プラットフォームでも、大きなページが機能しない場合は、次のような警告がログに記録されます。
Java HotSpot(TM) 64 ビット サーバー VM の警告: メモリ内のページをロックする十分な権限がないため、JVM は大きなページ メモリを使用できません。
GraalVM は、(MOD およびバニラの) Minecraft のパフォーマンスを向上させることができる Oracle の新しい Java VM です。クライアントの FPS の向上はわずかですが、チャンク生成などのサーバー側のワークロードは 20% 以上向上します。
GraalVM Enterprise Edition のみに完全な最適化セットが付属しています。 Oracle からの直接リンクを介してダウンロードします。
Windows AMD64 (64 ビット): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA17_22_3_1/graalvm-ee-java17-windows-amd64-22.3.1.zip
Linux AMD64 (64 ビット): 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 ビット): 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 ビット): 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 ビット): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA11_22_3_1/graalvm-ee-java11-windows-amd64-22.3.1.zip
Linux AMD64 (64 ビット): 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 ビット): 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 ビット): 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 ビット): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA8_21_3_5/graalvm-ee-java8-windows-amd64-21.3.5.zip
Linux AMD64 (64 ビット): 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 ビット): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA8_21_3_5/graalvm-ee-java8-darwin-amd64-21.3.5.tar.gz
(一部の GraalVM EE バージョンは、AUR および Oracle Linux のリポジトリでも入手できます)
ARM Mac の新しいバージョンを使用するには、Oracle のメイン ダウンロード ページ (https://www.oracle.com/downloads/graalvm-downloads.html) で無料登録する必要があります。
これらのリリースは Java インストーラーではありません。ランチャーの Java バージョンを手動で置き換えるか、Java パスの指定をサポートする Minecraft ランチャーを使用する必要があります。 ATLauncher、Prism Launcher、または GDLauncher をお勧めします。 Java パスを指定する場合は、GraalVM ダウンロードの「bin」フォルダーに移動し、「javaw.exe」または「java.exe」を使用します。
サーバーの場合は、サーバー起動 sh/bat ファイル内の「java」コマンドを、引用符で囲んだ graalvm java への完全パスに置き換える必要があります。
あるいは、Oracle のガイドに従ってシステム全体にインストールすることもできます: https://www.graalvm.org/22.2/docs/getting-started/#install-graalvm
GraalVM EE 22+ Java 17 (または 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
これらの引数を指定して G1GC を使用する必要があります。 GraalVM は現在、ZGC または Shenandoah では動作しません。
GraalVM EE 22.3.0 は、Minecraft の既知のバグをすべて修正します
Java 8 ベースの古いバージョンの GraalVM を実行している場合、いくつかの潜在的な問題が発生します。
VectorizeSIMD Optifine、Iris、Occulus などのシェーダー MOD を使用してエンティティを非表示にします...ただし、特定の条件下でのみです。これは GraalVM EE 22.3.0 で修正される予定です。参照: oracle/graal#4849
GraalVM CE と EE はどちらも、1.16.5 Astral Sorcery でのコンステレーション レンダリングを破壊します。これはシェーダーのバグに関連している可能性があります。参照: HellFirePvP/AstralSorcery#1963
サーバー側のバグはまだ観察されていません。
GraalVM に遡ることができる他の Mod の問題が発生した場合は、Github の問題を作成するか、Discord に投稿してください。一般に、主要なdgraal最適化フラグを無効にするか、 Dgraal.PrintCompilation=trueで適切な関数を見つけ、コンパイルミスの関数を見つけたら-Dgraal.GraalCompileOnly=~...で回避することで、これらを回避できます。
ReShade に似た「ユニバーサル」 Windows MOD である SpecialK には、パフォーマンス上の 2 つの大きな利点があります。
スタッターを軽減し、ティアリングを排除し、電力を節約し、CPU TDP を節約して必要なときにブーストする「スマート」フレーム リミッター。 VRR や Nvidia Reflex と組み合わせても機能します。
OpenGL-IK と呼ばれる OpenGL-to-DirectX11 ラッパー。Minecraft のウィンドウ モードのオーバーヘッドを排除し、他の機能 (自動 HDR やサイズ変更可能なボーダーレス ウィンドウなど) を有効にします。
ここからダウンロードしてください: https://wiki.special-k.info/en/SpecialK/Tools
MC ランチャーを追加し、「昇格されたサービス」チェックボックスをオンにします。次に、 javaw.exe がある Java bin フォルダーに移動し、 SpecialK.OpenGL32という空のファイルを作成します。 SpecialK ランチャーを使用して Minecraft ランチャーを起動すると、ランチャーが SpecialK を Minecraft に「注入」します。 
さらに便利にするために、SpecialK UI を通じて Minecraft ランチャーへのデスクトップ ショートカットを作成できます。
VSync とゲーム内の Minecraft フレーム リミッターを必ずオフにしてください。
あるユーザーは、SpecialK を実行すると FPS が低下すると報告しました。このようなことが起こった場合は、Discord または Github を通じてお知らせください。
Minecraft を起動した後、タスク マネージャーを使用して Windows で Java を「通常より高い」プロセス優先度で実行するように設定します。
Linux ユーザーは、起動コマンドの先頭にsudo nice -n -10を追加できますが、0 未満の nice レベル (「最大」は -20) では、Minecraft をsudoとして実行する必要があることに注意してください。または、Minecraft の起動後にreniceコマンドを使用して、このセキュリティ リスクを回避します。
これはパフォーマンス MOD を見つけるための素晴らしいリポジトリです: https://github.com/NordicGamerFE/usefulmods
Optifine の代わりに、Sodium + Iris または Rubidium + Oculus など、より互換性のある代替品をお勧めします。
8 が絶対に必要でない限り、Java 17 を使用するか、そうでない場合は Java 11 を使用することをお勧めします。しかし、そうである場合、これらのフラグは、Shenandoh GC (クライアント上の Red Hat OpenJDK の場合) または G1GC (その他すべての場合) とともに OpenJDK8 で動作します。
-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
x86 Java 8 ユーザー (ほとんどの Java 8 ユーザー) は、次の追加の引数を追加できます。
-XX:+UseXMMForArrayCopy
Oracle サイトの 21.X セクションから GraalVM EE の Java 8 バージョンを入手し、次の引数を使用することもできます。
-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
シェーダーを実行する場合は、必ず-Dgraal.VectorizeSIMD falseに設定してください。
Clear Linux で Minecraft サーバーを実行してください!これは、すぐに使用できる Linux ディストリビューションの中で最も最適化されており、他にもいくつかの優れた機能 (ステートレス設定システムなど) を備えています。また、AMD/Intel GPU 上でクライアントを非常にうまく実行します: https://web.archive.org/web/20220916090057/https://docs.01.org/clearlinux/latest/tutorials/multi-boot/dual-boot- win.html
Oracle Linux は、すぐに使用できる状態で適切に最適化されており、パッケージ マネージャー経由で Graalvm EE を利用できるため、サーバーにも適しています。クライアントにとって、CachyOS や EndeavorOS などの Arch ベースのディストリビューションは、ほとんどのハードウェアを幅広くサポートしているため、優れています。
Minecraft クライアントが個別の GPU を使用していることを確認してください。 F3 タブを確認し、AMD/Nvidia コントロール パネル (機能しなくなったようなので)ではなく、「 Windows グラフィック設定」で Minecraft がそれを使用するように強制します。
Minecraft クライアント Linux ユーザーは https://github.com/Admicos/minecraft-wayland をチェックしてください。
Discord、ゲームランチャー、ブラウザなど、バックグラウンドにあるものをすべて閉じてください。 Minecraft はリソースを大量に消費するため、他のアプリが CPU 割り込みを生成したり、ディスク I/O、RAM などを消費したりすることを好みません。
Java 18/19 には、MOD との非互換性がいくつかあります。一部の Modpack で動作すると報告されていますが、パフォーマンス上の利点があるかどうかはわかりません。
Java の調整により、サーバーのパフォーマンスとクライアントの途切れが改善されますが、クライアントの平均 FPS は (たとえあったとしても) あまり向上しません。そのためには、正しい/最新のグラフィックス ドライバーとパフォーマンス MOD を実行することがはるかに重要です: https://github.com/NordicGamerFE/usefulmods
このガイドは、Minecraft を実行するときに少しの RAM に余裕があることを前提としています。セットアップが RAM に制約されている場合は、特に次の引数を削除してみてください: -XX:NmethodSweepActivity=1 -XX:ReservedCodeCacheSize=400M -XX:NonNMethodCodeHeapSize=12M -XX:ProfiledCodeHeapSize=194M -XX:NonProfiledCodeHeapSize=194M 、サーバーを試してください。 G1GC 引数。
IBM の OpenJ9 は、その評判が示すように確かに RAM を節約しますが、私のテストではサーバー チャンクゲンで 30% 以上遅くなります。 OpenJDK と競合できるフラグがある場合は、Discord またはここで知らせてください: #9
-XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions使用するフラグをさらにロック解除するだけです。これらは、 -XX:+PrintFlagsFinalフラグと-XX:+JVMCIPrintPropertiesフラグを使用してリストできます。「フラグ ダンプ」を参照してください。-XX:G1MixedGCCountTarget=3 : これは、「混合」GC でターゲットとする oldgen gc ブロックの数です。これらの混合コレクションは非常に遅く、Minecraft クライアントは oldgen をすぐには生成しないため、GC の一時停止を短くするには、この値を 3、2、または 1 に下げることができます。-XX:+UseNUMA 、該当する場合、マルチソケット システムの最適化を有効にします。これが Ryzen や Epyc などの MCM CPU に適用されるかどうかはわかりませんが、適用されない場合は自動的に無効になります。-XX:-DontCompileHugeMethods巨大なメソッドのコンパイルを許可します。 Mod を導入した Minecraft にはこれらのいくつかがあり、バックグラウンド コンパイラの CPU 使用率の上昇は気にしません。-XX:MaxNodeLimit=240000 -XX:NodeLimitFudgeFactor=8000より大きなメソッドの最適化を有効にします。参照: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8058148-XX:ReservedCodeCacheSize=400M -XX:NonNMethodCodeHeapSize=12M -XX:ProfiledCodeHeapSize=194M -XX:NonProfiledCodeHeapSize=194Mコンパイルされたコード用により多くのスペースを予約します。すべてのセクションを「合計」してReservedCodeCacheSizeにする必要があります。私は、MOD を追加した Minecraft がXX:+PrintCodeCache使用するとデフォルトの 250 メガバイト制限に達するのを観察しましたが、たとえその制限が満たされなかったとしても、サイズが大きくなるとコンパイル済みコードのエビクションがそれほど積極的ではなくなります。-XX:NmethodSweepActivity=1 (デフォルトは 10) は、「コールド」コードをキャッシュに長時間保持します。コールド コードは、いっぱいになるとより積極的に削除されるため、コード キャッシュが「いっぱいになる」リスクもありません。-XX:+UseStringDeduplication-XX:+UseFastUnorderedTimeStamps時刻を取得するためのシステム コールを回避します。この影響はシステムごとに異なりますが、ログのタイムスタンプの精度についてはあまり関心がありません。-XX:+UseCriticalJavaThreadPriority Minecraft スレッドを優先するものは何もありません。 GC スレッドとコンパイラ スレッドは待機できます。-XX:ThreadPriorityPolicy=1より広範囲のスレッド優先順位を使用します。 Linux で sudo が機能する必要があります。一部の JDK (Graal など) ではこれがデフォルトで有効になっていますが、有効になっていないものもあります。-XX:G1SATBBufferEnqueueingThresholdPercent=30 -XX:G1ConcMarkStepDurationMillis=5 -XX:G1ConcRSHotCardLimit=16 -XX:G1ConcRefinementServiceIntervalMillis=150 : G1GC の同時収集スレッドを最適化します。まだテスト中です。 https://research.spec.org/icpe_proceedings/2014/p111.pdf-XX:G1RSetUpdatingPauseTimePercent=0 : この作業はすべて、一時停止ではなく G1GC 同時スレッドで実行されるようにします。-XX:G1HeapWastePercent=18このパーセントを超えるまでは、古い世代からわざわざ収集する必要はありません。これにより、低速の「混合」若い世代の GC がトリガーされるのを回避できますが、Minecraft (十分なメモリがある) では古い世代がそれほど早くいっぱいにならないため、これは問題ありません。アイデアの出典: https://www.reddit.com/r/Minecraft/comments/k9zb7m/tuning_jvm_gc_for_singleplayer/-XX:GCTimeRatio=99目標として、CPU 時間の 1% をガベージ コレクションに費やす必要があります。デフォルトは 12 ですが、これは低すぎるように思えます。 Java 8 のデフォルトは 99 でした。-XX:AllocatePrefetchStyle=3キャッシュ ラインごとに 1 つのプリフェッチ命令を生成します。一般に、より積極的なプリフェッチは、大規模なキャッシュを備えた新しい CPU で役立ちます。 ZGCが壊れそうです。参照: https://github.com/openjdk/jdk/blob/bd90c4cfa63ba2de26f7482ed5d1704f9be9629f/src/hotspot/share/opto/macro.cpp#L1806-Dgraal.LoopRotation=trueデフォルトではない最適化ですが、おそらくすぐにデフォルトになるでしょう。-Dgraal.TuneInlinerExploration=1インライン化の決定により多くの時間を費やします。 Minecraft では、C2 コンパイラを可能な限り低速で積極的にしたいと考えています。-Dgraal引数はデフォルトで有効になっており、デバッグのための健全性チェック、またはフェールセーフ (たとえば、誰かが他のフラグで無意識に JVCMI を無効にした場合) として存在します。-XX:MaxInlineLevel=15 -XX:MaxVectorSize=32など) は、Java 17 のデフォルトからコピーされただけです。その他 ( +AggressiveOptsなど) は、一部の古い Java 8 ビルドでのみデフォルトではありません。-Dgraal.BaseTargetSpending=160 (デフォルト 120) および OpenJDK のその他のフラグを使用した、より積極的なインライン化。より大きなキャッシュを備えた CPU では、この利点が得られる可能性があります。-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およびgraal.WriteableCodeCache=trueは安定していないようですが、GraalVM 22.3.0 ではより安定している可能性があります。G1HeapWastePercent値。-XX:+PrintFlagsFinalと-XX:+JVMCIPrintPropertiesフラグを使用して、フラグの説明/デフォルトをダンプします。
