مرحباً بالجميع،
لقد قمنا بترقية خادم Centos7 من الإصدار 2.2.2 إلى 2.7.0.beta4، ومنذ ذلك الحين نواجه تأخيراً في تحميل الصفحات، خاصة في الصفحات التي تتضمن قواعد بيانات أو صوراً. وقد وصل الأمر إلى حد جعل النظام غير قابل للاستخدام.
نقدر أي توجيهات في هذا الصدد.
حدثت العديد من الأمور خلال السنوات القليلة الماضية. كان هناك تغيير في البق يتطلب معالجة جميع الصور. أشك في أن خادمك مثقل بهذه المهمة. يمكنك الاطلاع على /sidekiq لرؤية قائمة الانتظار.
ما حجم قاعدة بياناتك؟ كم عدد الصور؟ ماذا تظهر قائمة Sidekiq؟ هل تستخدم قرصًا صلبًا من نوع SSD، أليس كذلك؟
إنه خادم يعتمد على الآلة الافتراضية، لذا لا أملك تأكيدًا فيما إذا كان يستخدم محرك أقراص الحالة الصلبة أم لا. لا أرى Sidekiq متاحًا، حيث لم قمت بنشر هذا التطبيق بنفسي، لذا لا أعرف كيفية الوصول إليه.
هل تعرف كيف تم تثبيته؟ يبدو أنه ليس تثبيتًا قياسيًا (وإلا، لكان /sidekiq متاحًا لك إذا كنت مسؤولاً).
أفضل مسار للمضي قدمًا هو التحقيق في سبب انخفاض الأداء. فهناك الكثير من الوظائف الخلفية التي أضيفت على مر السنين (مثل تحسين الصور وإعادة الخبز، إلخ) والتي من المرجح أنها تعمل حاليًا وتستهلك موارد الخادم الخاص بك. بمجرد انتهاء تلك الوظائف، من المفترض أن يتحسن الأداء.
يُعد الوصول إلى /sidekiq (باستخدام حساب مدير!) لاكتشاف الوظائف قيد التشغيل خطوة أولى ممتازة.
حسنًا، تمكنت من الوصول إلى Sidekiq. هل يمكنكم مساعدتي في فهم هذا وتقديم أي تحسينات مقترحة؟ أنا في ورطة حقيقية بسبب هذه المشاكل المتعلقة بالأداء.
السلوك الذي ألاحظه مع الخادم هو أنه يستمر في إظهار قائمة الانتظار الفارغة حتى عندما أحاول فتح منشور لرؤيته مدرجًا، لكن بوابة Sidekiq تتعطل أيضًا عند تحميل المنشور ولا يتم تحديثها إلا بعد اكتمال تحميل المنشور بالكامل.
أيضًا، مرة أخرى، عند التحميل، تظهر قائمة انتظار فارغة. أي مساعدة أو اقتراحات ستكون محل تقدير كبير.
إذا كانت قائمة الانتظار فارغة، فهذا يعني أنك لا تواجه مشكلة تشغيل العديد من الوظائف في الخلفية. إذن المشكلة تكمن في شيء آخر.
هل لديك أي إضافات؟ هل لديك مكونات سمة تقوم بإجراء العديد من استدعاءات واجهة برمجة التطبيقات (API)؟
لقد طرحت بعض الأسئلة الأخرى أعلاه.
ما حجم قاعدة بياناتك؟
كم عدد الصور؟
هل لديك مكونات سمة تُجري العديد من استدعاءات واجهة برمجة التطبيقات (API)؟
هل يمكنك إخباري بكيفية الحصول على هذه المعلومات من إعداد قائم على Docker؟ أعلم أن آخر نسخة احتياطية يبلغ حجمها 135 ميجابايت.
أما بالنسبة للإضافات، نعم لدينا الإضافات التالية:
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/jonmbake/discourse-ldap-auth.git
- git clone https://github.com/discourse/discourse-math
- git clone https://github.com/discourse/discourse-chat-integration.git
- git clone https://github.com/discourse/discourse-voting.git
- git clone https://github.com/unfoldingWord-dev/discourse-mermaid.git
- git clone https://github.com/discourse/discourse-solved.git
- git clone https://github.com/discourse/discourse-assign.git
- git clone https://github.com/discourse/discourse-knowledge-explorer.git
- git clone https://github.com/discourse/discourse-cakeday.git
أوصي بإزالة إضافة Mermaid.
كم عدد المنشورات والمستخدمين لديك؟ وما حجم الزيارات؟
كم مقدار الذاكرة العشوائية (RAM) المتوفرة؟
يبدو أن خادمًا رقميًا بسعة 2 جيجابايت من DigitalOcean سيكون كافيًا؛ يمكنك إنشاء مثيل جديد والتحقق من أداءه.
ربما توجد مشكلة أخرى في خادمك؟ هل هو محدث؟ هل تم إعادة تشغيله مؤخرًا؟
حسناً، سأقوم بإزالة ذلك.
لدينا حوالي 4 آلاف منشور وحوالي 350 مستخدماً.
عدد المستخدمين النشطين في نفس الوقت ليس مرتفعاً جداً، ربما يتراوح بين 5 إلى 10 مستخدمين كحد أقصى في المتوسط.
تم رفع هذا الخادم مؤخراً وهو يشاركه 8 جيجابايت من ذاكرة الوصول العشوائي (RAM) و10 جيجابايت من مساحة التبديل (Swap). وقد كان يعمل بشكل متواصل لمدة 13 يوماً حتى الآن. لكن مشاكل الأداء موجودة بغض النظر عن إعادة التشغيل ومدة التشغيل.
يوجد خطأ واضح في التثبيت الخاص بك؛ كان يجب أن تحصل على أداء أفضل بكثير مع هذا العتاد.
جرّب إجبار PostgreSQL على تنفيذ عملية تفريغ (vacuum) صريحة. إذا كنت تستخدم تثبيت الحاوية الشاملة (all-in-one container install):
# docker exec -it -u postgres app psql discourse
psql (13.1 (Debian 13.1-1.pgdg100+1))
Type "help" for help.
discourse=# VACUUM ANALYZE;
VACUUM
كم عدد عمال يونيكورن (unicorn workers) المحددة في ملف app.yml الخاص بك؟
يمكنك طلب من Discourse إضافة رؤوس أداء إضافية في الاستجابات بإضافة ما يلي في قسم env الخاص بك:
DISCOURSE_ENABLE_PERFORMANCE_HTTP_HEADERS: true
وفي الوقت نفسه، يمكنك تمكين miniprofiler باتباع هذا المنشور.
هذا يجب أن يكون كافياً جداً.
لا أتذكر ما إذا كان قد تم اقتراح ذلك وقمت بإعادة تشغيل discourse-setup لضبط استخدام ذاكرة Discourse، أو ما إذا كانت هذه القيم الافتراضية معقولة بالنظر إلى أي شيء آخر يستخدم الخادم.
إذا لم قمت بإعادة فهرسة قاعدة البيانات بعد ترقية PG13، فقد ترغب في الاطلاع على تحديث PostgreSQL 13 للحصول على بعض المعلومات حول ذلك.
نعم بالتأكيد، عدم وجود إحصائيات للجدول (VACUUM ANALYZE) هو السبب الأرجح هنا.
VACUUM FULL VERBOSE;
REINDEX DATABASE discourse;
VACUUM VERBOSE ANALYZE;
لذا، قمت بتشغيل هذه الأوامر وضبطت الرأس في env أيضًا، لكنني لا ألاحظ فرقًا كبيرًا في وقت تحميل الصفحة.
أنا أدير 8 من unicorns.
هل نفذت تلك الأوامر في PostgreSQL، أليس كذلك؟
نعم، تم تنفيذ أمر docker exec -it -u postgres app psql discourse قبل تشغيل الأوامر المذكورة أعلاه.
حسناً، هذا غريب جداً. لم يواجه أي شخص آخر مثل هذه المشاكل. يبدو أن لديك عتاداً كافياً. تخميني الوحيد هو وجود مشكلة ما في وكيل عكسي (أظن أن لديك أشياء أخرى على الجهاز؟).
نعم، خدمة أخرى تعتمد على Docker. لكن لا توجد أي مهام تتطلب أداءً عاليًا على الإطلاق، لأن ذلك كان سيظهر في مقاييس أداء الجهاز.
