الانتقال إلى المحتوى الرئيسي
Minecraftدليل

كيف تحسّنون أداء خادم Minecraft دون إفساد مزارعكم

خفض simulation-distance ليس مثل خفض view-distance. الأول يغيّر المنطقة التي يحاكيها الخادم حول اللاعب، والثاني يتحكم في حجم بيانات التضاريس المرسلة…

9 دقيقة للقراءةSharpHeberg
كيف تحسّنون أداء خادم Minecraft دون إفساد مزارعكم

خفض simulation-distance ليس مثل خفض view-distance. الأول يغيّر المنطقة المتمركزة حول اللاعب التي يحاكيها الخادم، أما الثاني فيتحكم في حجم بيانات التضاريس التي يرسلها إلى اللاعبين. فقد تبقى المناظر البعيدة مرئية بينما لا تعمل مزرعة هناك كما يتوقع صاحبها.

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

يغطي هذا الدرس خوادم Minecraft Java Edition الحديثة. تنطبق إعدادات المسافة على Vanilla وSpigot وPaper؛ أما أوامر الإضافات وإعدادات YAML فقد وُسمت بشكل منفصل. وهو ليس وصفة عامة لـ Bedrock أو حزم المودات أو Folia. قارنوا الوثائق بإصدار خادمكم بالتحديد: فالمراجع الحالية قد تصف إصدارات أحدث، ولا تبقى القيم الافتراضية ولا بنية الملفات ثابتة إلى الأبد.

1. قيسوا المشكلة أثناء حدوثها

سجّلوا إصدار Minecraft وبرنامج الخادم ونسخته، وعدد اللاعبين، وما يفعله اللاعبون عند حدوث البطء. قاعة تجارة مزدحمة ومجموعة تستكشف تضاريس جديدة هما حِملان مختلفان. وتحليل أداء خادم فارغ لن يفسّر أيًّا منهما؛ فـوثائق Paper تشترط صراحةً أن تكون المشكلة قائمة أثناء جمع البيانات.

على Paper، يأتي spark مدمجًا منذ الإصدار 1.21. أما على Spigot، فثبّتوا أولًا إضافة spark مستقلة متوافقة؛ فالأوامر التالية ليست مدمجة في خادم Vanilla غير المعدَّل.

نفّذوا هذه الأوامر داخل اللعبة بالصلاحيات المطلوبة:

code
/spark tps
/spark profiler start --timeout 600

يسجّل أمر المحلّل (profiler) لمدة عشر دقائق ثم يعيد رابط تقرير. احفظوا هذا التقرير مع إعداداتكم وملاحظات حِمل العمل.

عند معدل tick الطبيعي، يستهدف Minecraft 20 TPS، أي 50 ملّي ثانية لكل tick. يصف MSPT المدة التي تستغرقها الـ ticks، ولذلك يكشف ضغطًا قد تخفيه قراءة TPS وحدها. قارنوا بين الوسيط وMSPT عند المئين 95: الأخير يساعد في كشف الـ ticks البطيئة المتكررة، لكنه قد يفوّت الارتفاعات النادرة. افحصوا القيمة القصوى أيضًا، ولا تعتبروا مئينًا سليمًا دليلًا على أن شيئًا لم يتعطل.

بالنسبة إلى المشكلات المتقطعة، يمكن لـمراقب tick في spark أن ينبّه إلى الـ ticks التي تتجاوز هذه الميزانية:

code
/spark tickmonitor --threshold-tick 50

سجّلوا ما حدث في اللحظة نفسها. وإذا بقيت أزمنة الـ tick سليمة وقت الشكوى، فافحصوا معدل إطارات العميل أو ظروف الشبكة قبل التضحية بأسلوب اللعب على الخادم.

2. خذوا نسخة احتياطية وحدّدوا الإعدادات المطبَّقة فعلًا

قبل التعديل، أوقفوا الخادم بشكل سليم وخذوا نسخة احتياطية من العوالم وملفات الإعدادات وبيانات الإضافات. احتفظوا بالنسخة الاحتياطية خارج مجلد الخادم الحي وتأكدوا من قدرتكم على استعادتها. نسخة الإعدادات تجعل التراجع مريحًا؛ ونسخة العالم تحمي العمل الذي بُني عليه.

استخدموا محرر نصوص، وحافظوا على مسافات YAML البادئة، وغيّروا شيئًا واحدًا في كل تجربة. شغّلوا الخادم بشكل طبيعي بعد ذلك وافحصوا سجل الإقلاع بحثًا عن أخطاء الإعدادات. لا تستخدموا /reload أو أداة تحميل ساخن للإضافات كاختصار؛ فإعادة تحميل الإضافات قد تترك التبعيات والحالة غير متسقة.

