الموقع يستجيب بشكل سيء للغاية منذ الليلة الماضية

أتقدم بعتذري مسبقًا إذا كان هذا التصنيف أو الموقع غير مناسب.
أعمل على موقع Discourse منذ حوالي 6 أشهر عبر خادم VPS من DigitalOcean دون مشاكل كبيرة. تظهر صفحة الإدارة أن الإصدار هو 2.5.0.beta4. اعتبارًا من الليلة الماضية، إما أن محتوى معظم صفحات الموقع يرفض التحميل أو يستغرق وقتًا طويلًا بشكل غير مبرر. على سبيل المثال، يمكنني التنقل إلى صفحات مثل الصفحة الرئيسية أو /admin، لكن أي محتوى فعلي لها (منشورات، رسوم بيانية للإدارة أو علامات تبويب أخرى) لا يبدو أنه يتحمّل. تفحصت مؤشرات حيوية للنظام، وتتراوح استخدام وحدة المعالجة المركزية حول 2%، مع وجود حركة مرور أو استخدام للقرص ضئيل. عدد المستخدمين حوالي 10 أشخاص فقط حيث أنني فقط أختبر/أعدّ الموقع. وبالنظر إلى ذلك، يبدو هذا السلوك غريبًا جدًا.

أما الإضافات الوحيدة التي أملكها وفقًا لملف app.yml فهي docker_manager و discourse-signatures. وأنا المستخدم الوحيد المسؤول، لذا يمكنني تأكيد أن إعدادات الموقع لم تتغير منذ فترة طويلة.

كانت فكرتي الأولى إعادة تشغيل الجهاز نفسه، كما حاولت أيضًا التحديث يدويًا باستخدام git pull و ./launcher rebuild app. لست متأكدًا مما يجب البحث عنه أثناء هذه العملية لمعرفة ما إذا كانت هناك أخطاء، لكن عملية إعادة البناء تبدو مكتملة ويمكن الوصول إلى الموقع مرة أخرى بعدها، لكنه لا يزال على الإصدار 2.5.0.beta4. وبالمثل، فإن محاولة الوصول إلى صفحة /admin/update ستؤدي في النهاية إلى انتهاء مهلة الاتصال. يبدو كل هذا غريبًا إلى حد ما لأن الموقع عمليًا ‘يعمل’ - أنا ببساطة لا أعرف كفاية عن كيفية عمله لتشخيص أي مشكلة. عثرت على أداة discourse-doctor ويمكنني تشغيلها، لكنني لست متأكدًا مما تحققه - فهي ترسل لي بريدًا إلكترونيًا بنجاح، إلخ.

الشيء الوحيد الذي قد يشير إلى وجود مشكلة هو أنني تلقيت الليلة الماضية بريدًا إلكترونيًا من المنتدى بشأن رد على منشور، وعندما انتقلت إلى فئة ‘أحدث المنشورات’ (بعد أن تتحمّل في النهاية)، لا يبدو أن هناك أي مؤشر على وجود المنشور، لأن ملخص الموضوع في أحدث المنشورات لا يظهر أن هذا المستخدم نشره مؤخرًا. لا أستطيع تحميل محتوى أي منشور، لذا لا توجد طريقة للتحقق بالتأكيد. لذا قد يكون هناك خطأ أو عدم تطابق في قاعدة البيانات؟ لست متأكدًا كيف يمكن لمثل هذا الأمر أن يتفرّع ويسبب فشل تحميل أجزاء كاملة من الموقع، أو ما إذا كان هذا أمرًا يستحق المتابعة.

أي أفكار حول أين نبدأ في استكشاف مشكلة كهذه؟ شكرًا جزيلاً لو قرأت هذا : )

مرحبًا tuckie! أهلاً بك!

يبدو أنك تقوم بكل الإجراءات الصحيحة.

أوصيك بشدة بالتحديث إذا كان ذلك ممكنًا — فأنت متخلف إلى حد كبير عن أحدث إصدار. لكن تأكد من تنزيل نسخة احتياطية أولاً حتى لا تفقد أي شيء.

