Minecraft Performance Flags Benchmarks
1.0.0
นี่คือคำแนะนำในการปรับแต่ง Java สำหรับ Minecraft ทุกแฟล็กและการปรับแต่งจะมีการวัดประสิทธิภาพแยกกันเพื่อทดสอบการถดถอย และตรวจสอบกับค่าเริ่มต้นของ Java เพื่อหลีกเลี่ยงความซ้ำซ้อน
แม้ว่าการปรับแต่งเหล่านี้จะลดการกระตุกของเซิร์ฟเวอร์และไคลเอนต์อย่างเห็นได้ชัด แต่คาดว่าจะได้รับ TPS เพียงเล็กน้อย + FPS ขั้นต่ำที่ดีที่สุด และเพิ่มการใช้งาน RAM + CPU บ้าง และไม่สามารถทดแทนการล้างสิ่งที่กระตุกด้วยม็อดอย่าง Spark หรือ Observable
ไม่ลงรอยกันสำหรับคำถามและอื่นๆ: https://discord.gg/zeFSR9PnUw
ธงทั้งหมดได้รับการทดสอบด้วยสคริปต์ Benchmark.py ดู Benchmarks.md ที่กำลังดำเนินการอยู่
สำหรับ Minecraft 1.16.5 ขึ้นไป ให้ใช้ Java 17 ตัวเรียกใช้งานบางตัว เช่น Curseforge และ Prism Launcher ขอให้คุณใช้ Java 8 บน 1.16.X แต่ Minecraft 1.16.5+, mod 1.18+ ทั้งหมด และ mod 1.16.5 ส่วนใหญ่ เข้ากันได้ ด้วยจาวา 17
บางครั้ง Java 11 จะทำงานโดยที่ Java 17 ไม่รองรับ
โดยทั่วไปแล้ว 1.12.2 และต่ำกว่าต้องใช้ Java 8
รันไทม์ Java จาก Azul, Microsoft, Adoptium, Amazon และอื่นๆ โดยพื้นฐานแล้วจะเหมือนกัน ข้อยกเว้นที่น่าสังเกตบางประการ:
Oracle GraalVM Enterprise Edition มีคอมไพลเลอร์ Java ที่เข้มข้นมากขึ้น นี่คือสิ่งที่ฉันใช้งาน Minecraft เป็นการส่วนตัว ดูส่วน GraalVM ด้านล่าง
Clear Linux OpenJDK ของ Intel ใช้โค้ดเดียวกันกับ OpenJDK อื่นๆ (ทำให้เข้ากันได้สูง) แต่กระบวนการสร้างและการขึ้นต่อกันนั้นได้รับการปรับให้เหมาะสมสำหรับ CPU รุ่นใหม่ หยิบได้จาก repos ของ Clear Linux ผ่าน swupd จาก Distrobox หรือจาก Docker โปรดทราบว่าคุณต้องย้อนกลับไปยังรีลีส Java 17 และ Java 18 จะคืนค่าการปรับปรุงประสิทธิภาพบางส่วน
Prime OpenJDK ของ Azul นั้นเร็ว มาก เนื่องจากเชื่อมต่อกับ llvm แต่ปัจจุบันเข้ากันไม่ได้กับ mod ส่วนใหญ่และเป็น linux เท่านั้น รับได้จากที่นี่: https://docs.azul.com/prime/prime-quick-start-tar
Red Hat Java 8 มีตัวรวบรวมขยะ Shenandoah มันอยู่เบื้องหลังการสมัครรับอีเมลฟรี: https://developers.redhat.com/products/openjdk/download
OpenJ9 ของ IBM นั้น... ช้ากว่า มาก ใน Minecraft และใช้แฟล็กที่แตกต่างอย่างสิ้นเชิงกับ Java build อื่น ๆ แต่ใช้หน่วยความจำน้อยกว่ารันไทม์ที่ใช้ OpenJDK ดูคำถามที่พบบ่อย โฟลเดอร์เกณฑ์มาตรฐาน และส่วนสำคัญนี้สำหรับแฟล็กการใช้หน่วยความจำเหลือน้อย
หากคุณไม่รู้ว่าจะเลือกอะไร ฉันขอแนะนำ 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
ข้อยกเว้นประการหนึ่ง: หากคุณใช้ระบบหน่วยความจำเหลือน้อย และ Minecraft ใช้ RAM เกือบทั้งหมด ให้ตั้งค่าหน่วยความจำขั้นต่ำให้ต่ำกว่าหน่วยความจำสูงสุดเพื่ออนุรักษ์ให้ได้มากที่สุด
ขนาดถูกกำหนดเป็นเมกะไบต์ ( -Xms4096M ) หรือกิกะไบต์ ( -Xmx8G )
การจัดสรรหน่วยความจำมากเกินไปอาจทำให้ gc พังหรือทำให้ Minecraft ช้าลงได้ แม้ว่าคุณจะมีเหลือเฟือก็ตาม การจัดสรรน้อยเกินไปอาจทำให้เกมช้าลงหรือพังได้ จับตาดูตัวจัดการงานของ Windows (หรือมอนิเตอร์ระบบ DE ของคุณ) อย่างใกล้ชิดในขณะที่ Minecraft กำลังทำงานอยู่ และจัดสรรได้มากเท่าที่ต้องการ (ซึ่งโดยปกติจะน้อยกว่า 8G) sparkc gcmonitor จะบอกคุณว่าการจัดสรรของคุณสูงเกินไป (การหยุดชั่วคราวจะยาวเกินไป) หรือต่ำเกินไป (GC บ่อยครั้งพร้อมคำเตือนหน่วยความจำเหลือน้อยในการแจ้งเตือน)
ต้องเพิ่มแฟล็กการรวบรวมขยะลงในเซิร์ฟเวอร์และไคลเอนต์ Minecraft เนื่องจากค่าเริ่มต้น "หยุดชั่วคราว" เพื่อหยุดและรวบรวมรายการขยะเนื่องจากการติดอ่างบนไคลเอนต์และความล่าช้าบนเซิร์ฟเวอร์ ใช้คำสั่ง /sparkc gcmonitor ใน Spark mod เพื่อสังเกตการหยุดชั่วคราวในเกม การหยุดชั่วคราวของคนรุ่นเก่า นั้น ไม่ดี และคอลเลกชั่น G1GC ของคนรุ่นใหม่ควรจะไม่บ่อยนัก แต่สั้นพอที่จะมองไม่เห็น
เลือกธงหนึ่งชุด ฉันแนะนำ Shenandoah บนไคลเอนต์ , ZGC บนเซิร์ฟเวอร์ Java 17 ที่ทรงพลัง และ G1GC บน Graal หรือบนเซิร์ฟเวอร์/ไคลเอนต์ที่มี RAM น้อยกว่าและคอร์น้อยกว่า:
ZGC เหมาะอย่างยิ่งสำหรับเซิร์ฟเวอร์ที่มีหน่วยความจำสูง/จำนวนคอร์สูง ไม่มีปริมาณงานของเซิร์ฟเวอร์ที่ฉันสามารถวัดได้ และไม่กระตุกอย่างแน่นอน อย่างไรก็ตาม มันต้องการ RAM และคอร์มากกว่าตัวรวบรวมขยะอื่นๆ
น่าเสียดายที่มีไคลเอนต์ FPS จำนวนมากโจมตีบนแล็ปท็อป (8-core/16 thread) ของฉัน ดูการวัดประสิทธิภาพ "ZGC" ในโฟลเดอร์การวัดประสิทธิภาพ ไม่สามารถใช้งานได้ใน Java 8 และมีประสิทธิภาพน้อยกว่าใน Java 11 มากกว่าใน Java 17 มาก
-XX:+UseZGC -XX:AllocatePrefetchStyle=1 -XX:-ZProactive เปิดใช้งาน แต่จัดสรร RAM มากกว่าและ ConcGCThreads มากกว่าที่คุณทำตามปกติสำหรับ GC อื่น ๆ โปรดทราบว่า ZGC ไม่ชอบ AllocatePrefetchStyle=3 ดังนั้นการตั้งค่าเป็น 1 จะแทนที่รายการก่อนหน้า คุณ
Shenandoah ทำงานได้ดีกับไคลเอนต์ แต่ทำลายปริมาณงานของเซิร์ฟเวอร์ในการทดสอบของฉัน เปิดใช้งานด้วย -XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu -XX:ShenandoahGuaranteedGCInterval=1000000 -XX:AllocatePrefetchStyle=1
ดูตัวเลือกการปรับแต่งเพิ่มเติมได้ที่นี่ ตัวเลือก "herustic" และ "mode" ไม่ได้เปลี่ยนแปลงมากนักสำหรับฉัน (ยกเว้น "compact" ซึ่งคุณไม่ควรใช้) เช่นเดียวกับ ZGC Shenandoah ไม่ชอบ AllocatePrefetchStyle=3
โปรดทราบว่า Shenandoah ไม่ได้อยู่ใน Java 8 และไม่ได้อยู่ใน Oracle Java builds ใด ๆ ! หากคุณเป็นผู้ใช้ Java 8 คุณต้องใช้ Red Hat OpenJDK เพื่อใช้ Shenandoah: https://developers.redhat.com/products/openjdk/download
G1GC เป็นตัวรวบรวมขยะเริ่มต้น และเป็นตัวรวบรวมขยะเพียงตัวเดียวที่พร้อมใช้งานสำหรับผู้ใช้ GraalVM อาร์กิวเมนต์ G1GC เซิร์ฟเวอร์ Minecraft อันโด่งดังของ Aikar ทำงานได้ดีกับไคลเอนต์ โดยมีข้อแม้สองประการ: พวกเขายึดพารามิเตอร์ MaxGCPauseMillis ได้อย่างมีประสิทธิภาพโดยการตั้งค่า G1NewSizePercent ให้สูงมาก ทำให้เกิดการพูดติดอ่างยาวในไคลเอนต์บางราย และพวกมันรวบรวมขยะรุ่นเก่าที่ก้าวร้าวเกินไป (เนื่องจากไคลเอนต์สร้างน้อยกว่า มาก เซิร์ฟเวอร์ที่มีประชากร)
สิ่งเหล่านี้คล้ายกับแฟล็ก 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) คุณต้องการเพิ่มฝาครอบเธรดนี้ให้เกินค่าเริ่มต้น ฉันแนะนำ "2" บน CPU ที่มี 4 เธรด และ [number of real cores - 2] บน CPU อื่น ๆ ส่วนใหญ่ แต่คุณอาจต้องเล่นกับพารามิเตอร์นี้ ถ้ามันน้อยเกินไป การรวบรวมขยะไม่สามารถตาม Minecraft ได้ และเกมจะกระตุกและ/หรือเริ่มกิน RAM มหาศาลและพัง หากสูงเกินไปอาจทำให้เกมช้าลง โดยเฉพาะหากคุณใช้ Java 8
ไม่จำเป็นต้องมีแฟล็ก "เธรด" อื่น ๆ เช่น ParallelGCThreads หรือ JVMCIThreads เนื่องจากมีการเปิดใช้งานตามค่าเริ่มต้นด้วยการตั้งค่าอัตโนมัติที่ดีใน Java 8+
หมายเหตุ: หน้าใหญ่ต้องใช้สิทธิ์ของผู้ดูแลระบบบน Windows นี่เป็นความเสี่ยงด้านความปลอดภัย และคุณควรข้ามส่วนนี้ไปหากคุณไม่สบายใจ
การเปิดใช้งานหน้าขนาดใหญ่จะช่วยปรับปรุงประสิทธิภาพของเซิร์ฟเวอร์และไคลเอนต์ Minecraft ต่อไปนี้เป็นบทช่วยสอนที่ยอดเยี่ยมสำหรับการเปิดใช้งาน:
บน Windows คุณ ต้อง เรียกใช้ java และตัวเรียกใช้งานของคุณในฐานะผู้ดูแลระบบ นั่นหมายถึงการตรวจสอบช่องทำเครื่องหมายความเข้ากันได้ "run as administrator" สำหรับ javaw.exe , java.exe และ your launcher.exe ไม่เช่นนั้น Large Pages จะล้มเหลวโดยไม่แจ้งให้ทราบ เพิ่ม -XX:+UseLargePages -XX:LargePageSizeInBytes=2m ให้กับอาร์กิวเมนต์ของคุณ
บน linux โดยทั่วไปคุณต้องการใช้ -XX:+UseTransparentHugePages หากต้องการจัดสรรหน่วยความจำด้วยตนเองแทน (เพื่อการเพิ่มประสิทธิภาพที่มากขึ้น) Red Hat มีบทช่วยสอนที่ดีสำหรับ distros linux ที่คล้ายกับ RHEL เช่น Fedora, CentOS หรือ Oracle Linux: https://www.redhat.com/en/blog/optimizing -rhel-8-run-java-implementation-minecraft-เซิร์ฟเวอร์
ตรวจสอบและดูว่าเพจขนาดใหญ่ทำงานกับอาร์กิวเมนต์ -Xlog:gc+init java ใน Java 17 หรือไม่
ในเวอร์ชัน/แพลตฟอร์ม Java ใดๆ หากเพจขนาดใหญ่ใช้งานไม่ได้ คุณจะได้รับคำเตือนในบันทึกที่คล้ายกับสิ่งนี้:
คำเตือน Java HotSpot(TM) 64-Bit Server VM: JVM ไม่สามารถใช้หน่วยความจำเพจขนาดใหญ่ได้ เนื่องจากไม่มีสิทธิ์เพียงพอที่จะล็อคเพจในหน่วยความจำ
GraalVM เป็น Java VM ใหม่จาก Oracle ที่สามารถปรับปรุงประสิทธิภาพของ Minecraft (modded และ vanilla) แม้ว่า 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
ลินุกซ์ 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
ลินุกซ์ 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 และบน repos ของ Oracle Linux ด้วย)
เวอร์ชันใหม่สำหรับ ARM Mac ต้องลงทะเบียนฟรีบนหน้าดาวน์โหลดหลักของ Oracle: https://www.oracle.com/downloads/graalvm-downloads.html
รุ่นเหล่านี้ไม่ใช่ตัวติดตั้ง Java คุณต้องแทนที่ Java เวอร์ชันของ Launcher ด้วยตนเอง หรือใช้ Minecraft Launcher ที่รองรับการระบุเส้นทาง Java ของคุณ ฉันแนะนำ ATLauncher, Prism Launcher หรือ GDLauncher เมื่อระบุเส้นทาง Java ให้นำทางไปยังโฟลเดอร์ "bin" ในการดาวน์โหลด GraalVM และใช้ "javaw.exe" หรือ "java.exe"
สำหรับเซิร์ฟเวอร์ คุณต้องแทนที่คำสั่ง "java" ในเซิร์ฟเวอร์ของคุณที่เริ่มไฟล์ sh/bat ด้วยพาธแบบเต็มไปยัง 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 ที่รู้จักทั้งหมด
หากคุณใช้งาน GraalVM เวอร์ชันเก่าที่ใช้ Java 8 อาจมีปัญหาที่อาจเกิดขึ้นบางประการ:
VectorizeSIMD เปลี่ยนเอนทิตีที่มองไม่เห็นด้วยม็อดเชเดอร์ เช่น Optifine, Iris หรือ Occulus... แต่ภายใต้เงื่อนไขบางประการเท่านั้น สิ่งนี้จะได้รับการแก้ไขใน GraalVM EE 22.3.0 ดู: oracle/graal#4849
GraalVM CE และ EE ต่างทำลายการเรนเดอร์กลุ่มดาวใน 1.16.5 Astral Sorcery สิ่งนี้อาจเกี่ยวข้องกับข้อผิดพลาดของเชเดอร์ ดู: HellFirePvP/AstralSorcery#1963
ฉันยังไม่ได้สังเกตเห็นข้อบกพร่องฝั่งเซิร์ฟเวอร์เลย
หากคุณพบปัญหา Mod อื่นๆ ที่คุณสามารถติดตามกลับไปยัง GraalVM ได้ โปรดสร้างปัญหา Github หรือโพสต์ใน Discord! โดยทั่วไป คุณสามารถแก้ไขปัญหาเหล่านี้ได้ด้วยการปิดใช้งานแฟล็กการเพิ่มประสิทธิภาพ dgraal หลัก หรือโดยการค้นหาฟังก์ชันที่ถูกต้องด้วย Dgraal.PrintCompilation=true และแก้ไขด้วย -Dgraal.GraalCompileOnly=~... เมื่อคุณพบฟังก์ชันที่คอมไพล์ผิดแล้ว
ม็อด Windows "สากล" คล้ายกับ ReShade โดย SpecialK มีประโยชน์ด้านประสิทธิภาพหลัก 2 ประการ:
ตัวจำกัดเฟรม "อัจฉริยะ" ที่ลดการกระตุก ลดการฉีกขาด ประหยัดพลังงาน และประหยัด TDP ของ CPU เพื่อเพิ่มพลังเมื่อจำเป็น มันยังทำงานร่วมกับ VRR หรือ Nvidia Reflex ได้อีกด้วย
Wrapper OpenGL-to-DirectX11 ที่เรียกว่า OpenGL-IK ซึ่งช่วยลดโอเวอร์เฮดของโหมดหน้าต่างของ Minecraft และเปิดใช้งานคุณสมบัติอื่นๆ (เช่น auto-HDR หรือหน้าต่างไร้ขอบที่ปรับขนาดได้)
ดาวน์โหลดได้ที่นี่: https://wiki.special-k.info/en/SpecialK/Tools
เพิ่ม MC Launcher ของคุณ และทำเครื่องหมายที่ช่อง "บริการระดับสูง" จากนั้นไปที่โฟลเดอร์ java bin ซึ่งมี javaw.exe อยู่ และสร้างไฟล์เปล่าชื่อ SpecialK.OpenGL32 เปิดตัว Launcher Minecraft ของคุณด้วย SpecialK Launcher จากนั้น Launcher จะ "แทรก" SpecialK ลงใน Minecraft 
คุณสามารถสร้างทางลัดบนเดสก์ท็อปไปยังตัวเรียกใช้งาน Minecraft ของคุณผ่าน SpecialK UI เพื่อความสะดวกยิ่งขึ้น
อย่าลืมปิด VSync และตัวจำกัดเฟรม Minecraft ในเกม
ผู้ใช้รายหนึ่งรายงานว่า FPS ลดลงเมื่อใช้งาน SpecialK หากสิ่งนี้เกิดขึ้นกับคุณ โปรดแจ้งให้เราทราบผ่าน Discord หรือ Github!
หลังจากเปิดตัว Minecraft ให้ตั้งค่า Java ให้ทำงานที่ลำดับความสำคัญของกระบวนการ "สูงกว่าปกติ" ใน Windows ด้วยตัวจัดการงาน:
ผู้ใช้ Linux สามารถเพิ่ม sudo nice -n -10 ที่จุดเริ่มต้นของคำสั่ง launch แต่โปรดทราบว่าระดับที่ดีที่ต่ำกว่า 0 (โดยที่ "สูงสุด" คือ -20) ต้องใช้ Minecraft เป็น sudo หรือใช้คำสั่ง renice หลังจากเปิดตัว Minecraft เพื่อหลีกเลี่ยงความเสี่ยงด้านความปลอดภัย
นี่เป็น repo ที่ยอดเยี่ยม สำหรับการค้นหา mods ประสิทธิภาพ: https://github.com/NordicGamerFE/usefulmods
แทนที่จะใช้ Optifine ฉันอยากจะแนะนำทางเลือกอื่นที่เข้ากันได้มากกว่า เช่น Sodium + Iris หรือ Rubidium + Oculus
ฉันแนะนำให้ใช้ Java 17 หรือไม่เช่นนั้น Java 11 เว้นแต่ 8 จำเป็นจริงๆ แต่ถ้าเป็นเช่นนั้น แฟล็กเหล่านี้จะใช้งานได้กับ OpenJDK8 พร้อมด้วย Shenandoh GC (สำหรับ Red Hat OpenJDK บนไคลเอนต์) หรือ G1GC (สำหรับอย่างอื่นทั้งหมด):
-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
คุณยังสามารถรับ GraalVM EE เวอร์ชัน Java 8 ได้จากส่วน 21.X บนไซต์ Oracle และใช้อาร์กิวเมนต์เหล่านี้:
-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 หากคุณเรียกใช้เชเดอร์
ใช้งานเซิร์ฟเวอร์ Minecraft ของคุณบน Clear Linux! มันเป็นการกระจาย 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 พร้อมใช้งานผ่านตัวจัดการแพ็คเกจ สำหรับไคลเอนต์ การแจกแจงแบบอิง Arch เช่น CachyOS หรือ EndeavorOS นั้นยอดเยี่ยมมาก เนื่องจากมีการสนับสนุนฮาร์ดแวร์ส่วนใหญ่อย่างกว้างขวาง
ตรวจสอบให้แน่ใจว่าไคลเอนต์ Minecraft ใช้ GPU แยกของคุณ! ตรวจสอบแท็บ F3 และบังคับให้ Minecraft ใช้ใน " การตั้งค่ากราฟิกของ Windows " ไม่ใช่ ในแผงควบคุม AMD/Nvidia (เนื่องจากดูเหมือนว่าจะไม่ทำงานอีกต่อไป)
ผู้ใช้ Linux ไคลเอนต์ Minecraft ควรตรวจสอบ https://github.com/Admicos/minecraft-wayland
ปิดทุกสิ่งในเบื้องหลัง รวมถึง Discord ตัวเปิดเกม และเบราว์เซอร์ของคุณ! Minecraft เป็นทรัพยากรที่เข้มข้น และไม่ชอบแอปอื่นๆ ที่สร้างการขัดจังหวะของ CPU หรือกินดิสก์ I/O, RAM และอื่นๆ
Java 18/19 มีความเข้ากันไม่ได้ของ mod บางอย่าง มีรายงานว่าใช้งานได้กับ modpacks บางตัว แต่ฉันไม่แน่ใจว่ามีประโยชน์ด้านประสิทธิภาพหรือไม่
การปรับแต่ง Java ปรับปรุงประสิทธิภาพของเซิร์ฟเวอร์และการกระตุกของไคลเอนต์ แต่ไม่ได้เพิ่ม FPS ของไคลเอนต์โดยเฉลี่ยมากนัก (หากเลย) ด้วยเหตุนี้ การใช้ไดรเวอร์กราฟิกที่ถูกต้อง/ทันสมัยและม็อดประสิทธิภาพจึงมีความสำคัญมากกว่า: https://github.com/NordicGamerFE/usefulmods
คู่มือนี้ถือว่าคุณมี RAM สำรองเล็กน้อยเมื่อใช้งาน Minecraft หากการตั้งค่าของคุณมีข้อ จำกัด RAM ให้ลองลบอาร์กิวเมนต์ต่อไปนี้โดยเฉพาะ: -XX:NmethodSweepActivity=1 -XX:ReservedCodeCacheSize=400M -XX:NonNMethodCodeHeapSize=12M -XX:ProfiledCodeHeapSize=194M -XX:NonProfiledCodeHeapSize=194M และลองใช้เซิร์ฟเวอร์ อาร์กิวเมนต์ G1GC
OpenJ9 ของ IBM ช่วยประหยัด RAM ได้จริง ๆ ดังที่ชื่อเสียงของมันแนะนำ แต่ช้ากว่า 30% ที่เซิร์ฟเวอร์ chunkgen ในการทดสอบของฉัน หากมีธงใดที่ทำให้สามารถแข่งขันกับ OpenJDK ได้ โปรดแจ้งให้เราทราบใน Discord หรือที่นี่: #9
-XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions เพียงปลดล็อคแฟล็กเพิ่มเติมที่จะใช้ สิ่งเหล่านี้สามารถแสดงรายการได้ด้วยแฟล็ก -XX:+PrintFlagsFinal และ -XX:+JVMCIPrintProperties โปรดดูแฟล็กดัมพ์-XX:G1MixedGCCountTarget=3 : นี่คือจำนวนบล็อก gc oldgen ที่จะกำหนดเป้าหมายใน gc "แบบผสม" คอลเลกชันแบบผสมเหล่านี้จะช้ากว่ามาก และไคลเอนต์ Minecraft ไม่ได้สร้างรุ่นเก่าเร็วนัก ดังนั้นเราจึงสามารถลดค่านี้เป็น 3, 2 หรือ 1 แม้แต่ 1 เพื่อให้ GC หยุดชั่วคราวสั้นลง-XX:+UseNUMA เปิดใช้งานการปรับให้เหมาะสมสำหรับระบบหลายซ็อกเก็ต ถ้ามี ไม่แน่ใจว่าสิ่งนี้ใช้ได้กับ MCM CPU เช่น Ryzen หรือ Epyc หรือไม่ แต่จะปิดใช้งานโดยอัตโนมัติหากไม่เกี่ยวข้อง-XX:-DontCompileHugeMethods อนุญาตให้ คอมไพล์เมธอดขนาดใหญ่ได้ Modded 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 ฉันสังเกตเห็นว่า Minecraft ที่ดัดแปลงแล้วทำงานเกินขีดจำกัดเริ่มต้นที่ 250 เมกะไบต์ด้วย XX:+PrintCodeCache แต่ถึงแม้ว่ามันจะไม่เต็ม แต่ขนาดที่ใหญ่ขึ้นก็ทำให้การขับไล่โค้ดที่คอมไพล์มีความก้าวร้าวน้อยลง-XX:NmethodSweepActivity=1 (ค่าเริ่มต้น 10) เก็บโค้ด "cold" ไว้ในแคชเป็นเวลานานขึ้น ไม่มีความเสี่ยงในการ "เติม" โค้ดแคชเช่นกัน เนื่องจากโค้ดแบบเย็นจะถูกลบออกอย่างจริงจังมากขึ้นเมื่อเต็ม-XX:+UseStringDeduplication-XX:+UseFastUnorderedTimeStamps หลีกเลี่ยงการเรียกระบบเพื่อรับเวลา ผลกระทบของสิ่งนี้จะแตกต่างกันไปในแต่ละระบบ แต่เราไม่ได้กังวลกับความถูกต้องของการประทับเวลาการบันทึก-XX:+UseCriticalJavaThreadPriority ไม่มีสิ่งใด ควรยึดถือเธรด Minecraft เธรด GC และคอมไพเลอร์สามารถรอได้-XX:ThreadPriorityPolicy=1 ใช้ลำดับความสำคัญของเธรดที่กว้างขึ้น ต้องใช้ sudo บน linux จึงจะทำงานได้ 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 (ที่มีหน่วยความจำเพียงพอ) ไม่ได้เติมเต็ม Gen เก่าอย่างรวดเร็วขนาดนั้น ไอเดียจาก: https://www.reddit.com/r/Minecraft/comments/k9zb7m/tuning_jvm_gc_for_singleplayer/-XX:GCTimeRatio=99 ตามเป้าหมาย 1% ของเวลา CPU ควรถูกใช้ไปกับการรวบรวมขยะ ค่าเริ่มต้นคือ 12 ซึ่งดูเหมือนต่ำเกินไป ค่าเริ่มต้นสำหรับ Java 8 คือ 99-XX:AllocatePrefetchStyle=3 สร้างคำสั่งการดึงข้อมูลล่วงหน้าหนึ่งคำสั่งต่อบรรทัดแคช โดยทั่วไปการดึงข้อมูลล่วงหน้าเชิงรุกมากขึ้นจะมีประโยชน์กับ 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) ใน Graal และแฟล็กอื่น ๆ ใน 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.0G1HeapWastePercent สูงสุด-XX:+PrintFlagsFinal และ -XX:+JVMCIPrintProperties เพื่อดัมพ์คำอธิบาย/ค่าเริ่มต้นของแฟล็ก
