كم يحتاج خادم Minecraft من RAM؟

ما الذي يحدّد فعلاً كم تحتاج من RAM

رافعتان تحدّدان كم يحتاج خادم Minecraft من ذاكرة. وكل ما عداهما تفاصيل هامشية بجانبهما.

• عدد اللاعبين يزيد RAM تدريجياً. فكل لاعب متصل يحمّل القطع (chunks) المحيطة به، لذا فإن زيادة عدد اللاعبين — ورفع قيمة view-distance — تعني أن جزءاً أكبر من العالم محفوظ في الذاكرة دفعةً واحدة. الانتقال من 4 لاعبين إلى 20 زيادة حقيقية، لكنها قابلة للاحتواء.
• التعديلات والإضافات هي الرافعة الكبرى بفارق واسع. فـ Vanilla خفيف. وحفنة من إضافات Paper تزيد الحمل قليلاً. أما حزمة modpack فهي فئة مختلفة تماماً: إذ يحمّل كل تعديل شيفرته وعناصره ومكعّباته وتوليد عالمه إلى الذاكرة قبل أن ينضمّ لاعب واحد، ولهذا قد تحتاج حزمة CurseForge من 200 تعديل إلى أضعاف ما يحتاجه خادم vanilla من RAM لعدد اللاعبين نفسه.

هذا هو النموذج كلّه: vanilla يتوسّع مع اللاعبين، والمُعدّل يتوسّع مع التعديلات. كما يرفع حجم العالم وعمره الرقم قليلاً — فخريطة مترامية عمرها سنوات وبها قطع محمّلة كثيرة تكلّف أكثر من خريطة جديدة — لكن اللاعبين والتعديلات هما ما تحدّد الحجم على أساسه. واحتفظ بأمر واحد في ذهنك وأنت تتابع القراءة: RAM ليست سوى أحد موارد الخادم، وبعد حدٍّ معيّن تكفّ عن كونها المورد المهم (المزيد عن ذلك في لماذا لا تكون زيادة RAM دائماً هي الحل).

كم يحتاج خادم Minecraft من RAM، بحسب الإعداد

هذا هو تحديد الحجم الذي نبني عليه الباقات — الأرقام نفسها التي ننصح بها صديقاً. و"RAM المستهدفة" هي ما تخصّصه للخادم نفسه، لا إجمالي ذاكرة جهازك الذي يحتاج إلى هامش فوقها (راجع كيف توزّعها).

أتشغّل حزمة modpack ولست متأكداً في أي فئة تقع؟ حجم الحزمة وعدد اللاعبين كلاهما يرفعك في الجدول — ويفصّل دليل خادم Minecraft المُعدّل المُحمِّلات وأحجام الحزم بالتفصيل.

كيف تمنح خادمك تلك الذاكرة

معرفة الرقم نصف المهمة؛ والنصف الآخر هو أن تسلّم تلك الذاكرة فعلاً إلى الخادم. وتختلف طريقة ذلك بحسب المكان الذي يعمل فيه الخادم.

الاستضافة الذاتية: وسيطا -Xmx و -Xms

حين تشغّل ملف jar الخاص بالخادم بنفسك، يتحكّم وسيطان في ذاكرته. يحدّد -Xmx الكومة القصوى (السقف)، ويحدّد -Xms الكومة الابتدائية. وبالنسبة إلى Minecraft، فالنصيحة الشائعة والمُجرَّبة جيداً هي ضبطهما متساويين، كي تحجز آلة Java الافتراضية (JVM) كامل ذاكرتها منذ البداية بدلاً من إعادة تحجيمها تحت الحمل:

java -Xms4G -Xmx4G -jar server.jar nogui

هذا السطر يبدأ خادماً بـ 4 GB. وإليك بضعة أمور تُوقع الناس في الخطأ:

• استخدم Java بنسخة 64-bit. لا تستطيع Java بنسخة 32-bit معالجة أكثر من نحو 1.5 GB، لذا إن رفض -Xmx4G الإقلاع فهذا هو السبب عادةً. وأي بناء حديث من Temurin أو Java 25 هو 64-bit.
• لا تمنح الخادم كامل ذاكرتك أبداً. اترك 1-2 GB على الأقل لنظام التشغيل، وأكثر إن كنت تشغّل عميل Minecraft على الجهاز نفسه أيضاً — فاللعبة تحتاج إلى ذاكرتها الخاصة فوق ذاكرة الخادم.
• ثم اضبط الأداء بوسائط Aikar. ما إن تعمل الأساسيات، حتى تُعيد "وسائط Aikar" المعيارية لدى المجتمع ضبط جامع المهملات G1 في Java بما يلائم نمط ذاكرة Minecraft، مقايضةً جزءاً يسيراً من RAM بنبضات (ticks) أكثر ثباتاً بوضوح. وهي الخطوة التالية المعيارية بعد مجرّد -Xmx/-Xms. أما الشرح الكامل للاستضافة الذاتية — من ملف jar واتفاقية EULA وتوجيه المنافذ وكل شيء — ففي كيف تُنشئ خادم Minecraft.