هل يمكنك تسجيل الدخول عبر SSH والتحقق مما إذا كنت تعاني من نفاد مساحة التخزين؟

df -h

بغض النظر عن الحالة، يُعد التخزين أول شيء يجب التحقق منه، وهذه الأوامر مفيدة جدًا لتنفيذها لإزالة أي حاويات قديمة تشغل مساحة:

./launcher cleanup app

بعد ذلك، جرب إعادة بناء التطبيق إلى أحدث إصدار. أخبرنا إذا نجح الأمر هذه المرة ولم تظهر أي أخطاء في وحدة التحكم.

./launcher rebuild app

شكرًا لك على الاستجابة السريعة.
يُظهر النظام حوالي 7.9 جيجابايت من المساحة الحرة في القرص المثبت على /dev/vda1 والمُرفَق في / - لستُ على دراية كبيرة بكيفية استخدام الأقسام الأخرى في نظام أوبونتو أو كيف قد تؤثر على التشغيل (ديسكورش يعمل داخل حاوية، أليس كذلك؟)، ويبدو أن الباقي هو قسم التمهيد وما إلى ذلك. لا يوجد سوى حوالي 30-40 منشورًا إجماليًا على المنتدى أثناء الاختبار، لذا لا يبدو أنه معرض للخطر هناك. وقد نجحت عملية التنظيف في تحرير حوالي 4 جيجابايت إضافية.

أما فيما يتعلق بإعادة بناء التطبيق، فقد قمت بتشغيله عدة مرات بالفعل. لا أرى أي رسائل تحذير واضحة تظهر أثناء العملية، وفي الوقت نفسه، عند الانتهاء لا أرى أي رسالة تشير إلى ‘النجاح’ - ولا أعرف أي أسطر أخطاء أو تحذيرات يجب البحث عنها. يقوم بإزالة الحاوية القديمة ثم تشغيل حاوية دوكر، ثم ينتهي الأمر. لقد قمت بتشغيله مرة أخرى للتو، وعند الاتصال بالموقع يخبرني أن التحديثات متاحة، لكنه يستغرق وقتًا طويلاً بشكل لا يصدق للإبلاغ عن الإصدار الذي أعمل عليه (2.5.0.beta4 لا يزال) والإصدار المراد الترقية إليه.

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

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

يبدو أن المشكلة تتعلق بالشبكة. هل تستخدم Cloudflare؟ (إذا كان الأمر كذلك، قم بإيقاف تشغيل السحابة البرتقالية).

قد يكون لديك جار مزعج في DigitalOcean، لذا قد تحتاج إلى فتح تذكرة معهم.

لا معنى لما تقول بأنه قمت بإعادة البناء بينما الإصدار لم يتغير. أعتقد أنك ستحتاج إلى ترقية PostgreSQL 12. هل لم تلاحظ أي شيء يتعلق بذلك عند إجراء إعادة البناء؟

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

أما بالنسبة لإعادة البناء/تغيير الإصدار - فقد يكون أن خطأًا مثل ذلك يحدث، لكنني لا أعرف طريقة جيدة للتعامل مع تحليله، ولا أعرف حقًا ما الذي أبحث عنه. لقد رأيت سطرًا على غرار ‘تم تثبيت postgres’ أثناء مراقبة خروج النص يتدفق أثناء تشغيل إعادة البناء مرة أخرى للتو. لست متأكدًا مما إذا كان هذا بسبب العمل الجاري داخل حاوية أم لا، لكن على سبيل المثال، الأمر ./launcher rebuild app | grep 'postgres' لا يبدو أنه يرشح أي شيء، وكذلك الأمر ./launcher rebuild app > output.txt && grep 'postgres' output.txt. يحتوي ملف output.txt على معلومات بداخله، لكن يبدو أنه لا يحتوي على كل شيء؟ على الأقل لا ينتهي بنفس الطريقة التي ينتهي بها مخرج وحدة التحكم الفعلي.

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

عند محاولة الوصول إلى الموقع عبر Firefox، يظهر الآن ما يلي:

واجه الموقع الموجود في https://aregames.art/ انتهاكًا لبروتوكول الشبكة لا يمكن إصلاحه.

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

