ما مقدار ذاكرة RAM التي يحتاجها خادم Minecraft؟

أنت تشغّل خادمًا لأصدقائك على جهاز يحتوي على 8 GB من RAM. من السهل كتابة -Xmx8G في ملف التشغيل: لديك 8 من RAM، إذًا لندع Java تستخدم 8 أيضًا. ثم تتذكر Windows والمتصفح، وإذا كنت ستلعب على الجهاز نفسه، تتذكر Minecraft client كذلك. وقبل أن يسجّل أي لاعب دخوله أصلًا، لا يعود النظام يجد ذاكرة كافية لتوزيعها. أحيانًا لا تكون المشكلة في الخادم، بل في ذلك السطر الواحد.

انظر إلى نتيجتي «Java heap الموصى به» و«إجمالي RAM المطلوبة» في الحاسبة كلٌّ على حدة. تستخدم الأولى مع -Xmx. أما الثانية فتخبرك بمقدار RAM الذي يجب أن يتوفر في الكمبيوتر أو الخادم الذي تستأجره. لا أقول إن «8 GB تكفي» من دون الفصل بين هذين الرقمين. عدد اللاعبين وحده لا يكفي للوصول إلى هذا الاستنتاج.

عشرة لاعبين لا يعني دائمًا الحمل نفسه

التجمع عند spawn مقابل الانتشار عبر الخريطة

أدخل عدد الأشخاص الذين سيلعبون في الوقت نفسه، لا عدد الحسابات المسجلة. عندما يبني 10 لاعبين قاعدة حول spawn، فهم يتعاملون غالبًا مع نفس الـchunks. لكن عندما ينطلقون في اتجاهات مختلفة باستخدام Elytra يتغير الأمر. يبدأ الخادم من جهة بتحميل مناطق جديدة، ومن جهة أخرى بتوليد أراضٍ لم يرها أحد بعد. لذلك فإن 10 لاعبين في بداية المساء قد لا يفرضون حمل RAM نفسه الذي يفرضه 10 لاعبين في نهايته.

عند إجراء الحساب أنظر إلى طريقة لعب المجموعة. إذا كان الجميع يبقون في منطقة مشتركة، فاختيار «غالبًا في المنطقة نفسها» مناسب. أما إذا كان كل لاعب يتجه إلى قاعدته الخاصة في عالم Survival، فخيار «في مناطق مختلفة / لا أعرف» أقرب للواقع. وإذا كان الاستكشاف كثيفًا، فحدده أيضًا. تضيف الحاسبة 25 بالمئة إلى حمل الـchunks. رفع عدد اللاعبين تقديريًا إلى عشرين فقط من باب الاحتياط يخفي السبب الحقيقي وراء الفرق.

تحقق أيضًا من مسافتي الرؤية والمحاكاة في ملف server.properties. مسافة الرؤية هي المنطقة التي ترسلها إلى اللاعب. أما مسافة المحاكاة فهي النطاق الذي تعمل داخله الـmobs وأحداث اللعبة. عند فتح النموذج لأول مرة تكون القيمتان 8 و6 chunks. في حساب الإصدارات الحديثة تكون المسافة الأكبر من الاثنتين هي المؤثرة. فإذا كانت مسافة الرؤية 8 ورفعت المحاكاة من 6 إلى 7، فقد تبقى نتيجة RAM كما هي. لكن لا يمكن قول الشيء نفسه عن حمل الـtick. وفي ملف تعريف «1.17 والإصدارات الأقدم» لا تأخذ الأداة مسافة المحاكاة في الحسبان.

لا تعتمد على عدد الإضافات وحده أيضًا

بالنسبة إلى Paper وPurpur وSpigot، تدخل عدد الإضافات ومتوسط حملها. أما في Fabric وForge وNeoForge فيدخل عدد الـmods في الحساب. وفي Vanilla لا تستخدم الحاسبة أيًا من هذه المدخلات القديمة. لا تعتبر خيارات «خفيف / متوسط / ثقيل» قياسًا مباشرًا لاستهلاك RAM لكل إضافة على حدة. فعشر إضافات صغيرة للصلاحيات ليست مساوية لإضافة تقوم بعمل render للخريطة في الخلفية.

عند تثبيت modpack أبحث أولًا عن توصية الـheap التي يقدمها للـserver. إذا وجدتها، فأدخلها في قسم «استخدام توصية RAM الخاصة بالـmodpack». لن تنخفض الأداة عن هذا الرقم. ولا تنقل إلى هنا التوصية المكتوبة للـclient، فنحن نتحدث عن عمليتي تشغيل منفصلتين للعبة. إذا لم تستطع تقدير حمل الحزمة، فقارن نتيجتي «متوسط» و«ثقيل» جنبًا إلى جنب. الفرق بينهما أكثر فائدة من مجرد عدد الـmods عند مناقشة ما إذا كنت بحاجة إلى خطة استضافة أكبر.

