لقد قمت بتثبيت نسخة “مستقرة” خاصة بي من discourse مع Postgres و Redis خارجيين.
للتوضيح حول البنية: في Azure، 1 LoadBalancer، 1 VM يستضيف حاوية Discourse مع مشاركة NFS للنسخ الاحتياطي والصور، 1 Postgres، 1 Redis.
لقد قمت بتخصيصها بشعار خاص بي، وإضافات discourse-calendar و discourse-news (وأشياء أخرى أيضاً ولكنها غير ذات صلة هنا).
بشكل عشوائي، لفترة مثل 30 دقيقة، تفشل بعض واجهات المستخدم:
يعود الشعار الرئيسي إلى الافتراضي
يعود الأيقونة المفضلة (Favicon) إلى الافتراضية
صفحة “upcoming-events” التي تم إنشاؤها بواسطة discourse-calendar تختفي (لا يوجد رابط واستجابة 404 عند الانتقال إليها عبر الرابط)
الشعار المخصص المعطى لـ discourse-news (مع رابط) يختفي
ثم تعود الأمور إلى طبيعتها.
ليس لدي أي شيء في السجلات حول هذا الأمر.
وحدة تحكم المتصفح الخاصة بي لا تعرض شيئاً.
شيء واحد يمكنني قوله هو أنه خلال هذه الفترة، يمكنني رؤية زيادة في حالات فشل ذاكرة التخزين المؤقت لـ Redis.
هل يمكن لأي شخص مساعدتي في استكشاف هذه المشكلة؟ أنا حتى لا أعرف أين يمكنني العثور على السجلات ذات الصلة…
@pfaffman لقد استخدمت التثبيت القياسي من وجهة نظري.
باستثناء أنني استخدمت الميزة المقدمة لاستخدام قاعدة بيانات خارجية و Redis.
لكنني أستخدم app.yaml و Docker build و run الموصوفة في التثبيت القياسي.
لقد فعلت ذلك لأتمكن من توفير التوفر العالي واستراتيجيات التحجيم المختلفة: مع نشر مستقل بالكامل، يمكنك فقط التحجيم عموديًا (زيادة حجم العقدة الخاصة بك) وليس التوفر العالي.
حسناً. يبدو أن هذا يجب أن يعمل. أفضل تخمين لدي هو أنك تقوم بتقليص عدد الأجهزة الافتراضية إلى الصفر وأن ما تراه هو الموقع المخزن مؤقتًا في متصفحك. أو بطريقة أخرى لا يتصل موازن التحميل بالمضيف. أو أن Discourse لا يحصل على عنوان IP الحقيقي ويقوم بتقييد المعدل (ولكن عادةً ما ترى خطأ).
لكن ميزات التوفر العالي لديك توفر توفرًا منخفضًا. ما لم تكن تنتقل من وجود عشرات المستخدمين في معظم الأوقات إلى الآلاف في أوقات أخرى (كما هو الحال بالنسبة لموقع رياضي) فإن التحجيم من المرجح أن يسبب المزيد من المشاكل أكثر من حلها.
لذا فإن أول شيء سأفعله هو التخلص من موازن التحميل ومعرفة ما إذا كان ذلك سيؤدي إلى حل المشكلة. ثم تقرر ما يجب فعله من هناك. إذا حدث ذلك مرة واحدة في الشهر فلن يكون من السهل تشخيصه.