بالنسبة إلى Vanilla، ابدؤوا بـ server.properties. وبالنسبة إلى Spigot وPaper، افحصوا أيضًا spigot.yml: فإعدادات المسافة لكل عالم قد تتجاوز ملف properties.

يوضّح هذا المقتطع الوراثة، وليس إعدادًا مسبقًا للأداء:

yaml
world-settings:
  default:
    view-distance: default
    simulation-distance: default

هنا، تأمر القيمة default هذين الخيارين باستخدام قيم server.properties. ادمجوا المفاتيح في القسم الموجود؛ ولا تستبدلوا الملف كله ولا تضيفوا كتلة world-settings ثانية. وافحصوا أقسام العوالم المسمّاة أيضًا، لأن قيمة خاصة بعالم معيّن قد تتجاوز الإعداد المشترك.

إذا استبدلتم القيم الرقمية المتجاوِزة بالوراثة، فاعتبروا ذلك تغييرًا منفصلًا وسجّلوا خط أساس جديدًا. وإلا فقد تغيّرون عدة مسافات فعلية قبل أول اختبار منضبط.

3. افصلوا رؤية التضاريس عن المحاكاة

تُقاس المسافتان بـ**الـ chunks حول اللاعب**، وليس بالكتل ولا بالقطر.

منطقة رؤية زرقاء مبسّطة ومنطقة محاكاة كهرمانية أصغر حول اللاعب نفسه. تنطبق أيضًا قواعد تحميل وقرب أخرى.

مسافة الرؤية ليست مجانية لمجرد أن بعض التضاريس خارج مسافة المحاكاة. وبالمثل، فخفضها ليس بديلًا عن إصلاح إضافة مكلفة. اختاروا التجربة الأولى بناءً على التحليل (profile) وعلى تنازل أسلوب اللعب الذي يمكنكم قبوله.

جرّبوا تغيير مسافة واحدة

لنفترض أن server.properties الحالي لديكم يحتوي على:

properties
view-distance=10
simulation-distance=10

إذا كان التحليل يشير إلى عمل الـ ticks عبر المناطق المحمَّلة، فإحدى التجارب أن تُبقوا مسافة الرؤية دون تغيير وتخفضوا مسافة المحاكاة قليلًا:

properties
view-distance=10
simulation-distance=8

هذه الأرقام توضيحية، وليست قيمًا افتراضية عامة ولا إعدادًا مسبقًا مجرَّبًا من SharpHeberg. وإذا كانت مسافة الرؤية لديكم مختلفة، فاتركوا قيمتكم كما هي. أعيدوا التشغيل بشكل سليم، وأعيدوا إنتاج حِمل العمل الأصلي، واجمعوا تقريرًا آخر قبل أي خفض إضافي.

أما إذا كان التحليل يشير بدلًا من ذلك إلى أن المشكلة في صيانة التضاريس البعيدة أو إرسالها، فاختبروا مسافة الرؤية بشكل منفصل. لا تخفضوا الإعدادين معًا ثم تحاولوا تخمين أيهما ساعد.

مسافة المحاكاة ليست كتاب قواعد كاملًا للمزارع. فتذاكر الـ chunks (chunk tickets)، التي تُبقي الـ chunks محمَّلة لأسباب معينة، ومتطلبات قرب اللاعب تختلف بين الآليات والإصدارات. «محمَّل» لا يضمن أن التفريخ ونمو المحاصيل والكيانات وكيانات الكتل تتصرف جميعها بالطريقة نفسها. افحصوا متطلبات مزرعتكم المحددة بدلًا من افتراض أن مسافة واحدة تضمن عملها.

وللتفريخ الطبيعي والاختفاء أيضًا قواعد مسافة خاصة بهما؛ ويضيف كل من mob-spawn-range في Spigot وإعدادات الاختفاء في Paper ضوابط إضافية. فإذا توقفت مزرعة عن العمل بعد التجربة، فأعيدوا أولًا المسافة السابقة. ولا تعوّضوا فورًا بتغيير عدة إعدادات تفريخ.

4. على Spigot أو Paper، افحصوا عمل الكيانات قبل تقليص النطاقات