أي رقم تكتب في أي مكان داخل الحاسبة؟

إذا كنت تنشئ خادمًا جديدًا، اختر مسار «حساب متطلبات RAM». وإذا كنت ستختبر جهازًا موجودًا لديك، فاختر «فحص جهازي». حساب الخادم نفسه متطابق في المسارين. وأكثر شيء يسهل نسيانه هنا هو القيم الافتراضية للنموذج: يبدأ مع Paper و10 إضافات. إذا لم تكن لديك أي إضافة في التثبيت، فغيّر 10 إلى صفر. بعد ذلك أدخل الإصدار ومسافة الرؤية، وعند الحاجة مسافة المحاكاة، بالقيم المستخدمة فعليًا في خادمك. وإذا كنت تخطط لمزرعة كثيفة أو redstone أو خريطة ويب أو عوالم إضافية، فانتقل إلى الإعدادات المتقدمة. وإلا فلا تحدد الخيارات لمجرد أن مربعاتها ظاهرة أمامك.

هامش التشغيل الافتراضي عند فتح الأداة هو 25 بالمئة. ويمكنك تغييره من 10 إلى 100 بالمئة في الإعدادات المتقدمة. بمجرد إغلاق تلك الإعدادات تُستبعد الأحمال الإضافية من الحساب ويعود الهامش إلى 25 بالمئة. إذا رأيت 6 GiB في تجربة و9 GiB في أخرى، فتحقق أولًا من المفاتيح التي كانت مفعلة. واكتب أيضًا المدخلات التي استخدمتها بجانب النتيجة. بهذه الطريقة لن تضطر إلى إعادة كل شيء من البداية عند البحث عن سبب الفرق.

8 GB تساوي تقريبًا 7.45 GiB. إذا كان إعلان الخادم يذكر GB، فأدخل GB في النموذج. وإذا كانت آلة افتراضية أو container لا تستطيع استخدام سوى جزء من RAM الفعلية، فأدخل ذلك الجزء باعتباره الحد المتاح. من السهل أن تطمئن لأنك «أدخلت 8 فظهرت 8». لكن إذا اخترت وحدات مختلفة في الجانبين، تصبح المقارنة غير صحيحة من البداية، خصوصًا إذا كانت النتيجة قرب حد نصف GiB.

نتيجتا RAM الظاهرتان على الشاشة

لا تعتبر رقم الـheap سعة الجهاز

Java heap هو الحد الأعلى للذاكرة التي يمكن أن يستخدمها الخادم لكائنات Java. أما إجمالي RAM فيترك أيضًا مساحة لنظام التشغيل وللذاكرة التي تستخدمها Java خارج الـheap. تخصص الحاسبة ما لا يقل عن 1 GiB لهذا الاستخدام الإضافي لـJava. وإذا كان 15 بالمئة من الـheap أكبر من ذلك، تستخدم هذه القيمة، ثم تقرّب النتيجة إلى الأعلى لأقرب نصف GiB. فإذا كانت قيمة الـheap على الشاشة 3.5 GiB، فإن -Xmx3584M الذي تنشئه الأداة يمثل القيمة نفسها. لا تعتبر رقم -Xmx هو إجمالي RAM لخطة الاستضافة.

جرّب الإعداد التالي: Paper لـ10 لاعبين، إصدار حديث، مسافة رؤية 8 chunks، ومسافة محاكاة 6 chunks، مع 10 إضافات بحمل متوسط. عندما تكون الإعدادات المتقدمة وChunky معطلتين، تعطي الأداة 3.5 GiB heap و6.5 GiB إجمالي RAM. على جهاز Linux بلا واجهة سطح مكتب ويحتوي على 8 GiB، تلائم متطلبات الذاكرة إذا لم تخصص هامشًا إضافيًا لتطبيقات أخرى. الآن أضف Windows وMinecraft client على الكمبيوتر نفسه. إذا أدخلت 1 GiB للتطبيقات الأخرى و4 GiB للـclient، يرتفع إجمالي المتطلبات إلى 13.5 GiB. وهنا لا يعود جهاز 8 GiB كافيًا. ولم نضف حتى إضافة واحدة إلى Paper. ما يستهلك RAM هنا هو العمليات الأخرى.

يخصص فحص الكمبيوتر 2 GiB لنظام Linux بلا واجهة سطح مكتب، و3 GiB لـLinux مع سطح مكتب، و4 GiB لكل من Windows وmacOS. وفي حالة الـcontainer لا يضيف حصة نظام تشغيل الجهاز المضيف. إذا كانت هناك خدمات أخرى تعمل داخله، فعليك إدخال RAM الخاصة بها في قسم «التطبيقات الأخرى». وعندما لا تكون سعة الجهاز كافية، لا تقلل الحاسبة الـheap تلقائيًا، بل تعرض مقدار النقص بوضوح.

