كيفية إصلاح تأخر (لاغ) خادم Minecraft

لاغ الخادم أم لاغ الشبكة أم لاغ جهاز اللاعب؟

أسرع اختبار هو أن تسأل: هل يعاني الجميع من اللاغ في اللحظة نفسها؟ الخادم المتأخر يجمّد كل اللاعبين معًا؛ أما الاتصال السيئ أو الجهاز البطيء فيؤثر في صاحبه فقط. بقية هذا الدليل تتناول لاغ الخادم.

قِس أولًا: TPS وMSPT وspark

يعمل خادم Minecraft بمعدل 20 tick في الثانية، أي أن لكل tick مهلة 50 ms لينتهي. رقمان يصفان مدى قدرته على المواكبة:

• TPS (عدد الـ tick في الثانية): 20 تعني أن الخادم يواكب؛ وما دون 20 يتباطأ العالم.
• MSPT (الميلي ثانية لكل tick): المدة التي يستغرقها كل tick. تحت 50 ms يوجد وقت فائض؛ وفوق 50 ms يتأخر الخادم.

يوفّر Paper الأمرين /tps و/mspt، لكن توثيقه نفسه يحيل إلى spark، المدمج في Paper منذ 1.21 والمتاح كمود لـ Fabric وForge وNeoForge:

/spark tps
/spark health
/spark ping

يعرض /spark tps قيمة TPS خلال الثواني والدقائق الأخيرة، والأهم أنه يعرض مدد الـ tick كحد أدنى ووسيط والمئين 95 وحد أقصى. ويعرض /spark ping بينغ اللاعبين، ما يحسم سؤال «الخادم أم الشبكة». ويضيف /spark health معلومات CPU والذاكرة والقرص.

اعثر على السبب بملف تحليل من spark

الأرقام تقول إن الخادم متأخر؛ أما ملف التحليل فيقول لماذا. ابدأ التحليل أثناء حدوث اللاغ واتركه يعمل بضع دقائق:

/spark profiler start --timeout 300

عند انتهائه ينشر spark رابطًا إلى عارضه على الويب. وفيه:

1. افتح Server thread — الخيط الرئيسي الذي يشغّل العالم. هناك يكمن اللاغ.
2. وسّع العناصر ذات النسب الأعلى: هناك يذهب وقت الـ tick.
3. انتقل إلى عرض Sources لترى الوقت مقسّمًا حسب الإضافة أو المود. إضافة أو مود واحد يستحوذ على حصة كبيرة من الخيط الرئيسي هو جوابك في الغالب.

أداتان أخريان تساعدان مع اللاغ الذي يأتي ويذهب: /spark tickmonitor يُبلغ عن كل tick يطول أكثر من اللازم، و/spark profiler start --only-ticks-over 100 يسجّل الـ ticks البطيئة فقط، حتى لا تضيع القفزة النادرة في المتوسط.

الإصلاحات المهمة، بالترتيب

1. مسافة الرؤية ومسافة المحاكاة

في server.properties، يحدد simulation-distance المسافة من اللاعبين التي يُحاكى فيها العالم فعلًا — الكائنات والمحاصيل والريدستون — ويحدد view-distance المسافة التي تُرسل فيها الـ chunks إلى اللاعبين. القيمة الافتراضية لكليهما 10. خفض simulation-distance غالبًا هو أكبر مكسب منفرد: جرّب من 6 إلى 8، وأبقِ view-distance أعلى قليلًا ليبقى العالم واسعًا في المظهر. هذه قيم للبدء وليست قيمًا رسمية؛ قِس قبل التعديل وبعده.

2. ولّد العالم مسبقًا

توليد chunks جديدة من أكثر ما يستهلك موارد الخادم، واستكشاف اللاعبين في اتجاهات مختلفة يجعله يفعل ذلك باستمرار. تولّد إضافة (أو مود) Chunky الخريطة مسبقًا:

chunky radius 5000
chunky start
chunky pause
chunky continue

شغّلها حين لا يلعب أحد — فالتوليد المسبق الجاري يجعل الخادم يُبلغ «Can't keep up» بطبيعته — وأوقفها مؤقتًا عند دخول اللاعبين.

3. الكائنات والمزارع

مزارع الكائنات وقاعات القرويين وأكوام الأغراض هي أكثر مصادر الاستنزاف المستمر شيوعًا. على Paper وSpigot، يتحكم entity-activation-range في spigot.yml في مدى قرب اللاعب اللازم قبل معالجة الكائن بالكامل في كل tick، ويدمج merge-radius الأغراض المُسقطة وكرات الخبرة. قيّد مزارع الكائنات بإضافة أو بقاعدة، ونظّف أكوام الأغراض المنسية.

