بطء التحميل في private-message-topic-tracking-state.json

ساهم خلل
1

منذ الإصدار 2.8.0.beta5، يستغرق تحميل صندوق الوارد الخاص بالرسائل الجماعية أكثر من 4 ثوانٍ، حيث يُستهلك معظم الوقت (2-3 ثوانٍ) في استعلام SQL الضخم في ملف private-message-topic-tracking-state.json.

لدينا حوالي 800 ألف موضوع، و3.8 مليون مستخدم، وربما رسم بياني كبير للرسائل الخاصة غير المقروءة للمستخدمين، لكنني لا ألاحظ أي شيء ملحوظ في تحليل الاستعلام (ربما أنا مجرد غير خبير في قراءته).

كان كل شيء على ما يرام قبل الإصدار beta5، أما الآن فإن صناديق الوارد الخاصة بالرسائل أصبحت صعبة ومزعجة جدًا للمتابعة.

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

هه، هذا يستغرق في المتوسط 200 مللي ثانية هنا على Meta بالنسبة لنا.

ومع ذلك، فإن الأمر مشبوه جدًا لأن الانتقال إلى الرسائل في ملفك الشخصي الآن يُجري 3 عمليات جلب منفصلة، وأن العملية التي أشرت إليها تُرجع ملف JSON بحجم 92 كيلوبايت يحتوي على 900 كائن بالنسبة لي :scream:

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

يبدو أنه أيضًا يُبطل حالة miniprofiler في منتصف الطريق، لذا لا يمكنني حتى التقاط استعلام SQL لشرحه بشكل صحيح باستخدام EXPLAIN.

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

نعم، يبدو أن انتقال المسار لا يعمل بشكل طبيعي.

بالمناسبة، قمت باستخراج خطة من هنا: ieWq | explain.depesz.com

3 إعجابات
9

يجب أن يؤدي هذا الإصلاح إلى خفضه إلى حوالي 13 مللي ثانية.

لاحظ أن عدد العناصر غير المقروءة لديك كلما زاد، كلما أصبحت الاستعلامات أكثر تكلفة.

@سام هناك شيء آخر أحتاج إلى إصلاحه وهو أن تجاهل العناصر غير المقروءة لا يقوم بتحديث تحسينات first_unread_at التي نمتلكها للمواضيع العادية والرسائل الخاصة.

4 إعجابات
10

1.73 ثانية بعد اختيار هذا التغيير وإعادة تشغيل يونيكورن، لكن وقت عدم القراءة لي ولمجموعاتي متأخر جدًا على الأرجح (لدي فقط 59 رسالة جديدة و 4 غير مقروءة مرئية لهذا البريد الوارد - هل هذا المسار خاص بكل مستخدم؟ ومع ذلك، حتى لـ ‘جميع الرسائل’ لدي 61 رسالة جديدة و 7 غير مقروءة)

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

هل يرتبط وقت عدم القراءة بعدد الرسائل غير المقروءة في صناديق الوارد الخاصة بك؟

إعجاب واحد (1)
12 
discourse=# select first_unread_pm_at from group_users where user_id = 2334 order by first_unread_pm_at asc;
     first_unread_pm_at
----------------------------
 2021-09-03 06:54:13.493514
 2021-09-03 07:05:33.138986
 2021-09-03 07:05:33.138986
 2021-09-03 07:05:33.138986
 2021-09-03 07:05:33.138986
 2021-09-03 07:05:33.138986
 2021-09-03 07:05:33.138986
 2021-09-03 07:05:33.138986
 2021-09-03 07:05:33.138986
 2021-09-03 07:05:33.138986
 2021-09-03 07:05:33.138986
 2021-09-03 07:05:33.138986
 2021-09-03 07:05:33.138986
 2021-09-03 07:05:33.138986
 2021-09-03 07:05:33.138986
 2021-09-03 07:05:33.138986
 2021-09-03 07:05:33.138986
(17 rows)

discourse=# select first_unread_pm_at from user_stats where user_id = 2334;
     first_unread_pm_at
----------------------------
 2021-09-03 07:05:00.565522
(1 row)

من الغريب أن النطاق ليس مرتفعًا لدرجة كبيرة، مما يعني أن شرطًا آخر هو ما يسبب البطء (على الرغم من أنه، غريبًا، أصبح أسرع الآن ليصل إلى 700 مللي ثانية بعد تجاهل بعض الرسائل غير المقروءة، وهو أمر مقبول؛ لست متأكدًا مما كان عليه نطاق first_unread_pm_at الخاص بي من قبل، ربما بضعة أسابيع؟).

هل توجد طريقة للحصول على الاستعلام من Miniprofiler بعد تحديثه وإزالة جميع الطلبات القديمة في صفحة الرسائل حتى أتمكن من تشغيل EXPLAIN؟

