Dies ist eine Anleitung zum Optimieren von Java für Minecraft. Jedes Flag und jede Optimierung wird individuell einem Benchmarking unterzogen, um Regressionen zu testen, und mit Java-Standards verglichen, um Redundanz zu vermeiden.
Während diese Optimierungen einige Server- und Client-Ruckler deutlich reduzieren, erwarten Sie nur bescheidene TPS-Zuwächse + bestenfalls minimale FPS-Zuwächse und eine etwas erhöhte RAM- und CPU-Auslastung. Und sie sind kein Ersatz für die Beseitigung von Verzögerungen mit Mods wie Spark oder Observable.
Discord für Fragen und dergleichen: https://discord.gg/zeFSR9PnUw
Alle Flags werden mit dem Benchmark.py-Skript getestet. Siehe die in Arbeit befindliche Benchmarks.md.
Verwenden Sie für Minecraft 1.16.5 und höher Java 17. Einige Launcher wie Curseforge und Prism Launcher fordern Sie auf, Java 8 auf 1.16.X zu verwenden, aber Minecraft 1.16.5+, alle 1.18+ Mods und die meisten 1.16.5 Mods sind kompatibel mit Java 17.
Manchmal funktioniert Java 11, während Java 17 nicht funktioniert.
1.12.2 und niedriger erfordern im Allgemeinen Java 8.
Java-Runtimes von Azul, Microsoft, Adoptium, Amazon usw. sind grundsätzlich identisch. Einige bemerkenswerte Ausnahmen:
Oracle GraalVM Enterprise Edition verfügt über einen aggressiveren Java-Compiler. Damit betreibe ich persönlich Minecraft, siehe Abschnitt GraalVM weiter unten.
Intels Clear Linux OpenJDK verwendet den gleichen Code wie jedes andere OpenJDK (was es hochkompatibel macht), aber der Build-Prozess selbst und die Abhängigkeiten sind für neuere CPUs optimiert. Holen Sie es sich über swupd
aus den Repos von Clear Linux, von Distrobox oder von Docker. Beachten Sie, dass Sie ein Rollback auf die Version Java 17 durchführen müssen und dass Java 18 einige der Leistungsverbesserungen rückgängig macht.
Azuls Prime OpenJDK ist sehr schnell, da es sich in llvm einklinkt, ist aber derzeit mit den meisten Mods nicht kompatibel und nur für Linux verfügbar. Holen Sie es sich hier: https://docs.azul.com/prime/prime-quick-start-tar
Red Hat Java 8 verfügt über den Shenandoah-Garbage Collector. Es ist hinter einer kostenlosen E-Mail-Anmeldung verborgen: https://developers.redhat.com/products/openjdk/download
IBMs OpenJ9 ist ... in Minecraft viel langsamer und verwendet völlig andere Flags als alle anderen Java-Builds, verbraucht aber weniger Speicher als OpenJDK-basierte Laufzeiten. Informationen zu Flags für geringen Speicherverbrauch finden Sie in den FAQ, im Ordner „Benchmarks“ und in diesem Gist.
Wenn Sie nicht wissen, was Sie auswählen sollen, empfehle ich GraalVM EE (siehe unten) oder die neueste Adoptium Java 17 JRE: https://adoptium.net/
Couleur führt hier eine gute laufende Liste von JREs: https://rentry.co/JREs
Diese optimierten Flags laufen mit jedem Java 11+ Build. Sie funktionieren sowohl auf Servern als auch auf 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
Sie müssen diesen Java-Argumenten Garbage-Collection-Flags hinzufügen.
-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
Der minimale und maximale ( -xms
und -xmx
) Speicher sollte auf denselben Wert eingestellt werden, wie hier erläutert: https://dzone.com/articles/benefits-of-setting-initial-and-maximum-memory-siz
Eine Ausnahme: Wenn Sie ein System mit wenig Arbeitsspeicher verwenden und Minecraft fast den gesamten Arbeitsspeicher beansprucht, stellen Sie Ihren Mindestspeicher unter Ihren Maximalspeicher ein, um so viel wie möglich zu sparen.
Die Größen werden in Megabyte ( -Xms4096M
) oder Gigabyte ( -Xmx8G
) festgelegt.
Das Zuweisen von zu viel Speicher kann GC beschädigen oder Minecraft nur verlangsamen, selbst wenn Sie noch viel Speicher übrig haben. Auch eine zu geringe Zuteilung kann das Spiel verlangsamen oder unterbrechen. Behalten Sie den Windows-Task-Manager (oder den Systemmonitor Ihres DE) genau im Auge, während Minecraft ausgeführt wird, und weisen Sie nur so viel zu, wie benötigt wird (normalerweise weniger als 8 GB). sparkc gcmonitor
teilt Ihnen mit, ob Ihre Zuweisung zu hoch (die Pausen werden zu lang) oder zu niedrig (häufiger GC mit einer Warnung zu wenig Speicher in der Benachrichtigung) ist.
Garbage-Collection-Flags müssen zu Minecraft-Servern und -Clients hinzugefügt werden , da sich die standardmäßigen „Pausen“ zum Stoppen und Sammeln von Garbage als Stottern auf dem Client und Verzögerungen auf den Servern manifestieren. Verwenden Sie den Befehl /sparkc gcmonitor
im Spark-Mod, um Pausen im Spiel zu beobachten. Alle Pausen der alten Generation sind schlecht, und G1GC-Sammlungen der jungen Generation sollten selten, aber kurz genug sein, um nicht wahrnehmbar zu sein.
Wählen Sie einen Satz Flaggen aus. Ich empfehle Shenandoah auf Clients , ZGC auf leistungsstarken Java 17-Servern und G1GC auf Graal oder auf Servern/Clients mit weniger RAM und weniger Kernen:
ZGC eignet sich hervorragend für Server mit viel Speicher und hoher Kernanzahl. Ich kann keinen Einfluss auf den Serverdurchsatz feststellen und ruckelt absolut nicht. Es benötigt jedoch mehr RAM und mehr Kerne als andere Garbage Collectors.
Leider hat es auf meinem Laptop (8-Core/16-Thread) einen erheblichen Client-FPS-Einbruch. Siehe den „ZGC“-Benchmark im Benchmark-Ordner. Es ist in Java 8 nicht verfügbar und in Java 11 deutlich weniger leistungsfähig als in Java 17.
-XX:+UseZGC -XX:AllocatePrefetchStyle=1 -XX:-ZProactive
aktiviert es, weist aber mehr RAM und mehr ConcGCThreads
zu, als Sie es normalerweise für andere GCs tun würden. Beachten Sie, dass ZGC AllocatePrefetchStyle=3 nicht mag, weshalb das Setzen auf 1 den vorherigen Eintrag überschreibt. U
Shenandoah schneidet auf Clients gut ab, beeinträchtigt in meinen Tests jedoch den Serverdurchsatz. Aktivieren Sie es mit -XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu -XX:ShenandoahGuaranteedGCInterval=1000000 -XX:AllocatePrefetchStyle=1
Weitere Tuning-Optionen finden Sie hier. Die Optionen „herustic“ und „mode“ ändern für mich nicht viel (außer „compact“, das Sie nicht verwenden sollten). Wie ZGC mag Shenandoah AllocatePrefetchStyle=3 nicht.
Beachten Sie, dass Shenandoah nicht in Java 8 enthalten ist. Es ist auch nicht in Oracle Java-Builds enthalten! Wenn Sie ein Java 8-Benutzer sind, müssen Sie Red Hat OpenJDK verwenden, um Shenandoah verwenden zu können: https://developers.redhat.com/products/openjdk/download
G1GC ist der Standard-Garbage Collector und der einzige verfügbare Garbage Collector für GraalVM-Benutzer. Aikars berühmte Minecraft-Server-G1GC-Argumente laufen hervorragend auf Clients, mit zwei Einschränkungen: Sie schränken den MaxGCPauseMillis
-Parameter effektiv ein, indem sie G1NewSizePercent
so hoch setzen, dass es bei einigen Clients zu langen Stottern kommt, und sie sammeln Oldgen-Müll zu aggressiv (da der Client weit weniger als a produziert). bestückter Server).
Diese ähneln den Aikar-Flags, jedoch mit kürzeren, häufigeren Pausen, einer weniger aggressiven gemischten G1-Sammlung und einer aggressiveren Hintergrundsammlung: -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
und MaxGCPauseMillis
können verwendet werden, um die Häufigkeit/Dauer Ihrer Sammlungen der jungen Generation anzupassen. G1HeapWastePercent=18
sollte entfernt werden, wenn in Ihrem Setup Pausen der alten Generation auftreten. Alternativ können Sie den Wert erhöhen und G1MixedGCCountTarget
auf 2 oder 1 setzen, um die gemischte Garbage Collection noch langsamer zu gestalten (auf Kosten einer höheren Speichernutzung).
Längere Pausen sind auf Servern akzeptabler. Diese Flags kommen den Aikar-Standardwerten sehr nahe:
-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]
steuert die maximale Anzahl von Hintergrundthreads, die der Garbage Collector verwenden darf, und verwendet standardmäßig logical (hyperthreaded) cores / 4
. Aktuelle Java-Versionen reduzieren bei Bedarf die Anzahl der GC-Threads.
In manchen Fällen (insbesondere bei ZGC oder Shenandoh) möchten Sie diese Thread-Obergrenze über den Standardwert hinaus erhöhen. Ich empfehle „2“ für CPUs mit 4 Threads und [number of real cores - 2]
für die meisten anderen CPUs, aber möglicherweise müssen Sie mit diesem Parameter experimentieren. Wenn er zu niedrig ist, kann die Speicherbereinigung nicht mit Minecraft mithalten und das Spiel stottert und/oder fängt an, viel RAM zu verbrauchen und stürzt ab. Wenn der Wert zu hoch ist, kann dies das Spiel verlangsamen, insbesondere wenn Sie Java 8 verwenden.
Es sind keine weiteren „Threading“-Flags wie ParallelGCThreads
oder JVMCIThreads
erforderlich, da sie in Java 8+ standardmäßig mit guten automatischen Einstellungen aktiviert sind.
HINWEIS: Für große Seiten sind unter Windows Administratorrechte erforderlich. Dies stellt ein Sicherheitsrisiko dar und Sie sollten diesen Abschnitt überspringen, wenn Sie damit nicht einverstanden sind.
Durch die Aktivierung großer Seiten wird die Leistung von Minecraft-Servern und -Clients verbessert. Hier sind einige tolle Tutorials zum Aktivieren:
Unter Windows müssen Sie Java und Ihren Launcher als Administrator ausführen. Das bedeutet, dass Sie das Kompatibilitätskästchen „Als Administrator ausführen“ für javaw.exe
, java.exe
und your launcher.exe
aktivieren, da große Seiten andernfalls stillschweigend fehlschlagen. Fügen Sie -XX:+UseLargePages -XX:LargePageSizeInBytes=2m
zu Ihren Argumenten hinzu.
Unter Linux möchten Sie im Allgemeinen -XX:+UseTransparentHugePages
verwenden. Um stattdessen manuell Speicher zuzuweisen (für eine größere Leistungssteigerung), bietet Red Hat ein gutes Tutorial für RHEL-ähnliche Linux-Distributionen wie Fedora, CentOS oder Oracle Linux: https://www.redhat.com/en/blog/optimizing -rhel-8-run-java-implementation-minecraft-server
Überprüfen Sie, ob große Seiten mit dem Java-Argument -Xlog:gc+init
in Java 17 funktionieren.
Wenn große Seiten nicht funktionieren, erhalten Sie in jeder Java-Version/Plattform eine Warnung im Protokoll ähnlich dieser:
Java HotSpot(TM) 64-Bit Server VM-Warnung: Die JVM kann keinen großen Seitenspeicher verwenden, da sie nicht über ausreichende Berechtigungen zum Sperren von Seiten im Speicher verfügt.
GraalVM ist eine neue Java-VM von Oracle, die die Leistung von (modifiziertem und Vanilla-)Minecraft verbessern kann. Während die Client-FPS-Zuwächse bescheiden ausfallen, können serverseitige Workloads wie die Chunk-Generierung um mehr als 20 % gesteigert werden!
Nur die GraalVM Enterprise Edition verfügt über alle Optimierungen. Laden Sie es über direkte Links von Oracle herunter:
Windows AMD64 (64-Bit): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA17_22_3_1/graalvm-ee-java17-windows-amd64-22.3.1.zip
Linux AMD64 (64-Bit): 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-Bit): 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-Bit): 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-Bit): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA11_22_3_1/graalvm-ee-java11-windows-amd64-22.3.1.zip
Linux AMD64 (64-Bit): 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-Bit): 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-Bit): 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-Bit): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA8_21_3_5/graalvm-ee-java8-windows-amd64-21.3.5.zip
Linux AMD64 (64-Bit): 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-Bit): https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA8_21_3_5/graalvm-ee-java8-darwin-amd64-21.3.5.tar.gz
(Ausgewählte GraalVM EE-Versionen sind auch im AUR und in den Repos von Oracle Linux verfügbar.)
Neue Versionen für ARM-Macs erfordern eine kostenlose Registrierung auf der Haupt-Download-Seite von Oracle: https://www.oracle.com/downloads/graalvm-downloads.html
Bei diesen Versionen handelt es sich nicht um Java-Installationsprogramme. Sie müssen die Java-Version Ihres Launchers manuell ersetzen oder einen Minecraft-Launcher verwenden, der die Angabe Ihres Java-Pfads unterstützt. Ich empfehle ATLauncher, Prism Launcher oder GDLauncher. Wenn Sie einen Java-Pfad angeben, navigieren Sie zum Ordner „bin“ im GraalVM-Download und verwenden Sie „javaw.exe“ oder „java.exe“.
Für Server müssen Sie den Befehl „java“ in der SH/BAT-Startdatei Ihres Servers durch den vollständigen Pfad zu graalvm java in Anführungszeichen ersetzen.
Alternativ können Sie es systemweit installieren, indem Sie der Anleitung von Oracle folgen: https://www.graalvm.org/22.2/docs/getting-started/#install-graalvm
Argumente für GraalVM EE 22+ Java 17 (oder 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
Sie müssen G1GC mit diesen Argumenten verwenden. GraalVM funktioniert derzeit nicht mit ZGC oder Shenandoah.
GraalVM EE 22.3.0 behebt alle bekannten Minecraft-Fehler
Wenn Sie eine ältere, Java 8-basierte Version von GraalVM ausführen, gibt es einige potenzielle Probleme:
VectorizeSIMD
macht Entitäten mit Shader-Mods wie Optifine, Iris oder Occulus unsichtbar ... aber nur unter bestimmten Bedingungen. Dies wird in GraalVM EE 22.3.0 behoben. Siehe: oracle/graal#4849
GraalVM CE und EE unterbrechen beide das Konstellations-Rendering in 1.16.5 Astral Sorcery. Dies hängt möglicherweise mit dem Shader-Fehler zusammen. Siehe: HellFirePvP/AstralSorcery#1963
Ich habe bisher keine serverseitigen Fehler beobachtet.
Wenn Sie auf andere Mod-Probleme stoßen, die auf GraalVM zurückzuführen sind, erstellen Sie bitte ein Github-Problem oder posten Sie es im Discord! Im Allgemeinen können Sie sie umgehen, indem Sie wichtige dgraal
Optimierungsflags deaktivieren oder indem Sie die richtige Funktion mit Dgraal.PrintCompilation=true
finden und sie mit -Dgraal.GraalCompileOnly=~...
umgehen, sobald Sie die falsch kompilierte Funktion gefunden haben.
SpecialK ist ein „universeller“ Windows-Mod ähnlich wie ReShade und bietet zwei große Leistungsvorteile:
Ein „intelligenter“ Frame-Limiter, der Ruckeln reduziert, Tearing verhindert, Strom spart und die CPU-TDP spart, um bei Bedarf zu steigern. Es funktioniert sogar in Verbindung mit VRR oder Nvidia Reflex.
Ein OpenGL-zu-DirectX11-Wrapper namens OpenGL-IK, der den Overhead des Minecraft-Fenstermodus eliminiert und andere Funktionen (wie Auto-HDR oder ein in der Größe veränderbares randloses Fenster) ermöglicht.
Laden Sie es hier herunter: https://wiki.special-k.info/en/SpecialK/Tools
Fügen Sie Ihren MC-Launcher hinzu und aktivieren Sie das Kontrollkästchen „Erweiterter Dienst“. Navigieren Sie dann zu Ihrem Java-Bin-Ordner, in dem sich Ihre javaw.exe befindet, und erstellen Sie eine leere Datei mit dem Namen SpecialK.OpenGL32
. Starten Sie Ihren Minecraft-Launcher mit dem SpecialK-Launcher, und der Launcher „injiziert“ dann SpecialK in Minecraft.
Für noch mehr Komfort können Sie über die SpecialK-Benutzeroberfläche eine Desktop-Verknüpfung zu Ihrem Minecraft-Launcher erstellen.
Stellen Sie sicher, dass Sie VSync und den Minecraft-Frame-Limiter im Spiel deaktivieren.
Ein Benutzer hat von reduzierten FPS beim Ausführen von SpecialK berichtet. Wenn dir das passiert, lass es mich bitte über Discord oder Github wissen!
Stellen Sie nach dem Starten von Minecraft mit dem Task-Manager Java so ein, dass es in Windows mit einer Prozesspriorität „Über dem Normalen“ ausgeführt wird:
Linux-Benutzer können sudo nice -n -10
am Anfang des Startbefehls hinzufügen. Beachten Sie jedoch, dass Nice-Level unter 0 (wobei „max“ -20 ist) die Ausführung von Minecraft als sudo
erfordern. Alternativ können Sie nach dem Start von Minecraft den Befehl renice
verwenden, um dieses Sicherheitsrisiko zu vermeiden.
Dies ist ein fantastisches Repo zum Finden von Performance-Mods: https://github.com/NordicGamerFE/usefulmods
Anstelle von Optifine würde ich kompatiblere Alternativen wie Sodium + Iris oder Rubidium + Oculus empfehlen.
Ich empfehle die Verwendung von Java 17 oder, falls dies nicht der Fall ist, Java 11, es sei denn, 8 ist unbedingt erforderlich. Wenn dies jedoch der Fall ist, funktionieren diese Flags mit OpenJDK8 zusammen mit Shenandoh GC (für Red Hat OpenJDK auf Clients) oder G1GC (für alles andere):
-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-Benutzer (auch bekannt als die meisten Java 8-Benutzer) können diese zusätzlichen Argumente hinzufügen:
-XX:+UseXMMForArrayCopy
Sie können Java 8-Versionen von GraalVM EE auch im Abschnitt 21.X auf der Oracle-Site herunterladen und diese Argumente verwenden:
-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
Stellen Sie sicher, dass Sie -Dgraal.VectorizeSIMD
auf false
setzen, wenn Sie Shader ausführen.
Betreiben Sie Ihre Minecraft-Server unter Clear Linux! Es ist bei weitem die am besten optimierte Linux-Distribution und verfügt über einige andere nette Funktionen (wie ein zustandsloses Konfigurationssystem). Es führt auch Clients auf AMD/Intel-GPUs recht gut aus: https://web.archive.org/web/20220916090057/https://docs.01.org/clearlinux/latest/tutorials/multi-boot/dual-boot- win.html
Auch für Server ist Oracle Linux eine gute Wahl, da es von Haus aus einigermaßen gut optimiert ist und Graalvm EE über den Paketmanager verfügbar ist. Für Kunden eignen sich Arch-basierte Distributionen wie CachyOS oder EndeavourOS hervorragend, da sie die meiste Hardware umfassend unterstützen.
Stellen Sie sicher, dass der Minecraft-Client Ihre separate GPU verwendet! Überprüfen Sie die Registerkarte F3 und zwingen Sie Minecraft, sie in den „ Windows-Grafikeinstellungen “ zu verwenden, nicht in der AMD/Nvidia-Systemsteuerung (da diese nicht mehr zu funktionieren scheinen).
Benutzer des Minecraft-Clients unter Linux sollten sich https://github.com/Admicos/minecraft-wayland ansehen
Schließen Sie alles im Hintergrund, einschließlich Discord, Spielestarter und Ihren Browser! Minecraft ist ressourcenintensiv und mag es nicht, wenn andere Apps CPU-Interrupts erzeugen oder Festplatten-I/O, RAM usw. verbrauchen.
Java 18/19 weist einige Mod-Inkompatibilitäten auf. Berichten zufolge funktionieren sie mit einigen Modpacks, aber ich bin mir nicht sicher, ob es irgendwelche Leistungsvorteile gibt.
Java-Optimierungen verbessern die Serverleistung und verhindern das Stottern des Clients, aber sie steigern die durchschnittlichen Client-FPS nicht wesentlich (wenn überhaupt). Dafür ist es weitaus wichtiger, korrekte/aktuelle Grafiktreiber und Leistungsmodifikationen auszuführen: https://github.com/NordicGamerFE/usefulmods
In dieser Anleitung wird davon ausgegangen, dass Sie beim Ausführen von Minecraft über etwas freien RAM verfügen. Wenn Ihr Setup RAM-beschränkt ist, versuchen Sie, insbesondere die folgenden Argumente zu entfernen: -XX:NmethodSweepActivity=1 -XX:ReservedCodeCacheSize=400M -XX:NonNMethodCodeHeapSize=12M -XX:ProfiledCodeHeapSize=194M -XX:NonProfiledCodeHeapSize=194M
und versuchen Sie es mit dem Server G1GC-Argumente.
IBMs OpenJ9 spart tatsächlich RAM, wie sein Ruf vermuten lässt, ist aber in meinen Tests beim Server-Chunkgen über 30 % langsamer. Wenn es irgendwelche Flags gibt, die es mit OpenJDK konkurrenzfähig machen, lassen Sie es mich bitte auf Discord oder hier wissen: #9
-XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions
entsperrt einfach weitere Flags zur Verwendung. Diese können mit den Flags -XX:+PrintFlagsFinal
und -XX:+JVMCIPrintProperties
aufgelistet werden, siehe Flag Dumps-XX:G1MixedGCCountTarget=3
: Dies ist die Anzahl der Oldgen-GC-Blöcke, auf die im „gemischten“ GC abgezielt werden soll. Diese gemischten Sammlungen sind viel langsamer und der Minecraft-Client generiert Oldgen nicht sehr schnell, daher können wir diesen Wert für kürzere GC-Pausen auf 3, 2 oder sogar 1 senken.-XX:+UseNUMA
ermöglicht ggf. Optimierungen für Multisocket-Systeme. Ich bin mir nicht sicher, ob dies auf MCM-CPUs wie Ryzen oder Epyc zutrifft, aber wenn nicht, wird es automatisch deaktiviert.-XX:-DontCompileHugeMethods
Ermöglicht das Kompilieren großer Methoden. Modded Minecraft hat einige davon, und wir kümmern uns nicht um eine höhere CPU-Auslastung des Hintergrund-Compilers.-XX:MaxNodeLimit=240000 -XX:NodeLimitFudgeFactor=8000
Ermöglicht die Optimierung größerer Methoden. Siehe: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8058148-XX:ReservedCodeCacheSize=400M -XX:NonNMethodCodeHeapSize=12M -XX:ProfiledCodeHeapSize=194M -XX:NonProfiledCodeHeapSize=194M
reserviert mehr Platz für kompilierten Code. Alle Abschnitte müssen sich zu ReservedCodeCacheSize
addieren. Ich habe beobachtet, dass modifiziertes Minecraft mit XX:+PrintCodeCache
die standardmäßige 250-Megabyte-Grenze erreicht, aber selbst wenn diese nicht gefüllt ist, macht die größere Größe die Entfernung von kompiliertem Code weniger aggressiv.-XX:NmethodSweepActivity=1
(Standard 10) hält „kalten“ Code für längere Zeit im Cache. Es besteht auch keine Gefahr, dass der Code-Cache „voll“ wird, da kalter Code aggressiver entfernt wird, je mehr er sich füllt.-XX:+UseStringDeduplication
-XX:+UseFastUnorderedTimeStamps
Vermeiden Sie Systemaufrufe zum Abrufen der Zeit. Die Auswirkungen sind je nach System unterschiedlich, die Genauigkeit der Zeitstempel bei der Protokollierung ist uns aber nicht wirklich wichtig.-XX:+UseCriticalJavaThreadPriority
Nichts sollte den Minecraft-Threads zuvorkommen. GC- und Compiler-Threads können warten.-XX:ThreadPriorityPolicy=1
Verwenden Sie einen größeren Bereich von Thread-Prioritäten. Erfordert Sudo unter Linux, um zu funktionieren. Einige JDKs (wie Graal) aktivieren dies standardmäßig, andere jedoch nicht.-XX:G1SATBBufferEnqueueingThresholdPercent=30 -XX:G1ConcMarkStepDurationMillis=5 -XX:G1ConcRSHotCardLimit=16 -XX:G1ConcRefinementServiceIntervalMillis=150
: Optimiert die gleichzeitigen Sammlungsthreads von G1GC, wird noch getestet: https://research.spec.org/icpe_proceedings/2014/p111.pdf-XX:G1RSetUpdatingPauseTimePercent=0
: Wir möchten, dass all diese Arbeit in den gleichzeitigen G1GC-Threads erledigt wird, nicht in den Pausen.-XX:G1HeapWastePercent=18
Machen Sie sich nicht die Mühe, von der alten Generation zu sammeln, bis dieser Prozentsatz übersteigt. Dadurch wird vermieden, dass langsamere „gemischte“ GCs der jungen Generation ausgelöst werden, was in Ordnung ist, da Minecraft (mit ausreichend Speicher) die alte Generation nicht so schnell füllt. Idee von: https://www.reddit.com/r/Minecraft/comments/k9zb7m/tuning_jvm_gc_for_singleplayer/-XX:GCTimeRatio=99
Als Ziel sollte 1 % der CPU-Zeit für die Speicherbereinigung aufgewendet werden. Der Standardwert ist 12, was viel zu niedrig erscheint. Der Standardwert für Java 8 war 99.-XX:AllocatePrefetchStyle=3
Erzeugt eine Prefetch-Anweisung pro Cache-Zeile. Ein aggressiveres Prefetching ist im Allgemeinen auf neueren CPUs mit großen Caches sinnvoll. Es scheint ZGC zu zerstören. Siehe: https://github.com/openjdk/jdk/blob/bd90c4cfa63ba2de26f7482ed5d1704f9be9629f/src/hotspot/share/opto/macro.cpp#L1806-Dgraal.LoopRotation=true
Eine nicht standardmäßige Optimierung, wird wahrscheinlich bald Standard sein.-Dgraal.TuneInlinerExploration=1
Verbringen Sie mehr Zeit damit, Inlining-Entscheidungen zu treffen. Für Minecraft möchten wir, dass der C2-Compiler so langsam und aggressiv wie möglich ist.-Dgraal
Argumente sind standardmäßig aktiviert und dienen entweder zur Plausibilitätsprüfung, zum Debuggen oder als Ausfallsicherung (wenn beispielsweise jemand unwissentlich JVCMI mit einem anderen Flag deaktiviert).-XX:MaxInlineLevel=15 -XX:MaxVectorSize=32
) werden einfach aus den Java 17-Standardeinstellungen kopiert. Andere (wie +AggressiveOpts
) sind nur in einigen älteren Java 8-Builds nicht standardmäßig vorhanden.-Dgraal.BaseTargetSpending=160
(Standard 120) in Graal und einige andere Flags in OpenJDK. CPUs mit größeren Caches könnten davon profitieren.-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
und graal.WriteableCodeCache=true
, die nicht stabil erscheinen, aber in GraalVM 22.3.0 möglicherweise stabiler sindG1HeapWastePercent
Werte.-XX:+PrintFlagsFinal
und -XX:+JVMCIPrintProperties
um Flagbeschreibungen/-Standards auszugeben.