4. القمعات والريدستون

سلاسل القمعات الكبيرة مكلفة. في spigot.yml، يحدد ticks-per.hopper-transfer عدد مرات نقلها للأغراض، ويسرّعها hopper.disable-move-event في Paper كثيرًا — لكنه يعطّل إضافات الحماية التي تعتمد على ذلك الحدث. أما الريدستون، فيمكن لـ misc.redstone-implementation: ALTERNATE_CURRENT في Paper أن يقلل كثيرًا من اللاغ الناتج عن غبار الريدستون، لكنه يغيّر سلوك الغبار، لذا اختبر آلاتك أولًا.

5. الإضافة أو المود الظاهر في ملف التحليل

إذا أشار ملف تحليل spark إلى إضافة أو مود بعينه، فهذا هو الإصلاح: حدّثه، أو خفّف إعداداته، أو استبدله. لا توجد كمية RAM تجعل إضافة سيئة البرمجة أسرع.

«TPS عند 20 لكن اللاغ مستمر»

هذه الحالة الأكثر إرباكًا، وهي في الغالب توقف في الـ tick: معظم الـ ticks سريعة، لكن بين حين وآخر يستغرق أحدها مئات الميلي ثانية. يبقى المتوسط عند 20، ومع ذلك يشعر الجميع بالتجمّد.

• تحقق من أقصى مدة tick في /spark tps، أو شغّل /spark tickmonitor. القفزات التي تبلغ عدة مئات من الميلي ثانية تؤكد ذلك.
• السبب المعتاد إضافة تنتظر على الخيط الرئيسي — تجلب سكنات اللاعبين أو رؤوسهم من الإنترنت، أو ترسل إلى webhook، أو تتحقق من التحديثات أو الترخيص، أو تحفظ ملفًا أو قاعدة بيانات بشكل متزامن. لا يفعل الخادم شيئًا أثناء الانتظار.
• حلّل الانتظار، لا الحساب فقط. ملف التحليل العادي يُظهر عمل CPU؛ والخيط المنتظر يبدو خاملًا. استخدم /spark profiler start --thread * لالتقاط أين يُصرف الوقت بما في ذلك الانتظار، وابحث عن استدعاءات الشبكة أو الملفات على Server thread.

الإصلاح في الإضافة نفسها — استدعاءات غير متزامنة، أو إضافة مختلفة. لن يفيد مزيد من RAM أو CPU أسرع أو اتصال أفضل، لأن الخادم لا ينقصه شيء؛ إنه ينتظر.

متى يكون الحل فعلًا RAM أو CPU

يحاكي Minecraft العالم على خيط رئيسي واحد. ولهذا نتيجتان:

• سرعة CPU لكل نواة هي الأهم. إذا أظهر spark أن Server thread مشغول بعمل العالم العادي — الكائنات والـ chunks وticks الكتل — وكانت MSPT مرتفعة، فإن CPU أسرع يفيد حيث لا تفيد نوى إضافية.
• RAM تفيد فقط عندما ينقصك منها. العلامات: يُعاد تشغيل الخادم عند بلوغه حد الذاكرة، أو تهيمن توقفات garbage collection على ملف التحليل. بعد تجاوز ما يحتاجه العالم والمودات، لا تفعل RAM الإضافية شيئًا لسرعة الـ tick — بل إن heap ضخمًا غير مضبوط قد يطيل توقفات garbage collection.

كم يحتاج الخادم من RAM، ومعاملات التشغيل التي تُبقي garbage collection قصيرًا، مشروحة في كم يحتاج خادم Minecraft من RAM. والاختيار بين Paper وPurpur وغيرهما في أفضل برامج خوادم Minecraft.

اللاغ وخادمك على HytHost

تعمل كل باقات Minecraft من HytHost على العتاد نفسه: معالجات Ryzen 7 وIntel i9 بتردد boost يصل إلى 5.0 GHz، وذاكرة DDR4 وتخزين NVMe — أي سرعة الخيط الواحد التي يعتمد عليها Minecraft. spark جزء من Paper أصلًا، لذا يمكنك التحليل من الكونسول مباشرة.

إذا أظهر ملف التحليل أن الخادم ينقصه فعلًا من الذاكرة ما يحتاجه عالمه وموداته، فانتقل إلى باقة أعلى من اللوحة؛ ويبقى العالم في مكانه. وإذا أشار إلى إضافة أو مزرعة، فأصلح ذلك أولًا — فهو مجاني ويعمل على أي باقة. اطّلع على استضافة Minecraft، أو الباقات الأكبر في استضافة Minecraft المميزة ابتداءً من €11.65 شهريًا.