لم أتمكن من العثور على معلومات مفيدة من مستعرض المتصفح، لأنه لا يبدو أن هناك ردًا على طلب GET.

منذ اكتشاف هذه المشكلة الجديدة، قمت بما يلي:

  • تشغيل عملية إعادة البناء عدة مرات
  • تحديث نظام Ubuntu إلى الإصدار 20.04
  • إعادة البناء مرة أخرى

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

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

هل الخادم يعمل؟ هل يمكنك الدخول إليه عبر SSH؟

إذا كان الأمر كذلك، أعد تشغيل الخادم ثم أعد بناء Discourse.

إذا لم يعمل الخادم بعد كل ذلك، الصق مخرجات إعادة البناء هنا وسنساعدك.

نعم، يمكنني استخدام SSH بشكل صحيح، وهذا هو الطريقة التي قمت بها بتشغيل إعادة البناء في كل مرة. ولا، لا يزال غير قابل للوصول بعد إعادة البناء. ألاحظ (حتى بعد إعادة البناء) أن أمر ifconfig يعرض حاوية Docker بعنوان IP مختلف عن عنوان IP للخادم، ولا يمكنني الوصول إليه من متصفح الويب الخاص بنظامي. لست متأكدًا مما إذا كان هذا مقصودًا أم لا. يبدو أن الأمر ./launcher rebuild app > output.txt يُخرج فقط جزءًا من مخرجات وحدة التحكم الفعلية، لكن يمكنني تضمين ذلك أيضًا.

Ubuntu Pastebin (ملف إخراج قصير)
Ubuntu Pastebin (إخراج كامل من طرف المحطة)
أرى بعض رسائل الخطأ من postgres تشير إلى أن قاعدة بيانات ‘discourse’ موجودة بالفعل، هل يستحق البحث في ذلك؟

هل إعدادات DNS الخاصة بك صحيحة؟

host aregames.art 
aregames.art has address 198.54.117.200
aregames.art has address 198.54.117.199
aregames.art has address 198.54.117.198
aregames.art has address 198.54.117.197

لماذا هناك عناوين IP كثيرة؟ ما هو عنوان IP للخادم الخاص بك؟

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

مع ذلك، لا يزال لدي بعض الارتباك بشأن المشاكل التي واجهتها في البداية - هل كنت أستخدم نسخة مخزنة مؤقتًا من الصفحة، وبسبب مشاكل خادم الأسماء لم تكن طلبات المحتوى تمر؟ بعض الأشياء، مثل حتى المنشورات في موضوع معين، أو قائمة المنشورات عند فتح ‘أحدث المنشورات’، كانت ستظهر في النهاية، ولكن بعد وقت طويل.

تحديث: host aregames.art كما ذكرت أعلاه يبدو أنه يحل مرة أخرى إلى عنوان IP الصحيح وخادم البريد. تمكنت من التأكد من خلال سكريبت إعداد discourse أنه يقبل DNS كمتجه إلى عنوان IP. يبدو أن سكريبت الإعداد قام أيضًا بتشغيل إعادة البناء. ومع ذلك، يؤدي التنقل إلى URL إلى ظهور رسالة ‘خادم غير موجود’. يؤدي الوصول إلى عنوان IP مباشرةً على المنفذ 443 إلى ظهور خطأ 400 من nginx، وهو ما يبدو نوعًا ما تقدمًا.

تعديل مرة أخرى: كان علي مسح ذاكرة التخزين المؤقت للمتصفح - تم تحميل الموقع بشكل كامل وصحيح من تبويب التصفح المتخفي. الأمور تبدو تعمل مرة أخرى! أعتقد… أن دفع ثمن موقعي كان هو الحل لإصلاح الموقع هنا.

نعم، كنت تستخدم العرض المخزن.

أضفنا ميزة جديدة في Discourse 2.6 لإضافة فئة CSS محددة للمستند عندما تكون في هذا العرض، لكننا لا نملك عنصر واجهة مستخدم افتراضيًا له بعد.

يمكنك قراءة المزيد عنه على Offline Indicator