أكثر ثلاث رسائل لاق شيوعا في سجل Minecraft لا تعني الشيء نفسه: Can't keep up! Is the server overloaded? تعني أن سيرفرك ما زال يعمل، لكنه لا يواكب الحمل. A single server tick took 60.00 seconds تعني أن فرامل الطوارئ المدمجة أنهته بالقوة. Exception in server tick loop تعني أن خطأ برمجيا محددا كسر حلقة اللعب. من يتعامل مع الثلاثة بالطريقة نفسها غالبا يصلح الشيء الخطأ.

التمييز بين الرسائل الثلاث

Minecraft يحسب عالم اللعب 20 مرة في الثانية. كل دورة من هذه الدورات تسمى Tick ويجب ألا تستغرق أكثر من 50 مللي ثانية. كل لاق تشعر به هو انحراف عن هذا الرقم الواحد.

رسالة السجل ما الذي حدث فعلا هل ما زال السيرفر يعمل؟
Can't keep up! Is the server overloaded? Running 5074ms or 101 ticks behind تستغرق الـ Ticks أكثر من 50 ms، والسيرفر يعالج تأخرا متراكما نعم، لكن بثقل واضح
A single server tick took 60.00 seconds + Considering it to be crashed تجاوزت Tick واحدة قيمة max-tick-time؛ أنهى Watchdog العملية لا، تم إنهاؤه بالقوة
Exception in server tick loop وصل خطأ إلى الحلقة الرئيسية لا، غالبا مع تقرير تعطل
Dispatched async TPS command (تحذير Paper) قياس TPS الخاص بنا يستعلم عن السيرفر من الخارج نعم — هذا طبيعي

السطر الأخير يسبب ارتباكا بشكل متكرر: Paper يسجل كل استعلام قادم من الخارج كتحذير. هذا هو قياس الأداء المجدول لدينا كل حوالي خمس دقائق، وليس خطأ ولا تدخلا في لعبك.

أهم خطوة: عند رسائل Watchdog اقرأ للأعلى

إيقاف Watchdog هو عرض، وليس سببا. هو يقول فقط: شيء ما حظر Server-Thread لمدة أطول من المسموح. أما ما الذي حظره، فهو مكتوب في مكان آخر.

هناك حالتان، وتؤديان إلى إجراءات مختلفة تماما:

الحالة 1 — جاء Watchdog أولا. قبل سطر Watchdog يظهر تشغيل لعب عادي. عندها تكون مدة الـ Tick هي الرسالة فعلا: شيء ما جمّد السيرفر أثناء التشغيل.

الحالة 2 — جاء Watchdog لاحقا. قبل سطر Watchdog يوجد بالفعل Stopping server أو Preparing crash report. عندها كان السيرفر ميتا أصلا أو في طور الإيقاف، وWatchdog قام فقط بتنظيف إيقاف عالق.

هذه الحالة الثانية ليست نادرة. في حالة دعم بتاريخ 22 أغسطس 2026 تعطل Server-Thread عند 13:20:15، وبدأ Stopping server نظيفا — وبعد 60 ثانية فقط أطلق Watchdog. من يعلن هناك أن مدة الـ Tick هي السبب، يوجه صاحب السيرفر بعيدا عن رسالة الخطأ الحقيقية التي كانت موجودة قبلها بدقيقة. لهذا تحديدا يقيّم تحليل الكونسول لدينا إصابة Watchdog عمدا في النهاية: إذا كان في نفس مقطع السجل توقيع أكثر تحديدا، ستظهر لك تلك النتيجة وليس „كانت Tick بطيئة“.

الوصول إلى السبب خطوة بخطوة

1. افحص مسار TPS في اللوحة

افتح سيرفرك في اللوحة. تحت „Performance (letzte 24h)“ سترى مسار TPS؛ يتم القياس تقريبا كل خمس دقائق طالما أن السيرفر يعمل. شكل المنحنى يخبرك بالكثير:

  • هبوط حاد في وقت محدد → حدث. طابق الوقت مع السجل: توليد عالم، نسخة احتياطية، لاعب في منطقة غير مستكشفة، مهمة Plugin.
  • قيم منخفضة باستمرار → حمل زائد بنيوي. هنا لا يساعد إعادة التشغيل، بل تخفيف الحمل.
  • نمط سن المنشار → نموذجي لضغط الذاكرة: السيرفر يعمل، Garbage Collection تقاطعه، ويتكرر ذلك.