الانتقال من Vanilla إلى modpack

لنستخدم مرة أخرى 10 لاعبين وإعدادات 8/6 chunks. في Vanilla تكون النتيجة 3 GiB heap و6 GiB إجمالي RAM. وإذا أضفت إلى Paper عدد 10 إضافات بحمل متوسط تصبح القيمتان 3.5 و6.5 GiB. أما مثال Fabric مع 50 mod بحمل متوسط فيعطي 5 و8 GiB، بينما يعطي مثال Forge مقدار 6 و9 GiB. لا أفسر هذه النتائج على أنها تعني أن «Fabric أخف من Forge في كل الحالات». عندما تتغير الـmods داخل الحزم تتغير المقارنة أيضًا. الأرقام توضح فقط كيفية تصرف الحاسبة عند استخدام المدخلات نفسها.

في مثال Paper، إذا بقي اللاعبون في المنطقة نفسها فسترى 3 GiB heap و6 GiB إجمالي RAM. وإذا تفرقوا وبدأوا باستكشاف أراضٍ جديدة تصبح القيمتان 4 و7 GiB. وفي الحالتين عدد اللاعبين هو 10. لهذا السبب لا أعتمد وحدها على نصيحة من نوع «كمية RAM معينة لكل لاعب». وإذا أضفت مزرعة كثيفة وخريطة ويب وتوليد عالم مخصص وعالمين نشطين إضافيين، يصل الحساب نفسه إلى 6 GiB heap و9 GiB إجمالي RAM. بدلًا من تفعيل المفاتيح الأربعة دفعة واحدة ومشاهدة النتيجة فقط، جرّب كل واحد منها منفردًا. عندها سترى أي نوع من الأحمال هو الذي يرفع الحساب.

حساب Chunky مقارنة بقياس الخادم أثناء التشغيل

في Chunky تختار أولًا اسم العالم والمركز والشكل ونصف القطر. في الشكل المربع تكون المساحة 4 × نصف القطر²، وفي الدائرة تكون π × نصف القطر². ولأن كل chunk تغطي مساحة 16 × 16 block، تقسم الحاسبة المساحة على 256. إذا كان المركز 0، 0 ونصف قطر المربع 3000 block، تكون النتيجة 140,625 chunk. وإذا كان نصفها قد تم توليده مسبقًا، يتبقى 70,313. وعند رفع نصف القطر إلى 6000 تصبح النتيجة 562,500 chunk. إضافة 3000 block لا تجعل العمل يتضاعف مرتين فقط، بل تصبح المساحة أربعة أضعاف. تحقق مرة أخرى من الرقم الموجود في خانة نصف القطر.

عند تفعيل Chunky ترتفع توصية الـheap لخادم Paper في المثال إلى 4 GiB، ويرتفع إجمالي RAM إلى 7 GiB. ويمكنك تنفيذ عملية توليد اختبارية قصيرة لتقدير القرص والمدة. إذا أدخلت 10,000 chunk جديدة، وزيادة في حجم المجلد مقدارها 256 MiB، ومدة 300 ثانية، فسترى للـ140,625 chunk المتبقية تقديرًا يقارب 3.52 GiB من مساحة القرص و1.17 ساعة. قد لا تبقى السرعة ثابتة طوال عملية توليد العالم. لا تدرج النسخ الاحتياطية أو ملفات خريطة الويب ضمن القياس. وقبل إرسال الأمر، اقرأ اسم العالم ونصف القطر مرة أخرى. صفر إضافي واحد سيؤثر في الوقت ومساحة القرص معًا.

شغّلت الخادم، وانتشر اللاعبون، وانخفض TPS. لا ترفع -Xmx مباشرة. TPS هو عدد تحديثات اللعبة في الثانية، بينما MSPT هو عدد المللي ثانية التي يستغرقها كل تحديث. استخدم /spark tps لرؤية القيمتين. وعندما تأخذ ملفًا تعريفيًا باستخدام Spark في وقت الحمل المرتفع، يمكنك معرفة ما إذا كان الوقت يُستهلك في توليد العالم أم في إحدى الإضافات. ويمكنك أيضًا قراءة ضغط Garbage Collection بشكل منفصل من بيانات GC. إذا كان الخادم يتوقف بسبب خطأ OOM، فحد RAM و-Xmx هما أول ما يجب فحصه. أما إذا انخفض TPS بينما لا تزال الذاكرة متاحة، فأنا أبدأ أولًا بفتح نتائج الـprofiler، وأفكر في ترقية RAM بعد ذلك.