أواجه هذا باستمرار في السجلات - بقيم تتراوح بين ~ 100 ألف و ~ 1.35 مليون - ولكن القراءات القريبة من 100 ألف تبدو شائعة جدًا:
اتصال شبكة Redis الخاص بك ضعيف للغاية. كانت قراءات RTT الأخيرة [97069, 103986, 98459, 100762, 381617]، ومن المثالي أن تكون هذه أقل من 1000. تأكد من تشغيل Redis في نفس المنطقة المتاحة (AZ) أو مركز البيانات مثل Sidekiq. إذا كانت هذه القيم قريبة من 100,000، فهذا يعني أن عملية Sidekiq الخاصة بك قد تكون مشبعة بوحدة المعالجة المركزية؛ قلل من تزامنك و/أو راجع https://github.com/mperham/sidekiq/discussions/5039
يشير هذا إلى أن Redis قد لا يكون قادرًا على استخدام وحدة معالجة مركزية كافية؟ يبدو أن هناك متسعًا كبيرًا لوحدة المعالجة المركزية والذاكرة العشوائية على الخادم نفسه.
أيضًا: يستهلك Sidekiq الكثير من الذاكرة (باستخدام: 3570.19M) لـ 'www.example.com'، وإعادة التشغيل
هذا يستخدم تطبيق app.yml الكل في واحد مع Discourse stable 3.3.2.
للمتابعة بشأن هذا الأمر، أواجه نفس المشكلة مع Jobs::PostAlert:
مع هذه المهام التي غالبًا ما تستغرق ما يصل إلى 15 دقيقة عند استخدام 4 من عمال Sidekiq مع 5 (افتراضي) خيوط مع الاختبار الحالي. يبدو أن سرعة المهام في الثانية لـ Sidekiq تعتمد بشكل كبير على عدد هذه المهام التي يتم تشغيلها في وقت واحد وعدد الخيوط المتاحة للمهام الأخرى.
زيادة عدد عمال Sidekiq إلى 6 أو أعلى (5 خيوط) ستزيد من سرعة مسح قائمة الانتظار، ولكن قاعدة بيانات postgres ستتعطل بانتظام (أفترض بسبب تشغيل عدد كبير جدًا من مهام Jobs::PostAlert في وقت واحد).
هذا على الإصدار المستقر 3.3.2. يبدو أن التغييرات والإصلاحات من الموضوع المرتبط قد تم تنفيذها بالفعل في الإصدار 3.3.2، إذا لم أكن مخطئًا.