إذا كان التحليل يشير إلى معالجة الكيانات، فافحصوا المنطقة المتأثرة. ابحثوا عن عناصر مُسقَطة متراكمة، أو حظائر مكتظة، أو قاعة تجارة تؤدي عملًا غير ضروري. نسّقوا مع أصحاب المباني قبل تغييرها. فتقليل مصدر محدد للعمل الزائد أسهل في التقييم من إضعاف سلوك الكيانات في كل مكان.

خياران في spigot.yml متشابهان في الاسم يؤديان وظيفتين مختلفتين:

الإعداد الوحدة ما الذي يتحكم به
entity-activation-range الكتل مدى قرب الكيانات من اللاعبين لكي تعمل ticks بشكل طبيعي؛ ويُخنَق السلوك خارج هذا النطاق.
entity-tracking-range الكتل مدى بُعد الكيانات الذي تُرسل عنده إلى اللاعبين، ما يؤثر في وقت ظهورها.

هذه ضوابط للكيانات، وليست المسافات المبنية على الـ chunks أعلاه. وخفض نطاق التتبع قد يجعل الكائنات تظهر فجأة؛ وهو لا يعادل تقليل عبء الذكاء الاصطناعي لديها.

تتطلب تغييرات التنشيط عناية خاصة حول مزارع الحديد والقرويين. توثّق إرشادات المجتمع مزارع معطّلة ومشكلات في إعادة التخزين ناتجة عن تنشيط مفرط في الصرامة أو تغييرات في القرويين غير النشطين. اتركوا هذه الإعدادات كما هي ما لم يبرّر التحليل المقايضة، ثم اختبروا فئة الكيانات المتأثرة بدلًا من نسخ إعداد مسبق كامل.

ينطبق التحفظ نفسه على nerf-spawner-mobs وتوقيت الـ hopper وتغييرات دمج العناصر: فهي تغيّر السلوك، لا مجرد استهلاك الموارد. لا تجروا تخفيضات شاملة في سقف الكائنات ولا تثبّتوا حذفًا مجدولًا للكيانات كأول استجابة للبطء.

5. تعاملوا مع إعدادات Paper كضوابط خاصة بكل إصدار

يوفّر Paper طبقات إعدادات إضافية. فـبنيته الموثّقة تتضمن config/paper-global.yml للإعدادات العامة وconfig/paper-world-defaults.yml لإعدادات العوالم المشتركة. ويمكن لملف paper-world.yml الخاص بعالم ما أن يتجاوز هذه القيم الافتراضية للعالم.

حدّدوا مكان ملف التجاوز هذا اعتمادًا على وثائق نسختكم. فـبنى مجلدات العوالم والأبعاد تختلف؛ ونسخ مسار من درس قديم قد يقودكم إلى المكان الخطأ. انسخوا فقط الإعدادات التي تنوون تجاوزها، لا ملف القيم الافتراضية بأكمله.

يوفّر Paper ضوابط للتفريخ والاختفاء والتصادمات وسلوك الـ hopper. هذه خيارات لمشكلة محددة، وليست قائمة تحقق يجب إكمالها. فعلى سبيل المثال، تعطيل حدث تحريك الـ hopper قد يعطّل إضافات الحماية التي تعتمد عليه. تحسّن بسيط في التوقيت لا يبرّر تجاوز قاعدة في الخادم بصمت.

مرجع spigot.yml المُستشهَد به تتولى صيانته Paper ويتضمن سلوكًا خاصًا بـ Paper. لا تفترضوا أن كل خيار متداخل يوثّقه موجود أو يتصرف بالطريقة نفسها على Spigot الخالص. راجعوا الإعدادات المولَّدة لتنفيذكم وإصداركم قبل إضافة أي مفتاح.

6. تابعوا التحليل إلى ما بعد إعدادات المسافة

افحصوا عمل الإضافات

إذا أشار التقرير إلى مهمة إضافة، فاحفظوه وافحصوا إعدادات تلك الإضافة وتوافقها وملاحظات إصدارها. توصي Paper صراحةً بـمشاركة تقرير spark ذي صلة مع مطوّري الإضافات عند التحقيق في مشكلات الأداء.

أعيدوا إنتاج المشكلة على نسخة اختبار احتياطية حيثما أمكن. غيّروا ميزة أو إضافة واحدة في كل مرة، مع مراعاة التبعيات، ثم كرروا النشاط نفسه. تجنبوا تعطيل إضافات الحماية أو الاقتصاد على الخادم الحي لمجرد معرفة ما إذا كان TPS سيرتفع.