13

هذا غريب بالفعل، لكنني لا أستطيع إعادة إنتاجه في بيئة التطوير. سأخصص بعض الوقت للنظر في هذا الأسبوع القادم.

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

تم إصلاحه في

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

شكرًا لك! سأحاول تذكر التحقق مرة أخرى في نافذة إعادة البناء/إعادة التشغيل القادمة.

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

لدينا نتيجة خطة استعلام / EXPLAIN ANALYZE (تصل إلى 1.3 ثانية :confused:): CvUX | explain.depesz.com

بعد تشغيل reindex index concurrently index_topics_on_timestamps_private; أصبحت العملية أسرع قليلاً (768 مللي ثانية)، لذا قد يكون هذا مجرد أثر لعدد كبير من الرسائل الخاصة السابقة (كان بوت السرد، قبل التنظيف، يلوث جدول الرسائل الخاصة بشكل كبير!)… رغم أنها لا تزال بطيئة على نفس الفهرس.

17

هل يمكنك تشغيل Topic.where(archetype: Archetype.private_message).count في وحدة تحكم Rails؟

بالمناسبة، يتم تنفيذ الاستعلام الآن بشكل غير متزامن، لذا لن يعيق تحميل صفحة الرسائل أو رسالة خاصة.

18 
[1] pry(main)> Topic.where(archetype: Archetype.private_message).count
=> 543855

يمكن أن يكون الوضع أسوأ بكثير، لقد قمنا مؤخرًا بحذف جميع مواضيع الروبوتات السردية المتبقية. :sweat_smile: لا يزال العدد أكبر مما توقعت!

آه، تساءلت لماذا يظهر هذا الاستعلام في miniprofiler فقط بعد مرور بعض الوقت. هذا جيد!

19

قمنا مؤخرًا بتحديث النظام مرة أخرى لدعم هذه الميزة FEATURE: New and Unread messages for user personal messages. by tgxworld · Pull Request #13603 · discourse/discourse · GitHub (أي أننا حاليًا على الإصدار 2.8.0beta6)

يبدو أن عملية جلب جميع الرسائل الخاصة للمستخدم، والتي تؤدي في النهاية إلى نقطة ما في FEATURE: New and Unread messages for user personal messages. by tgxworld · Pull Request #13603 · discourse/discourse · GitHub تنتج استعلامًا كهذا → 

SELECT "topics"."id", "topics"."title", "topics"."last_posted_at", "topics"."created_at", "topics"."updated_at", "topics"."views", "topics"."posts_count", "topics"."user_id", "topics"."last_post_user_id", "topics"."reply_count", "topics"."featured_user1_id", "topics"."featured_user2_id", "topics"."featured_user3_id", "topics"."deleted_at", "topics"."highest_post_number", "topics"."like_count", "topics"."incoming_link_count", "topics"."category_id", "topics"."visible", "topics"."moderator_posts_count", "topics"."closed", "topics"."archived", "topics"."bumped_at", "topics"."has_summary", "topics"."archetype", "topics"."featured_user4_id", "topics"."notify_moderators_count", "topics"."spam_count", "topics"."pinned_at", "topics"."score", "topics"."percent_rank", "topics"."subtype", "topics"."slug", "topics"."deleted_by_id", "topics"."participant_count", "topics"."word_count", "topics"."excerpt", "topics"."pinned_globally", "topics"."pinned_until", "topics"."fancy_title", "topics"."highest_staff_post_number", "topics"."featured_link", "topics"."reviewable_score", "topics"."image_upload_id", "topics"."slow_mode_seconds" FROM "topics" LEFT OUTER JOIN topic_users AS tu ON (topics.id = tu.topic_id AND tu.user_id = 1234) LEFT JOIN group_archived_messages gm ON gm.topic_id = topics.id
LEFT JOIN user_archived_messages um
ON um.user_id = 1234
AND um.topic_id = topics.id WHERE "topics"."deleted_at" IS NULL AND (topics.id IN (
SELECT topic_id
FROM topic_allowed_users
WHERE user_id = 1234
 UNION ALL
SELECT topic_id FROM topic_allowed_groups
 WHERE group_id IN (
SELECT group_id FROM group_users WHERE user_id = 1234
  )
)) AND "topics"."archetype" = 'private_message' AND "topics"."visible" = TRUE AND (um.user_id IS NULL AND gm.topic_id IS NULL) ORDER BY topics.bumped_at DESC LIMIT 30;

يؤدي هذا في الأساس إلى تعليق خادم RDS الخاص بنا. أعتقد أن أحد أعضاء فريقنا اقترح أن نقوم بتصفية البيانات باستخدام أي فهارس متوفرة لدينا قبل إجراء عمليات الربط (JOIN). هذا الاستعلام يعمل في أقل من 100 مللي ثانية.

