لقد قمنا بإعادة جميع القيم المعدلة إلى الإعدادات الافتراضية وتحديث الإصدار إلى 2.6.0 بيتا4. هناك ألعاب مقررة يوم الخميس والجمعة، لذا سنحصل على تغطية اختبار جيدة في وقت لاحق من هذا الأسبوع.
@سام
للأسف، لا يحل الإصلاح المشكلة. كان لدينا لعبة نشطة إلى حد ما مع 600 رسالة. لاحظنا عدة تجمّدات خلال اختباراتنا الشخصية، وكذلك أعضاؤنا. ترتبط هذه التجمّدات بأحداث اللعبة، أي فترات الذروة في النشاط.
- كان استخدام وحدة المعالجة المركزية ضمن الحدود المسموح بها، حيث بلغ ذروته حوالي 60% ومتوسط الحمل حوالي 30%.
- المشكلة بالتأكيد من جانب العميل. عندما يتجمّد موضوع الدردشة، إذا انتقلت إلى الصفحة الرئيسية، سترى عدد المنشورات غير المقروءة. عند العودة إلى الموضوع، تصبح المنشورات مرئية.
ما لا يزال محيرًا لي، ولم يتم تغطيته في هذا الموضوع، هو ما الذي تغير منذ الإصدار 2.3، الذي لم يكن يعاني من هذه المشكلة؟
حدثت التحديثات الكبرى 2.4 و2.5 خلال موسمنا المغلق (الممدد بسبب جائحة كوفيد)، لذا لم يلاحظ أحد أي شيء، لكن التجمّد كان واضحًا فورًا في أول مباراة استعراضية للموسم الجديد.
هل هناك أي حيل معلمات يمكننا تجربتها غدًا؟ ستكون مباراة ديربي حامية الوطيس ومباراة خارج الأرض، لذا سيكون المجتمع في حالة نشطة للغاية.
في حالتنا، يبدو أن تعطيل إضافة ‘من متصل’ وإيقاف ملف تحديد المعدل (وقد قرأت أن هناك بعض التحسينات في النسخة التجريبية الأحدث) قد نجح معنا.
لدينا الآن أيضًا مباريات كرة قدم بين الحين والآخر يشارك فيها 300 مستخدم أو أكثر، حيث ينقر الجميع ويكتبون في نفس الموضوع في نفس الوقت، وقد بدا أن الأداء كان أفضل بكثير خلال المباراة الأخيرة.
هل تستخدم أحدث إصدار مع التصحيح الأخير؟
من فضلك، من فضلك، حدّث إلى “اختبارات ناجحة”. لقد حسّنت الكثير من الأشياء منذ النسخة التجريبية.
نعم، أحدث إصدار تجريبي (أي خلال آخر 48 ساعة).
تم التحديث. ستتبع التقرير.
@سام
للأسف، لا يزال الأمر غير مجدٍ. بالتأكيد، كانت اللعبة شديدة الحماس مع 950 رسالة. كنت أراقب GAnalytics، وكان هناك حوالي 250 شخصًا يراقبون، ونشر 119 منهم. لوحظت عدة تجمّدات، كما من قبل. عاد حافلة الرسائل ببعض أخطاء 429، مع رسائل مثل “لقد قمت بهذا الإجراء عددًا كبيرًا جدًا من المرات، يرجى الانتظار X دقائق”.
بلغ حمل وحدة المعالجة المركزية ذروته عند حوالي 70%، ولم يكن هناك أي انتظار فعلي (wa). لذا، رغم ارتفاع النشاط، لا يزال غيرنا قادرين على تقديم ما يمكن للأجهزة أن توفره.
هل يمكنك الإجابة على السؤال الذي أثار حيرتي: ما الذي تم تنفيذه بعد الإصدار 2.3 والذي يسبب هذه المشكلة، وما الذي يُفترض أن يضيفه إلى الطاولة؟
التنفيذ هو نفسه إلى حد كبير كما كان دائمًا، باستثناء أننا أضفنا حدودًا عامة لمعدل استخدام التطبيق يمكن تكوينها. يمكنك رفعها إذا أردت، لكن ذلك قد يتسبب في انهيار كامل؛ لا أدري.
لا أفهم ما تقصده بـ"التجمّد". إذا أصبحت الأمور مزدحمة الآن، سيتوقف التحديث، لكن الفرق هو أنك لن تحتاج إلى تحديث المتصفح لإصلاح الصفحة؛ سيعود العمل طبيعيًا بمجرد توفر سعة على الخادم.
هناك غموض قليل هنا: هل يلاحظ مستخدموك عدم أي تحسن بعد تغييراتي؟
هل يحتوي خادمك على ذاكرة عشوائية (RAM) حرة كثيرة؟ إذا كان الأمر كذلك، أضف عمال Unicorn.
ما هي القيمة المحددة في معامل db_shared_buffers؟ لقد واجهنا الكثير من السلوك “غير المستقر” في البداية (بعض المواضيع تستهلك موارد كثيرة، خاصة عند المشاركة المكثفة) مع مجرد النسبة الموصى بها وهي 25% من إجمالي الذاكرة العشوائية (RAM). وعندما قمنا بزيادتها إلى 16 جيجابايت (من أصل 32 جيجابايت)، اختفى كل هذا عدم الاستقرار… وحصلنا مؤخرًا على أداء أفضل مع أحدث التغييرات.
حسنًا، هذه الظاهرة صعبة المراقبة في بيئة الإنتاج (محادثات الألعاب)، لأن كل لعبة تختلف عن الأخرى — سواء من حيث عدد الأحداث الحرجة، أو الخصم، أو الشحنة العاطفية، وهكذا.
المشكلة من منظورنا هي أن القدرة القصوى على الخدمة قد انخفضت منذ الإصدار 2.3. هذا هو المفتاح هنا. كل خادم له حدوده، لكننا الآن نحصل من خوادمنا على أقل مما كنا نحصل عليه في مارس عند تشغيل الإصدار 2.3. بناءً على مراقبة تقريبية للواجهة الخلفية، لا يستطيع الخادم الوصول إلى 100% من الحمل أو السعة.
ما يراه المستخدم النهائي هو أن تدفق المحادثة يتوقف ببساطة، دون أي مؤشر في واجهة المستخدم يوضح ما يحدث. وهذا يسبب الارتباك.
أنا متأكد إلى حد كبير أن التغييرات في الاختبارات التي تم اجتيازها قد حسّنت الوضع، لكن الأداء أو الحد الأقصى للإخراج لا يزال أقل بشكل ملحوظ مقارنة بالإصدار 2.3.
لدينا خادم VPS يحتوي على 6 أنوية سريعة وذاكرة عشوائية (RAM) سعتها 16 جيجابايت. عدد عمليات Unicorn هو 12، وإعدادات ذاكرة التخزين المؤقت المتعلقة بذاكرة العشوائية مضبوطة على الإعدادات الافتراضية.
أعتقد أن أفضل خطوة تالية هنا هي إعداد مراقبة تاريخية لنظامك حتى نتمكن من تحديد مكان الاختناق، لأننا قد استنتجنا أن المشكلة ليست في وقت وحدة المعالجة المركزية. من الممكن دائمًا أن تكون قد وصلت إلى الحد الأقصى لسعة اتصالك بالشبكة!
بالإضافة إلى مقاييس الخادم التقليدية الأخرى مثل node-exporter.
إذا كان هذا هو الحال وتريد زيادة الضغط عليه.
-
يمكنك تقليل حدود المعدل، مما سيتيح للمستخدمين التفاعل بشكل أكثر عدوانية مع Discourse. على وجه التحديد، يمكنك مضاعفة
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTEوDISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS. -
يمكنك محاولة إضافة المزيد من عمال Unicorn.
هذا متوقع مؤقتًا أثناء التحميل الزائد، لكن الأمور يجب أن تتعافى تلقائيًا بمجرد انخفاض الحمل.
تخميني هنا هو أن كل هذا يتعلق بحدود المعدل فقط؛ فحدود المعدل جديدة وُضعت لحماية الخادم، ويبدو أن خادمك محمي بالتصميم نفسه.
لقد جربنا لعبة مع…
DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.3
DISCOURSE_MAX_REQS_PER_IP_MODE: none…وعندما بدأت المشاعر في التزايد في الفترة الثالثة، ساءت الأمور. وصلنا إلى حدود خوادمنا، وتم طرد المستخدمين باستمرار إلى وضع تسجيل الخروج، كما توقف دردشة اللعبة عن العمل.
كانت قصة نجاح رائعة استمرت 4 سنوات، لكننا الآن في موقف صعب للغاية. الانتقال إلى المستوى التالي من سعة VPS سيضعنا في فئة الأسعار التي تبلغ حوالي 160 يورو شهريًا، وهو تحدٍ لموقع هواية. نحن لا نتحدث حتى عن أحجام مستخدمين ضخمة - حيث نشر 116 شخصًا أكثر من 800 رسالة خلال اللعبة.
أيضًا، أيديولوجية “لا تفعل الدردشات” غير مناسبة. فلو لم تكن موجودة، لانتشرت منشورات ردود الفعل العاطفية في جميع أنحاء المواضيع الأكثر “جدية”. فهي أداة مهمة لتوجيه الشحنة العاطفية للوضع المباشر إلى موضوع واحد، مما يحافظ على نظافة المواضيع التحليلية أكثر.
حقلُي هو منتدى كرة قدم، وقد واجهتُ تحديات مماثلة.
في الأساس، ما وجدته هو أن المشكلة قابلة للتوسع.
بدأت المشاكل بالنسبة لي على مستويات مختلفة.
Digital Ocean
1 معالج و1 جيجابايت = 30-40 مستخدمًا في وضع الدردشة
2 معالجات و2 جيجابايت = 70-80 مستخدمًا في وضع الدردشة
4 معالجات و8 جيجابايت = مناسب لـ 120 مستخدمًا و1000 منشور خلال ساعتين. لم أصل إلى الحد الأقصى.
أنا أحاول مستويات الترقية المختلفة مع Hetzner (لموقع المرآة) لأنها أرخص، لكن الأمر لم يسر بسلاسة كما كنت أتمنى.
تجربتي حتى الآن هي:
3 معالجات (شريحة CPX 21 من AMD) و4 جيجابايت = صعوبة مع 20 مستخدمًا
2 معالجات (Intel) و8 جيجابايت = لا توجد مشكلة مع 20 مستخدمًا.
على وشك الاختبار مع 80 إلى 100 مستخدم متزامن تحت ظروف المباراة.
عندما نظرت إلى استخدام المعالج مع Digital Ocean، حتى تحت الضغط بدا استخدام المعالج منخفضًا نسبيًا (<50%) في جميع الأوقات وعلى جميع المستويات.
عندما نظرت إلى استخدام المعالج لـ Hetzner لشريحة AMD، كنت أرى متوسط استخدام المعالج يبلغ حوالي 60%، لكن كل دقيقة أو نحو ذلك كانت هناك قفزة قصيرة تصل إلى 300% من استخدام المعالج. لم يحدث هذا مع شريحة Intel.
ما يعنيه هذا، لا أعرف. أشك في أن مراقبة المعالج أفضل مع Hetzner (تسجيل القفزات القصيرة). لكن بشكل عام، يبدو استخدام المعالج متوازنًا جيدًا. يبدو أن Digital Ocean يتعامل بشكل أفضل مع القفزات من الناحية الظاهرية، لكن يجب أن أكون لدي معلومات أكثر عن Hetzner بعد عطلة نهاية الأسبوع هذه.
يجب أن أضيف أيضًا أنه مع اختبار Hetzner، لم يُحدث إضافة plugin ‘whose online’ أي فرق.
لكن إضافة discourse quick messages بدت ضارة.
المباراة القادمة مقررة غدًا. لقد أزلنا حلولنا الخاصة ونجرب هذه الإعدادات.
أيضًا، كخيار بعيد الاحتمال تمامًا، قمت بزيادة db_shared_buffers من 4 جيجابايت (25%) إلى 6 جيجابايت (37.5%). كما قمت بإلغاء التعليق عن سطر db_work_mem البالغ 40 ميجابايت من ملف app.yml (وهو خيار موثق بشكل غامض للغاية، مع أنه يُقدّم للمسؤول على أنه نوع من فرص التحسين).
لم أعد أتوقع العثور على حل للمشكلة، بل فقط تحسين إدارة الأضرار — مجموعة من المعاملات يكون لها أقل تأثير سلبي على تجربة المستخدم النهائي. وفي الوقت نفسه، سيتعين عليّ استكشاف إمكانيات زيادة موارد الاستضافة لدينا بشكل أكبر.
سؤال لـ @sam والمطورين الآخرين.
كيف يؤثر النمو المستمر لحجم قاعدة البيانات على حالة الاستخدام هذه، حيث يضغط المستخدمون على موضوع واحد لعدة ساعات؟
لقد راجعت نشاط الدردشة التاريخية في الألعاب ولاحظت أننا كانت لدينا ألعاب بإحصائيات ضخمة في عام 2017، عندما كان خادمنا يملك جزءًا بسيطًا من الموارد التي نملكها اليوم. كانت لدينا ألعاب حيث وصل عدد المنشورات إلى 1600 رسالة من قبل 165 مستخدمًا، ولم يكن هناك أي شكاوى بشأن الأداء. الآن لا يمكننا خدمة نصف ذلك العدد، رغم أن الخادم لدينا أقوى بكثير.
ربما يمكنك محاولة زيادته إلى 80 ميجابايت. ربما بدلًا من التغيير الآخر.
هذا أحد النقاط التي نعمل عليها بنشاط طوال الوقت.
عندما كان Discourse جديدًا، كانت جميع المواقع تقريبًا تحتوي على قاعدة بيانات جديدة تمامًا، مما سمح لقاعدة البيانات بالاحتواء في الذاكرة بسهولة. الآن، بعد بضع سنوات، تحتوي بعض المواقع على قواعد بيانات تتجاوز 100 جيجابايت، بينما لا تصل أحجام ذاكرة الوصول العشوائي (RAM) حتى إلى عُشر ذلك.
من بين التحديثات القادمة خلال الأسابيع القليلة القادمة، ترقية PostgreSQL 13 التي ستقلل حجم أكبر كائن إلى النصف.
إلى جانب ذلك، فإن الخطوة الأولى في تشخيص مشكلات الأداء هي جمع البيانات باستخدام إضافة Prometheus exporter لـ Discourse حتى لا نعمل في الظلام.