XF 2.3 دليل حل مشكلة تضخم جدول xf_search في XenForo

دليل حل مشكلة تضخم جدول xf_search في XenForo

إذا لاحظت أن حجم قاعدة بيانات منتداك قد ارتفع بشكل غير متوقع، وبعد فحص phpMyAdmin اكتشفت أن جدول xf_search هو السبب (في بعض الأحيان مئات الميجابايت إلى بضعة جيجابايت!)، فهذا الدليل يغطي السبب والحل.

الأعراض

  • نما حجم قاعدة البيانات الإجمالي بشكل كبير دون زيادة مماثلة في المحتوى الفعلي
  • إظهار أحجام الجداول في phpMyAdmin يُظهر أن xf_search كبير بشكل غير طبيعي (حتى لو لم يكن عدد الصفوف ضخماً، فالحجم هو المشكلة وليس عدد الصفوف)

مهم: xf_search ليس نفس xf_search_index:

  • xf_search_index ← فهرس البحث الرئيسي للمحتوى (المواضيع، المشاركات، إلخ)
  • xf_search ← ذاكرة التخزين المؤقت لنتائج البحث التي يقوم بها المستخدمون والزوار

التضخم يكون دائماً تقريباً في الجدول الثاني (ذاكرة نتائج البحث المؤقتة)، وليس في فهرس المحتوى.

لماذا ينمو هذا الجدول؟

في كل مرة يقوم فيها شخص ما بالبحث، يتم تخزين مجموعة النتائج كصف (مع بيانات نتائج مُسلسلة) في هذا الجدول لتسريع ترقيم صفحات نتائج البحث. الأسباب الشائعة لنموه بشكل غير طبيعي:

  • عمليات بحث واسعة جداً أو ذات تطابق عالٍ - مصطلح بحث يتطابق مع كل المحتوى تقريباً على المنتدى قد ينتج صفاً واحداً بحجم عدة ميجابايت إلى مئات الميجابايت.
  • حركة بحث عالية من الزوار - إذا كان البحث مسموحاً للزوار، فكل زائر (بما في ذلك الروبوتات والزواحف) يمكنه توليد صفوف جديدة في هذا الجدول.
  • نشاط الروبوتات / الزواحف أو هجوم - ضرب الروبوتات لصفحة البحث بشكل متكرر باستعلامات متنوعة يمكن أن ينفخ هذا الجدول بسرعة.
  • مهمة التنظيف المجدولة لا تعمل بشكل صحيح - لدى XenForo مهمة مجدولة تسمى "Rebuild expired search forum caches" من المفترض أن تنظف هذا الجدول بشكل دوري. إذا كانت معطلة، أو كانت مهمة cron على الخادم لا تستدعيها فعلياً، فسوف ينمو الجدول دون رقابة.

الحل

قبل أن تبدأ


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

الخطوة ١ - ما الذي عادةً لا يساعد

تشغيل "Rebuild Search Index" من:

كود:
ACP > Tools > Rebuild Search Index

أو تشغيل:

كود:
OPTIMIZE TABLE xf_search;

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

الخطوة ٢ - الحل الفعلي: تفريغ جدول الذاكرة المؤقتة

عبر phpMyAdmin:


  1. اختر قاعدة بيانات منتداك
  2. اذهب إلى تبويب SQL
  3. قم بتشغيل:

كود:
TRUNCATE TABLE xf_search;

بعد تشغيل هذا، ينخفض حجم الجدول إلى بضعة كيلوبايت فوراً وتعود قاعدة بياناتك إلى حجمها الحقيقي. التأثير الوحيد هو أن المستخدمين سيحتاجون إلى إعادة تشغيل عمليات البحث الخاصة بهم - لا شيء آخر يُفقد.

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

الخطوة ٣ - التحقق من إدخال cron المرتبط

لمنع حدوث ذلك مرة أخرى، اذهب إلى:

كود:
ACP > Tools > Cron Entries

ابحث عن "Rebuild expired search forum caches" وأكد على:

  • أنها مُمكّنة
  • أن وقت "Next run" الخاص بها يتقدم فعلاً بعد مروره (مما يؤكد أن cron على جانب الخادم يستدعي cron.php الخاص بـ XenForo بشكل صحيح)

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

خطوة احترازية (فقط إذا كنت تشك في هجوم أو حركة مرور غير طبيعية)

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

تحذير: افعل هذا فقط إذا كنت تشك حقاً في حركة مرور غير طبيعية أو هجوم، لأن تعطيل بحث الزوار يؤثر على تجربة المستخدم (وفي بعض الحالات، على SEO). إذا كان هذا مجرد تراكم طبيعي (والذي يجب أن تمنعه مهمة cron العاملة الآن)، فهذه الخطوة غير ضرورية.

المصدر: كود نت - CodeNet
جميع الحقوق محفوظة © كود نت
 
عودة
أعلى أسفل