إذًا، أنا أختبر Discourse كوجهة محتملة لمنتدانا الحالي وأحاول معرفة المتطلبات.
حاليًا، أقوم بتشغيل حاوية Discourse على عقدة Digitalocean مع 4 وحدات معالجة مركزية افتراضية و 8 جيجابايت من ذاكرة الوصول العشوائي.
مع تشغيل موقع vbulletin المستورد هنا بدون حركة مرور أو نشاط، يبدأ النظام في استخدام حوالي 75٪ من ذاكرة الوصول العشوائي البالغة 8 جيجابايت وخلال أيام قليلة تصل إلى 100٪ ثم يتوقف عن الاستجابة تمامًا.
هذا يربكني نظرًا لأن الحد الأدنى المطلوب يبدو أقل بكثير من هذا.
(لقد قمت بإعادة بناء الحاوية، وتحققت من مهام sidekiq ومسحتها، ولا يزال الاستخدام مرتفعًا)
هل لدى أي شخص أي نصائح أم يجب أن أبحث عن إعداد ذاكرة وصول عشوائي ضخم لمجرد الحفاظ على عمل المنتدى؟
قد يقوم النظام بإعادة خبز المشاركات وتغيير حجم الصور، مما قد يستهلك الكثير من الموارد حتى لو لم يكن لديك مستخدمون. يمكنك النظر إلى /sidekiq لمعرفة ما إذا كانت هناك مجموعة من المهام في قائمة الانتظار و/أو قيد التشغيل. أيضًا، قد يمنحك htop بعض التلميحات حول ما هو قيد التشغيل.
تم الاستيراد قبل حوالي 5 أسابيع، وتم المرور عبر 5 عمليات إعادة بناء للتطبيق منذ ذلك الحين، ويبدو أن هذا هو ما يحل مشكلة الذاكرة بمجرد أن يصبح الحاوية غير مستجيبة بنسبة 100% من الذاكرة.
تم مسح جميع المهام في sidekiq كما ذكر، ولا يزال الاستخدام عند 75%
رسم بياني للذاكرة منذ أن قمت بإعادة بناء الخادم بالأمس:
حسناً، سأجرب أمر redis.
كانت مشكلة عامل unicorn واحدة من المشكلات التي تحققت منها في وقت مبكر. لقد قمت بتغيير استخدام الذاكرة لـ db_shared_buffers وقمت أيضًا بتعيين عمال unicorn إلى 3.
يبدو أن إعداد عمال unicorn له تأثير ضئيل أو معدوم على عدد العمال الذين يعملون بالفعل.
من ملف app.yml الخاص بي
## كم عدد طلبات الويب المتزامنة التي يمكن دعمها؟ يعتمد على الذاكرة وأنوىة وحدة المعالجة المركزية.
## سيتم تعيينه تلقائيًا بواسطة bootstrap بناءً على وحدات المعالجة المركزية المكتشفة، أو يمكنك تجاوزها
UNICORN_WORKERS: 3