إذا بقيت القيم منخفضة ضمن نافذة زمنية أطول، ستبلغك اللوحة تلقائيا بالملاحظة „TPS منخفض باستمرار“.

2. قِس MSPT — TPS وحده لا يكفي

اكتب في الكونسول /spark tps. يعطي الأمر رقمين، والثاني هو الأهم:

  • TPS — عدد الـ Ticks في الثانية، الحد الأقصى 20.
  • MSPT — المللي ثانية لكل Tick. كل شيء حتى 50 ms صحي.

لماذا MSPT؟ Bukkit وSpigot وPaper يبطئون عمليات السيرفر لتجنب التعطل. لذلك قد يعرض المؤشر 20 TPS ثابتة، بينما السيرفر عمليا يعمل على الحد الأقصى منذ مدة. قيمة MSPT مقدارها 45 ms تعني: أنت على بعد Mob-Farm واحدة من لاق واضح — حتى لو كان عرض TPS ما زال يبدو مثاليا.

في Paper ابتداء من 1.21 يكون spark مضمنا بالفعل، ولا تحتاج إلى تثبيت أي شيء.

3. حدّد المسبب بالـ Profiler

لا تخمن أي Plugin هو السبب — قِس ذلك:

/spark profiler start --timeout 120

أعد خلال هاتين الدقيقتين تنفيذ الحالة التي تسبب اللاق. بعدها افتح رابط النتيجة الذي يخرجه السيرفر. يعرض التقرير، مرتبا حسب نسبة الوقت، أين يذهب وقت الـ Tick: Mod محدد، مهمة Plugin، تحميل Chunks، معالجة Entities أو Garbage Collection.

هذه هي النقطة التي يفترق فيها هذا الدليل عن „اشتر RAM أكثر“. يجيب الـ Profiler عن السؤال الذي لا تستطيع أي جدول توصيات الإجابة عنه: ما الذي يستهلك الوقت بالضبط على سيرفرك؟

4. خفف الحمل بشكل موجه

ما يعرضه الـ Profiler يحدد الإجراء:

ما يعرضه الـ Profiler الإجراء الفعال
تحميل Chunks، توليد عالم خفّض simulation-distance (الافتراضي 10، الحد الأدنى 3) — تأثيره أقوى من view-distance، لأن Chunks المحاكاة فقط تكلف وقت معالجة
معالجة Entities حدّ من Mob-Farms، ضع الحيوانات داخل أسوار بدلا من تركها تتحرك بحرية، ونظف تجمعات Items
Redstone / Block-Ticks ابن ساعات Redstone باستخدام Observers بدلا من حلقات Repeater، وأوقف الآليات التي تعمل باستمرار
Plugin واحد أو Mod واحد عطله للتجربة وقِس من جديد؛ ابحث عن بديل أو إصدار أحدث
Garbage Collection الآن تكون RAM أكثر هي الإجابة الصحيحة — وليس قبل ذلك

النقطة الأخيرة مهمة: RAM تصلح مشكلة ذاكرة فقط. إذا كانت ساعة Redstone تلتهم وقت الـ Tick، فلن تجعل باقة أكبر السيرفر أسرع. يحسب لك حاسبة RAM لـ Minecraft لدينا مقدار الذاكرة المناسب لعدد لاعبيك وحجم Modpack لديك.

5. max-tick-time — الاستثناء، وليس الحل

توجد القيمة في server.properties وتحدد من أي مدة Tick يتدخل Watchdog. القيمة الافتراضية هي 60000 مللي ثانية، أي 60 ثانية. إذا تم تجاوز القيمة، ينهي السيرفر نفسه.

