فلگهای Aikar در 12 GB تغییر میکنند — پنج مورد از آنها، و یکی کاهش مییابد
کپی کردن یک مجموعه فلگ 4 GB روی یک سرور 16 GB باعث نادرست بودن پنج مقدار میشود. در اینجا دقیقاً مشخص شده کدام پنج مورد، به علاوه تعداد بازیکنی که سرور ماد شده از این خط عبور میکند و وانیلا عبور نمیکند.
فلگهای Aikar آرگومانهای استاندارد JVM جامعه برای یک سرور Paper هستند و معمولاً به صورت یک بلوک کپی میشوند. آنها یک بلوک نیستند: از بیست آرگومان، پنج مورد بسته به اینکه heap شما زیر یا بالای 12 GB باشد تغییر میکنند. کپی و جایگذاری یک مجموعه heap کوچک روی یک سرور heap بزرگ، رایجترین روش برای اجرای «فلگهای توصیهشده» بدون دریافت مزایای آنهاست.
پنج موردی که تغییر میکنند
| فلگ | زیر 12 GB | 12 GB و بیشتر |
|---|---|---|
-XX:G1NewSizePercent | 30 | 40 |
-XX:G1MaxNewSizePercent | 40 | 50 |
-XX:G1HeapRegionSize | 8M | 16M |
-XX:G1ReservePercent | 20 | 15 |
-XX:InitiatingHeapOccupancyPercent | 15 | 20 |
G1ReservePercent is the one that goes down. چهار مورد از این پنج مورد با افزایش اندازه heap بیشتر میشوند و آن یکی کاهش مییابد، به همین دلیل است که تغییر حدسی و مبهم «افزایش اعداد برای سرور بزرگ» به جای یک نتیجه صرفاً غیراستاندارد، مجموعهای کاملاً اشتباه ایجاد میکند. این فلگ کسری از heap را در برابر خطای تخلیه رزرو میکند و یک heap بزرگتر به میزان کمتری کسر نیاز دارد تا همان فضای خالی مطلق را نگه دارد.
سیزده مورد باقیمانده -XX: arguments are identical at every heap size — -XX:+UseG1GC, -XX:MaxGCPauseMillis=200, -XX:+AlwaysPreTouch, -XX:SurvivorRatio=32, -XX:MaxTenuringThreshold=1 and the rest do not move. Only -Xms and -Xmx track the heap size itself.
جایی که خط 12 GB واقعاً قرار میگیرد
سازنده در این صفحه، اندازه heap را بر اساس تعداد بازیکنان شما تعیین میکند:
GB = clamp( ceil( (modded ? 2.5 : 1) × (2 + players / 12) ), 2, 32 )سرورهای ماد شده بر اساس ضریبی از 2.5× وانیلا محاسبه میشوند، و این ضریب تعیین میکند چه کسانی به شاخه heap بزرگ نیاز پیدا میکنند:
| بازیکنان | وانیلا | ماد شده |
|---|---|---|
| 10 | 3 GB | 8 GB |
| 20 | 4 GB | 10 GB |
| 29 | 5 GB | 12 GB ← ماد شده از اینجا عبور میکند |
| 50 | 7 GB | 16 GB |
| 100 | 11 GB | 26 GB |
| 109 | 12 GB ← وانیلا از اینجا عبور میکند | 28 GB |
یک سرور ماد شده به فلگهای heap بزرگ میرسد در 29 بازیکن. در حالی که سرور وانیلا تا این تعداد نمیرسد 109. بنابراین برای اکثر افرادی که Paper وانیلا اجرا میکنند، مجموعه heap کوچک برای همیشه درست است — و برای اکثر افرادی که سرور ماد شده اجرا میکنند، خیلی زودتر از آنچه انتظار دارند نامناسب میشود.
دو محدودیت در این فرمول که دانستن آنها مفید است
هرگز بیش از 32 GB را پیشنهاد نمیکند. وانیلا در 349 بازیکن به سقف میرسد و همانجا میماند. این یک خطای گرد کردن نیست — بعد از حدود 32 GB، JVM اشارهگرهای فشرده اشیاء را از دست میدهد و هر ارجاع در heap بزرگتر میشود، بنابراین رم بیشتر میتواند به معنای کمتر heap قابل استفاده باشد. ارتقا فراتر از این نقطه، کار یک سرور دوم است، نه یک سرور بزرگتر.
هرگز کمتر از 2 GB را پیشنهاد نمیکند، حتی برای یک بازیکن، زیرا حداقل مقدار به نرمافزار سرور مربوط است تا جمعیت بازیکنان.
و هر چه که فرمول بگوید: تمام حافظه سیستم را به JVM اختصاص ندهید. -Xms and -Xmx are set to the same value here on purpose — a fixed heap avoids the JVM resizing under load — which means the number you pick is claimed immediately and permanently. Leave the operating system 1–2 GB it does not have to fight you for.