اجعلوا ضبط Java والذاكرة قائمًا على الأدلة أيضًا. راجعوا سلوك جمع القمامة (garbage collection) ومتطلبات Java لنسخة خادمكم بالتحديد قبل تغيير خيارات التشغيل. فمجموعة منسوخة من علامات GC ليست خطوة تحسين عامة.

ولّدوا العالم مسبقًا فقط عندما يكون التوليد هو المشكلة

عندما يتزامن البطء مع الاستكشاف، قارنوا التنقل عبر تضاريس موجودة بالتنقل إلى تضاريس جديدة. وإذا دعم التحليل أن توليد الـ chunks هو عنق الزجاجة، فإن التوليد المسبق ينقل عمل التوليد إلى ما قبل اللعب الاعتيادي. يوفّر Chunky أدوات لهذا الغرض.

اختاروا المنطقة والأبعاد المقصودة، وتحققوا من مساحة القرص وسعة النسخ الاحتياطية، وجدولوا العمل خارج ساعات الذروة. اختبروا منطقة محدودة أولًا. فالتوليد المسبق لا يزيل تكلفة تحميل الـ chunks الموجودة أو إرسالها، ولا تكلفة تشغيل المزارع داخلها.

تختلف أدلة المجتمع حول مدى التوصية بـالتوليد المسبق للخوادم الحديثة. تعاملوا معه كاستجابة لضغط توليد مقيس، لا كصيانة إلزامية لكل تثبيت Paper.

7. تحققوا من أسلوب اللعب قبل الإبقاء على التغيير

كرروا حِمل العمل الأصلي بعدد لاعبين وتوزيع مماثلين. احتفظوا معًا بتقارير spark قبل التغيير وبعده، وفرق الإعدادات، والملاحظات. كرروا المقارنة إذا تغيرت الظروف بشكل كبير.

ثم اختبروا الخادم كما يستخدمه اللاعبون:

  • شغّلوا المزارع المهمة من مواضع AFK المعتادة، بما في ذلك التجميع والنقل.
  • افحصوا صفقات القرويين وإعادة تخزينها خلال دورة عمل طبيعية.
  • شغّلوا فارزات الـ hopper والساعات مدة كافية لكشف العناصر الفائتة أو التوقيت المتغيّر.
  • افحصوا ظهور الكائنات وسلوكها أثناء التنقل، واختبروا كل عالم متأثر.

أبقوا على التغيير فقط إذا كان التحسن المقيس مفيدًا وكان تنازل أسلوب اللعب مقبولًا. وإذا لم يكن الأثر واضحًا، فأعيدوا القيمة السابقة. ولا تعطّلوا الحفظ أبدًا لمجرد جعل رسم الأداء يبدو أفضل.

وإذا بدا أن عنق الزجاجة المتبقي هو سعة الاستضافة، فاستخدموا التقرير لتوجيه ذلك النقاش. يمكنكم مراجعة استضافة Minecraft من SharpHeberg مقارنةً بحِمل عملكم ومتطلباتكم. إن خيارات الاستضافة وتغييرات الإعدادات تستحق الاختبار نفسه: هل يعمل الخادم بشكل أفضل مع الحفاظ على الطريقة التي يلعب بها مجتمعكم؟

قراءة ذات صلة: التكلفة الحقيقية لخادم Minecraft عالي الأداء في 2025. اعتبروا أي أسعار في ذلك المقال القديم تاريخية، لا تعرفة حالية.

المصادر

Paper — server.properties

Paper — مرجع spigot.yml

Paper — إعدادات العالم

Paper — التحليل باستخدام spark

Minecraft optimization — دليل المجتمع

spark — العثور على ارتفاعات التأخر

Chunky — الوثائق

Paper-chan — دليل التحسين

spark — TPS وMSPT

Paper — مصدر وثائق الإعدادات

مقالات ذات صلة

المزيد من قاعدة معارفنا في هذه المقالات ذات الصلة

صورة الغلاف لمقالة كيفية تثبيت Codex على VPS بنظام Linux (Debian/Ubuntu)
VPSدليل

كيفية تثبيت Codex على VPS بنظام Linux (Debian/Ubuntu)

ثبّتوا Codex CLI على VPS بنظام Linux، وسجّلوا الدخول عبر SSH، وابدؤوا بمهمة للقراءة فقط. مع عرض تشخيص حقيقي لـ nginx وفحوصات أمان عملية.

7 دقيقة للقراءة

نُشرت في 16 أكتوبر 2026 بقلم SharpHeberg

شكرًا لقراءتك تحليلاتنا وشروحاتنا التقنية

العودة إلى المدونة