توصي كثير من الأدلة على الإنترنت في هذه النقطة بإيقاف Watchdog باستخدام -1. لا تفعل ذلك كحل افتراضي. Watchdog هو الجهة المدمجة الوحيدة التي تلاحظ أصلا وجود Deadlock حقيقي. مع -1 يبقى السيرفر الميت عالقا لساعات على المنفذ: اللاعبون لا يستطيعون الدخول، لا شيء في السجل يشرح السبب، ولن يتم تنبيه أحد. أنت أزلت المؤشر، لا المشكلة.

هناك مبرر جيد واحد فقط للزيادة: عملية معروفة تستغرق وقتا طويلا بشكل مشروع. الحالة الكلاسيكية هي أول تشغيل لـ Modpack كبير، حيث يستغرق توليد العالم وتهيئة Mods معا أكثر من دقيقة داخل Tick واحدة. عندها تكون قيمة مثل 180000 (ثلاث دقائق) مقبولة — مؤقتا، وبنية إعادتها بعد أول تشغيل ناجح.

عندما يظهر Exception in server tick loop في السجل

هذه الرسالة هي الأبسط بين الثلاثة، لأنها تأتي بسببها معها. مباشرة أسفلها أو بعد عدة أسطر قليلة يوجد سطر Caused by: — هناك يوجد الخطأ الفعلي، غالبا مع اسم الـ Mod أو الـ Plugin المسؤول.

الخطوات:

  1. ابحث عن Caused by: وسجل اسم الكلاس.
  2. إذا احتوى على اسم Mod أو Plugin، فقد تم تسمية المسبب.
  3. إذا ظهر الخطأ بعد تغيير (Mod جديد، تحديث، عالم جديد)، ألغ هذا التغيير أولا.
  4. إذا بقي الخطأ غير واضح، أعطِ المقطع الكامل للدعم — مع الوقت.

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

ما نتولاه تلقائيا لأجلك

  • قياس أداء بدون أي تدخل منك. يتم تسجيل TPS كل حوالي خمس دقائق وعرضه في اللوحة لمدة 24 ساعة — لا تحتاج إلى تثبيت Plugin لذلك.
  • تحذير عند ضعف مستمر. إذا بقي الأداء منخفضا خلال نافذة زمنية موثوقة، سيتم تنبيهك بدلا من أن تضطر لملاحظته بنفسك.
  • أسطر سجل مشروحة. تحصل الرسائل المكتشفة على السبب والحل بلغة واضحة، بلغتك — وحيث يوجد دليل مناسب، رابط إليه.
  • قاعدة العرض قبل السبب. إذا كانت في نفس مقطع السجل رسالة خطأ أوضح من Watchdog-Kill، نعرضها لك.

استكشاف الأخطاء: العرض، الفحص، الحل

العرض الفحص الحل المحتمل
لاق فقط عند استكشاف مناطق جديدة هل يحدث عندما يدخل اللاعبون إلى أرض غير مستكشفة؟ توليد عالم؛ خفّض simulation-distance، واجعل العالم يتولد مسبقا
لاق في أوقات ثابتة طابق الوقت مع المهام المجدولة انقل توقيت النسخة الاحتياطية أو خطة إعادة التشغيل
السيرفر يتوقف بدون خطأ، وينتهي السجل فجأة هل يوجد A single server tick took في النهاية؟ Watchdog-Kill؛ اقرأ الدقيقة التي قبله
TPS يعرض 20 ومع ذلك يوجد تقطيع /spark tps — راجع MSPT TPS-Limiter يخفي الحمل؛ قرر بناء على MSPT
بعد إضافة Mod أزل الـ Mod وقِس من جديد تعارض Mod أو Mod كثيف الحمل
سن منشار في مسار TPS افحص Garbage Collection عبر Profiler ضغط ذاكرة؛ زد RAM
„Dispatched async TPS command“ في السجل هذا السطر فقط، ولا شيء مريب غيره لا شيء عليك فعله — هذا قياسنا

FAQ

من أي قيمة TPS يلاحظ اللاعبون شيئا؟

