متابعة لهذا المنشور: Slow Page Loads on User Profiles
نختبر استيرادنا إلى Discourse مرة أخرى الآن بعد دفع هذه التغييرات، وهناك تحسن في تحميل الملفات الشخصية (خاصة بعد التحميل الأولي عندما تكون البيانات في ذاكرة التخزين المؤقت)، لكن لا يزال تحميل بعض الملفات الشخصية يستغرق من 5 إلى 10 ثوانٍ. هل هناك أي شيء آخر يمكن القيام به للمساعدة هنا؟ يبدو أن هذه الاستعلامات هي المسؤولة عن المشكلة:
كيف قمت بتثبيت discourse؟
تثبيت حاوية Docker من التعليمات.
كم مقدار الذاكرة العشوائية (RAM)؟ وما حجم قاعدة البيانات لديك؟
يحتوي هذا الجهاز الافتراضي على 8 أنوية و32 جيجابايت من ذاكرة الوصول العشوائي. أعتقد أن حجم قاعدة البيانات يبلغ حوالي 40 جيجابايت، لكنني لست متأكدًا بنسبة 100% في الوقت الحالي.
هل لا تزال صفحة الملف الشخصي بطيئة التحميل في الحالات التالية:
عند عرض صفحة ملف المستخدم كمستخدم مجهول (غير مسجل الدخول)؟
عند عرض صفحة ملف مستخدم عادي مقارنةً بمستخدم من طاقم العمل؟
نعم، لكليهما. لقد قمت بالاختبار مع مستخدم عادي وسجلت الخروج، ويبدو أن السلوك متشابه تقريبًا.
لقد جربت تصديرًا واستعادة (راجع: Restore Failing - Check Free Disk Space) لكن هذا لم يبدُ أنه غيّر السلوك. ومن الجدير بالذكر أيضًا أنني غالبًا ما أحصل على خطأ عند محاولة عرض صفحات الملفات الشخصية هذه. يظهر هذا الخطأ بعد بضع ثوانٍ من محاولة تحميل الصفحة.
قاعدة البيانات تبلغ الآن 104 جيجابايت بعد الاستعادة.
كان ذلك الموضوع يركز في الغالب على عدد من استعلامات N+1 التي كانت موجودة في ذلك المسار، وقد تم إصلاحها جميعًا الآن.
صفحة الملف الشخصي تحتوي بالفعل على بعض الاستعلامات الثقيلة لأنها تُخرج ملخصًا مخصصًا وشاملاً جدًا للمستخدم، لكن قاعدة بيانات بحجم معقول يجب أن تكون قادرة على عرضها في أقل من 500 مللي ثانية.
هذه قاعدة بيانات كبيرة لآلة افتراضية صغيرة. هل تقوم بتشغيل كل شيء في نفس الآلة الافتراضية (ويب + قاعدة بيانات + ريدز)؟
هل تستخدم أحدث إصدار من PostgreSQL 13؟ هل يمكنك محاولة تنفيذ مهام الأداء الاختيارية الموضحة في تحديث PostgreSQL 13، وهما vacuum وreindex؟
المستخدمون الذين يواجهون المشكلة هم أولئك الذين لديهم عدد كبير من المنشورات. صفحات الملفات الشخصية للمستخدمين ذوي عدد المنشورات المنخفض يتم تحميلها فورًا كما هو متوقع.
ربما أحتاج إلى تعديل توقعاتي هنا. هل يُعتبر 8 أنوية و32 جيجابايت من ذاكرة الوصول العشوائي صغيرًا لـ Discourse؟ (نعم، نقوم بالتشغيل كتركيب حاوية واحدة.) على برنامجنا الحالي، ندير هذا المنتدى بسهولة باستخدام نواتين و8 جيجابايت من ذاكرة الوصول العشوائي.
أما بالنسبة لقاعدة البيانات، فهي حاوية تم بناؤها مؤخرًا لذا بدأت بالإصدار 13.1. هل ستكون عملية الفراغ وإعادة الفهرسة ضرورية مباشرة بعد الاستعادة؟
يُوصى بشدة بإجراء عملية الفراغ لقاعدة بيانات بهذا الحجم.
بدأت هذه الإجراءات فورًا بعد منشورك. اكتملت عملية التفريغ بسرعة كبيرة، لكن إعادة الفهرسة لا تزال مستمرة حتى الآن، بعد أكثر من 24 ساعة من بدء تشغيلها. هل هذا أمر طبيعي؟ كم من الوقت يُتوقع أن تستغرق هذه العملية؟ وكيف يمكنني معرفة ما إذا كان هناك مورد (إن وجد) مقيد؟ لا ألاحظ أن postmaster يستخدم أكثر من 2-4 أنوية في معظم الأوقات، ويبدو أن هناك ذاكرة عشوائية (RAM) متوفرة بكثرة.
يسعدني أن أبلغكم أن إعادة الفهرسة لا تزال قيد التنفيذ.
@Falco @codinghorror @pfaffman
لقد عملت أنا و@Ghan طوال العام الماضي على تحسين عملية الاستيراد والتأكد من نجاحها لمجتمعنا، لكن السؤال الذي يدور في ذهني هو: هل هناك اعتبارات أخرى يجب أن نأخذها في الحسبان عند استيراد مجتمع يضم أكثر من 25 مليون منشور؟
هل توجد مجتمعات بهذا الحجم على منصة Discourse؟
لاحظت من خلال النظر إلى قائمة العملاء العامة أنه، على الأقل من بين تلك التي يمكنني رؤيتها، لا يوجد أحد قريب من حجم مجتمعنا. أتخيل أن هناك آلافًا أو عشرات الآلاف من العملاء الآخرين الذين لا أستطيع رؤيتهم. لقد أكملنا عملية الاستيراد بنجاح، وهي تعمل من جانبنا، لكننا نستمر في الاصطدام بمشكلات مثل مشكلة تحميل الملفات الشخصية للحسابات التي تحتوي على عدد كبير من المنشورات، والآن هذه المشكلة المتعلقة بإعادة الفهرسة.
هل هناك أي نصائح يمكن تقديمها لنا لتسهيل هذه المرحلة الانتقالية؟
لقد وجدت أمر rake db:stats من منشور آخر.
ما زال إعادة الفهرسة قيد التشغيل، لذا لست متأكدًا مما إذا كانت هذه الأرقام نهائية بنسبة 100٪.
نعم، كما ذكرت في موضوع آخر، لدينا نسخ قواعد بيانات بحجم 1 جيجابايت ونسخ بحجم 500 جيجابايت. ولكن تلك النسخ تعمل على آلات افتراضية بأحجام مختلفة تمامًا.
كيف يكون أداء القرص على خادمك؟ هل يستخدم أقراصًا صلبة قديمة دوّارة؟
لدينا قرصان صلبان من نوع Intel P3600 NVMe بسعة 1.2 تيرابايت لكل منهما، ومُهيّآن على خادم المضيف باستخدام تقنية ZFS في وضع المرآة.
أول ما يجب التحقق منه هو ضبط PostgreSQL. هل تستخدم الإعدادات الافتراضية في ملف app.yml؟
نعم. لم أكن متأكدًا مما إذا كان مشغل التطبيق سيحدد تلقائيًا بعض القيم بناءً على الموارد التي يكتشفها على جهاز المضيف، أو ما إذا كانت هناك إرشادات موصى بها لضبط الإعدادات. هل توجد دليل في مكان ما لضبط قاعدة البيانات؟
هناك بعض التعليقات في ملف app.yml، رغم أنه مُحسّن في الأصل للمواقع الصغيرة المستضافة ذاتيًا. على الأرجح أنك ترغب في زيادة بعض الإعدادات هناك (لا أتذكر أسماءها الدقيقة). ستحتاج إلى الرجوع إلى مصادر عامة أكثر حول PostgreSQL للحصول على مزيد من المعلومات.
المسألة ليست أن discourse غير قادر على استيعاب مجتمع بحجم مجتمعك، بل إن الأمر يختلف عن تشغيل مجتمع أصغر، وهو أصعب قليلاً.
شكرًا لك، سأقوم بالتأكيد بالنظر في الأمر. أنا لستُ على دراية بـ PostgreSQL، لكنني آمل أن تنطبق نفس المبادئ التي تعلمتها من تشغيل MySQL لسنوات.
بالتأكيد. أشعر أنه بمجرد أن نتمكن من تحديد نوع التغييرات التي يجب إجراؤها، ستسير الأمور بسلاسة أكبر.