الاستضافة المُدارة: اختر حجماً، وترقَّ في مكانه

على خادم مُدار لا توجد وسائط لتعديلها. فأنت تختار RAM بمنزلق عند الطلب، ويُجهَّز الخادم بذلك الحجم — ووسائط الإقلاع (بما فيها وسائط Aikar) مضبوطة لك سلفاً.

تظهر الفائدة الحقيقية حين تتجاوز تقديرك الأول: في صفحة استضافة Minecraft تحرّك المنزلق للأعلى فتنطبق RAM الإضافية على الخادم نفسه، مع بقاء العالم والإعدادات سالمةً — دون إعادة تثبيت ودون ترحيل، ويتمّ ذلك في نحو دقيقة. وهذا بالضبط سبب كون القاعدة العامة أعلاه هي "ابدأ صغيراً": فعلى باقة مُستضافة، لا تكلّف إضافة RAM لاحقاً سوى دقيقة.

علامات تدلّ على أن خادمك يحتاج مزيداً من RAM

لست مضطراً للتخمين إن كان خادمك يعاني نقص الموارد. فهو يخبرك بذلك، بطرق قليلة يسهل تمييزها:

• تتأخّر النبضات (ticks). تطبع الطرفية Can't keep up! Is the server overloaded? Running Xms behind, skipping Xs tick(s)، ويظهر ذلك داخل اللعبة على شكل ارتداد مطّاطي (rubber-banding)، وتجمّد للوحوش، وتأخّر لحظي في كسر المكعّبات.
• يتلعثم حفظ العالم. تجمّد وجيز كل بضع دقائق، متزامن مع الحفظ التلقائي، كثيراً ما يعني أن الخادم يتصارع على الذاكرة.
• ينهار تماماً. أوضح إشارة على الإطلاق هي انهيار يحتوي سجلّه على java.lang.OutOfMemoryError: Java heap space — أي أن الخادم طلب ذاكرة أكثر مما يسمح به سقف -Xmx لديه.

لتعرف أيّهما، يُظهر مُحلّل الأداء المجاني spark (شغّل /spark health أو /spark profiler) توقيتات النبضات واستهلاك الذاكرة، وترسم لوحة التحكم المُستضافة RAM اللحظية على رسم بياني. فإن بقيت الذاكرة ملتصقة قرب السقف، فكبّر الحجم. وإن كان في الذاكرة متّسع لكن النبضات لا تزال تتأخّر، فاقرأ القسم التالي أولاً.

لماذا لا تكون زيادة RAM دائماً هي الحل

هذا هو الجزء الذي تغفله معظم نصائح تحديد الحجم. يشغّل Minecraft حلقة اللعبة الرئيسية — "النبضة" (tick) التي تحرّك الوحوش وتُنبت المحاصيل وتعالج الـ redstone — على خيط معالجة واحد إلى حدٍّ كبير. الذاكرة تحفظ العالم؛ ونواة واحدة تقوم بالتفكير. وما إن يملك الخادم ما يكفي من RAM ليحفظ كل شيء، فإن إضافة المزيد لا تجعل تلك النواة أسرع.

نتيجتان جديرتان بأن تترسّخا في ذهنك:

• إن تأخّرت النبضات بينما لدى RAM متّسع، فعنق الزجاجة هو المعالج لا الذاكرة. فحشو خادم عالق على نواة واحدة بـ 32 GB لا يغيّر شيئاً. وهذا أشيع خطأ منفرد يرتكبه الناس في تحديد الحجم.
• بل قد يضرّ الإفراط في RAM. فالكومة الضخمة جداً تمنح جامع المهملات في Java مساحة أكبر ليكنسها دفعةً واحدة، وقد يتحوّل ذلك إلى تلعثمات توقّف أطول — سبب إضافي لصمود قاعدة "ابدأ أصغر".

ما يُحدث الفارق فعلاً حين يكون المعالج هو الحدّ هو تردّد عالٍ للساعة. لهذا يشغّل HytHost خادم Minecraft على معالجات Ryzen وIntel i9 عالية التردّد بدلاً من أنوية كثيرة بطيئة — فما يهمّ Minecraft هو سرعة النواة الواحدة، لا عددها. أما من جانب البرمجيات فيمكنك تخفيف حمل تلك النواة بخفض view-distance وsimulation-distance، وبتوليد قطع عالمك مسبقاً، وبتشغيل Paper بدلاً من vanilla، أو بإضافة تعديلات أداء مثل Lithium في إعداد مُعدّل. RAM تحمّل عالمك؛ أما المعالج وخياراتك البرمجية فهي ما يقرّر سلاسة تشغيله.