حتى حوالي 18 TPS لا يظهر شيء في اللعب. تحت 15 يصبح الثقل ملحوظا. لكن لا تعتمد على ذلك وحده: افحص MSPT أيضا، لأن TPS-Limiter قد يعرض رقما سليما بينما السيرفر يعمل بالفعل على الحد الأقصى.

هل تفيد RAM أكثر ضد اللاق؟

فقط إذا كانت الذاكرة هي عنق الزجاجة فعلا. إذا أظهر الـ Profiler أن Garbage Collection هي البند الرئيسي، نعم. إذا أظهر ساعة Redstone أو Mob-Farm، فلن تغير RAM أكثر شيئا. قِس أولا، ثم اشترِ بعد ذلك.

هل يجب أن أوقف Watchdog؟

لا، ليس بشكل دائم. -1 يأخذ منك الاكتشاف التلقائي الوحيد لتجمد حقيقي. زيادة مؤقتة لـ max-tick-time لعملية بطيئة معروفة مثل أول تشغيل لـ Modpack مقبولة — ثم أعدها بعد ذلك.

لماذا تظهر رسالة Watchdog بعد „Stopping server“؟

لأن السيرفر كان بالفعل في مرحلة الإيقاف وعلق أثناءها. عندها قام Watchdog بتنظيف إيقاف عالق، ولم يقتل سيرفرا ما زال يعمل. السبب موجود قبل Stopping server.

هل تساعد إعادة التشغيل؟

ضد تأخر حاد نعم، ضد السبب لا. إذا عاد اللاق بعد كل إعادة تشغيل خلال وقت قصير، فهو بنيوي — عندها لا يوصلك أبعد إلا القياس.

ما الفرق بين view-distance وsimulation-distance؟

view-distance تحدد مدى رؤية اللاعبين؛ simulation-distance تحدد إلى أي مدى يتم حساب العالم فعلا. كلاهما مضبوط افتراضيا على 10 Chunks. وبما أن Chunks المحاكاة فقط تكلف وقت معالجة، فإن خفض simulation-distance يعطي تخفيفا أكبر مع فقدان مرئي أقل.

إذا استمر اللاق

اجمع قبل طلب الدعم ثلاثة أشياء: الوقت الدقيق لآخر حادثة، رابط تقرير spark-Profiler الخاص بك، وبيان أي Mods أو Plugins تمت إضافتها مؤخرا. بهذا يمكن فحص المقطع المناسب في السجل بدقة، بدلا من إجراء جولة تحسين عامة.

ستجد إعدادات عامة عبر كل الألعاب — خطط إعادة التشغيل، اختيار الباقة، الشبكة — في دليل تحسين أداء Gameserver. أما طريقة تثبيت Mods وPlugins وإزالتها بشكل نظيف، فموجودة في تثبيت Mods وPlugins لـ Minecraft.

تريد سيرفرا تكون فيه قياسات TPS وشرح السجلات والتحذيرات موجودة بدون عمل إضافي؟ ستجد الباقات المناسبة في استئجار سيرفر Minecraft.

المصادر ومنصة الاختبار

  • max-tick-time، Tickrate والمسافات: PaperMC — server.properties. يوثق القيمة الافتراضية 60000 مللي ثانية، الإنهاء القسري عند التجاوز، التعطيل باستخدام -1، وكذلك القيم الافتراضية 10 لـ view-distance وsimulation-distance.
  • spark مضمّن في Paper: PaperMC — Profiling. ابتداء من Paper 1.21 لا يلزم تنزيل منفصل.
  • MSPT قبل TPS: spark — TPS and MSPT. يشرح لماذا يمكن أن يعرض TPS-Limiter قيمة 20 ثابتة بينما السيرفر فعليا يعمل أبطأ.
  • أوامر Profiler: spark — Command Usage. مصدر الأمرين /spark profiler start --timeout <sekunden> و/spark profiler stop.

منصة الاختبار: 24 أغسطس 2026. قد تتغير القيم الافتراضية والأوامر مع إصدارات سيرفر جديدة؛ عند الشك افحص وثائق الشركة المصنعة المرتبطة.