وظيفة PostAlerter تعلق/تستهلك ذاكرة زائدة منذ فترة

خلل
1

منذ FEATURE: new watched_precedence_over_muted setting (#22252) · discourse/discourse@9cf981f · GitHub (على الأرجح!) ونحن نواجه امتلاء قوائم انتظار Sidekiq/نفاد الذاكرة مع وظائف PostAlert العالقة:

image
image2568×520 172 KB

image
image956×198 16.3 KB

بالنظر إلى أن هذا الالتزام قد شهد بالفعل تراجعًا مشابهًا (FIX: error when CategoryList tried to find relevant topics by lis2 · Pull Request #22339 · discourse/discourse · GitHub)، فإنه يثير الشكوك - سنحاول الآن الرجوع إلى التزام سابق للالتزام المذكور أعلاه وسنقدم تقريرًا بالنتائج.

إعجابَين (2)
2

الانتقال إلى الأسفل إلى 4f7f9ef87cbcd574144f657dd43b7e705d98ff8e حل بالفعل مشكلة عمال sidekiq الذين يعلقون في PostAlert ومخاوف نفاد الذاكرة (OOM): الوظائف القليلة لـ PostAlert التي يتم وضعها في قائمة الانتظار الآن تكتمل في غضون ثوانٍ، وليس دقائق.

إعجابَين (2)
3

Ping @kris.kotlarek

إعجاب واحد (1)
5

لقد رأيت للتو FIX: improve performance of post alerter job (#22378) · discourse/discourse@7a204e7 · GitHub يتم دفعه - سأجرب هذا لاحقًا إذا كان هذا يعني إصلاحًا لهذه المشكلة.

إعجابَين (2)
6

نعم، هذا سيحل المشكلة على الأرجح. لقد اختبرت هذا الحل على 3 منتديات، وكان الاستعلام الجديد أسرع دائمًا ولم يؤد إلى إبطاء الخوادم.
شكراً للإبلاغ عن هذه المشكلة، ويرجى إعلامي إذا كنت لا تزال تواجه مشاكل.

4 إعجابات
7

للأسف، حتى مع هذه التغييرات، لا نزال نرى وظائف PostAlert تستغرق وقتًا أطول بكثير من ذي قبل وتعلق عمال Sidekiq تمامًا أثناء المعالجة. :frowning:

(لدينا 10 ملايين+ صف مستخدم وبعض الفئات مكتومة افتراضيًا، لذا هناك الكثير من كتم الصوت!)

التراجع عن الالتزامات الثلاثة التي المسّت هذه المهمة مؤخرًا وإعادة تشغيل الحاوية، في هذه الأثناء، يجعل المهام تكتمل بشكل جيد.

3 إعجابات
8

شكراً لك، سألقي نظرة أخرى

9

لقد قمت للتو بدمج محاولة أخرى لتحسين أداء هذه المهمة:

لقد اختبرتها على عدد قليل من المثيلات وكانت جيدة، لكنها كانت أصغر من مثيلك.

إذا كانت لا تزال تفشل مع هذا الالتزام، هل يمكنك تزويدي بتقرير EXPLAIN ANALYSE؟ البرنامج النصي لتوليده:

topic = Topic.last
user_option_sql_fragment =
  if SiteSetting.watched_precedence_over_muted
    <<~SQL
    INTERSECT
    SELECT user_id FROM user_options WHERE user_options.watched_precedence_over_muted IS false
    SQL
  else
    <<~SQL
    EXCEPT
    SELECT user_id FROM user_options WHERE user_options.watched_precedence_over_muted IS true
    SQL
  end
user_ids_sql = <<~SQL
  (
    SELECT user_id FROM category_users WHERE category_id = #{topic.category_id.to_i} AND notification_level = #{CategoryUser.notification_levels[:muted]}
    UNION
    SELECT user_id FROM tag_users tu JOIN topic_tags tt ON tt.tag_id = tu.tag_id AND tt.topic_id = #{topic.id} WHERE tu.notification_level = #{TagUser.notification_levels[:muted]}
    EXCEPT
    SELECT user_id FROM topic_users tus WHERE tus.topic_id = #{topic.id} AND tus.notification_level = #{TopicUser.notification_levels[:watching]}
  )
  #{user_option_sql_fragment}
SQL
sql = User.where!("id IN (#{user_ids_sql})").to_sql

sql_with_index = <<SQL
EXPLAIN ANALYZE #{sql};
SQL
result = ActiveRecord::Base.connection.execute("#{sql_with_index}")
puts sql_with_index
result.each do |r|
  puts r.values
end

سيساعدني ذلك في العثور على فهرس مفقود أو معرفة أي جزء من هذا الاستعلام بطيء جدًا.

3 إعجابات
10

يبدو أن هذا التغيير قد أعاد وظائف PostAlert إلى مدتها الطبيعية ولم يعلق مثيلات Sidekiq. يا للروعة!

3 إعجابات
11

تم إغلاق هذا الموضوع تلقائيًا بعد 3 أيام. لم يعد يُسمح بالردود الجديدة.