SELECT "topics_filter"."id", "topics_filter"."title", "topics_filter"."last_posted_at", "topics_filter"."created_at", "topics_filter"."updated_at",
"topics_filter"."views", "topics_filter"."posts_count", "topics_filter"."user_id", "topics_filter"."last_post_user_id", "topics_filter"."reply_count", "topics_filter"."featured_user1_id",
"topics_filter"."featured_user2_id", "topics_filter"."featured_user3_id", "topics_filter"."deleted_at", "topics_filter"."highest_post_number", "topics_filter"."like_count",
"topics_filter"."incoming_link_count", "topics_filter"."category_id", "topics_filter"."visible", "topics_filter"."moderator_posts_count", "topics_filter"."closed",
"topics_filter"."archived", "topics_filter"."bumped_at", "topics_filter"."has_summary", "topics_filter"."archetype", "topics_filter"."featured_user4_id", "topics_filter"."notify_moderators_count",
"topics_filter"."spam_count", "topics_filter"."pinned_at", "topics_filter"."score", "topics_filter"."percent_rank", "topics_filter"."subtype", "topics_filter"."slug",
"topics_filter"."deleted_by_id", "topics_filter"."participant_count", "topics_filter"."word_count", "topics_filter"."excerpt", "topics_filter"."pinned_globally",
"topics_filter"."pinned_until", "topics_filter"."fancy_title", "topics_filter"."highest_staff_post_number", "topics_filter"."featured_link", "topics_filter"."reviewable_score",
"topics_filter"."image_upload_id", "topics_filter"."slow_mode_seconds"
FROM (select * from "topics"
      where "topics"."deleted_at" IS NULL
      and (topics.id IN ( SELECT topic_id FROM topic_allowed_users WHERE user_id = 1234
                          UNION ALL
                          SELECT topic_id FROM topic_allowed_groups  WHERE group_id IN ( SELECT group_id FROM group_users WHERE user_id = 1234 )
                         ))
      AND "topics"."archetype" = 'private_message'
      AND "topics"."visible" = TRUE
      )   as topics_filter
LEFT OUTER JOIN (select topic_id from topic_users where user_id = 1234) AS tu ON (topics_filter.id = tu.topic_id )
LEFT JOIN group_archived_messages gm ON gm.topic_id = topics_filter.id
LEFT JOIN ( select user_id, topic_id from user_archived_messages where user_id = 1234) um
ON um.topic_id = topics_filter.id
WHERE (um.user_id IS NULL AND gm.topic_id IS NULL) ORDER BY topics_filter.bumped_at DESC LIMIT 30;

كمرجع، يحتوي جدول topics على أكثر من 10 ملايين صف، وجدول topic_users يحتوي على أكثر من 50 مليون صف.

هل من الممكن إعادة هيكلة الاستعلام لمعالجة هذه المشاكل بطريقة ما؟

تعديل:

للتوضيح فقط، عندما نفحص استعلاماتنا التي تستغرق وقتًا أطول (أكثر من دقيقتين أو حتى 5 دقائق)، فإن هذه هي الاستعلامات الوحيدة التي تظهر. مع أحدث تغيير، كانت وحدة معالجة مركزية (CPU) الخاصة بـ Postgres لدينا تعمل باستمرار عند 99%. عند إنهاء هذه الاستعلامات، نلاحظ أن استخدام وحدة المعالجة المركزية يعود إلى الوضع الطبيعي.

3 إعجابات
20

@tgxworld آسف على الإشارة إليك مباشرة، ولكن بما أنك الكاتب، كنت أتساءل عما إذا كان لديك أي اقتراحات أو ملاحظات.

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

كما أتذكر، كان @sam يصفها دائمًا بأنها ميزة محفوفة بالمخاطر وخطيرة. لن يفاجئني حدوث انتكاسات كبيرة هنا.

22

وجدنا هذا الموضوع الخاص بالخطأ بعد نشر هذا: Slow loading on private-message-topic-tracking-state.json - #9 by tgxworld

يبدو أن هناك التزامًا (commit) بعد ذلك المصنّف بـ v2.8.0beta6 والذي قد يعالج بعضًا من مشكلة الأداء هذه. سنحاول إعادة البناء مع استهداف مرجع ذلك الالتزام المحدد لمعرفة ما إذا كان سيخفف من المشكلة.

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

ما هو نوع مثيل RDS الحالي لديك وما هو حجم قاعدة البيانات الإجمالي؟

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

db.m5.2xlarge

حوالي 250 جيجابايت من حيث استخدام القرص.

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