لقد كنا نواجه مؤخرًا حملًا زائدًا على وحدة المعالجة المركزية.
لقد تمكنا من تحديد المشكلة في استعلام واحد يستمر في العمل بشكل متزامن لساعات (انظر أدناه).
المهمة قيد التشغيل هي postmaster - بمجرد قتلها جميعًا، يتم تقليل وحدة المعالجة المركزية حتى يتم إعادة بنائها كل خمس دقائق.
SELECT “users”.“id”, ARRAY_AGG(ARRAY [uccm.id, c_msg.id]) AS memberships_with_unread_messages
FROM “users”
INNER JOIN “user_options” ON “user_options”.“user_id” = “users”.“id”
INNER JOIN user_chat_channel_memberships uccm ON uccm.user_id = users.id
INNER JOIN chat_channels cc ON cc.id = uccm.chat_channel_id
INNER JOIN chat_messages c_msg ON c_msg.chat_channel_id = uccm.chat_channel_id
LEFT OUTER JOIN chat_mentions c_mentions ON c_mentions.chat_message_id = c_msg.id
WHERE “user_options”.“chat_enabled” = TRUE
AND “user_options”.“chat_email_frequency” = 1
AND (users.last_seen_at < ‘2023 - 11 - 15 09:54:26.931723’)
AND (c_msg.deleted_at IS NULL AND c_msg.user_id <> users.id)
AND (c_msg.created_at > ‘2023 - 11 - 08 10:09:26.931848’)
AND ((uccm.last_read_message_id IS NULL OR c_msg.id > uccm.last_read_message_id) AND
(uccm.last_unread_mention_when_emailed_id IS NULL OR c_msg.id > uccm.last_unread_mention_when_emailed_id) AND
(uccm.user_id = c_mentions.user_id AND uccm.following IS true AND
cc.chatable_type = ‘Category’
هل يمكن لأحد المساعدة أو اقتراح حل؟
مزيد من المعلومات:
يعمل على الإصدار 3.2.0.beta4-dev، ولكن هذا يحدث منذ بضعة أشهر على الأقل
لقد عملت على استعلام مشابه آخر وكان هذا الإصلاح خاصًا بهذا الاستعلام، لذلك من المحتمل ألا يساعد هنا. ومع ذلك، يجدر التحديث إلى أحدث إصدار، فقد تكون هناك تحسينات أخرى.
كان لدى العميل تفعيل إشارات @all في الدردشة، مع قناتين تضم كل منهما 16 ألف مستخدم. كان ذلك ممتعًا!
بعد 19 إشارة للجميع، قاموا بإيقافها بسرعة مرة أخرى. بعد 12 ساعة، كان نظامهم (القوي) لا يزال يعاني من حمل وحدة معالجة مركزية مرتفع.
تم حل المشكلة عن طريق مسح 320 ألف سجل مسيء من جدول الإشارات
delete from chat_mentions
where chat_message_id in (
(select chat_message_id
from chat_mentions
group by chat_message_id having count(*) > 100)
);
لكننا كنا لا نزال في حيرة من أمرنا لماذا تسبب هذا في الكثير من المشاكل.
كان لا يزال هناك عدد من الاستعلامات من هذا الاستعلام قيد التشغيل.
نظرًا لأن الصفوف كانت قد اختفت بالفعل، لم يعطِ شرح الاستعلام نتائج جيدة، ولكن من الواضح أنه كان يقوم بعمل شاق. جميع الفهارس في مكانها.
لقد رأينا أيضًا رسائل الدردشة تختفي لبضع دقائق قبل أن تظهر مرة أخرى.
بشكل عام، أعتقد أن هناك الكثير مما يمكن تحسينه في الدردشة، على الرغم من أنني أحب الاتجاه الذي تسير فيه تمامًا. شاغلي الرئيسي هو كيف يمكن للدردشة أن تسبب حملًا زائدًا لا يتوقف. لقد قمنا بتعطيل القدرة على الإشارة، ولم ينجح ذلك أيضًا.
مرحباً @sok777 ، شكراً للمتابعة — لدينا عدد قليل من المهندسين يبحثون في هذا الأمر، وسنتواصل معك هنا بمجرد أن يكون لدينا تحديث لك. نقدر صبرك في هذه الأثناء!
كان لدينا رسالة واحدة مع @all قمنا بحذفها. ومع ذلك، لم يحل هذا المشكلة. يستمر الاستعلام في العودة كل 5 دقائق ويستغرق وقتًا طويلاً لدرجة وجود طابور من الاستعلامات الأخرى.
بمجرد تعطيل الدردشة، انخفض تحميل وحدة المعالجة المركزية إلى 15٪. جنون
السبب الوحيد الذي يجعل هذا الاستعلام يستغرق وقتًا طويلاً هو وجود العديد من الإدخالات في جدول chat_mentions. هل جربت الاستعلام العام الذي نشرته؟ ربما ليس @all ولكن تم ذكر مجموعة كبيرة أخرى.
يقوم الاستعلام الإشكالي بالمسح لجميع الإشارات من الدردشات في الأيام السبعة الماضية.
يجب عليك أيضًا إنهاء جميع المثيلات الحالية للاستعلام.
نعم لقد قتلناهم لكنهم يستمرون في العودة.
لقد تحققنا من جميع الإشارات فوق 100 ولم يكن لدينا أي منها. لست متأكدًا من سبب حدوث ذلك.
يبدو لي أن هناك مشكلة أساسية في الاستعلام ولكن ربما أكون مخطئًا.
@sok777 سأحتاج إلى القليل من مساعدتك في هذا. أود إلقاء نظرة على خطة الاستعلام التي يستخدمها Postrges على موقعك. هل يمكنك من فضلك تشغيل هذا على قاعدة بياناتك ومشاركة النتائج:
EXPLAIN VERBOSE SELECT "users"."id", ARRAY_AGG(ARRAY [uccm.id, c_msg.id]) AS memberships_with_unread_messages
FROM "users"
INNER JOIN "user_options" ON "user_options"."user_id" = "users"."id"
INNER JOIN "group_users" ON "group_users"."user_id" = "users"."id"
INNER JOIN "groups" ON "groups"."id" = "group_users"."group_id"
INNER JOIN user_chat_channel_memberships uccm ON uccm.user_id = users.id
INNER JOIN chat_channels cc ON cc.id = uccm.chat_channel_id
INNER JOIN chat_messages c_msg ON c_msg.chat_channel_id = uccm.chat_channel_id
LEFT OUTER JOIN chat_mentions c_mentions ON c_mentions.chat_message_id = c_msg.id
WHERE "user_options"."chat_enabled" = TRUE
AND "user_options"."chat_email_frequency" = 1
AND (users.last_seen_at < '2023-11-27 08:00:00.0000000')
AND (c_msg.deleted_at IS NULL AND c_msg.user_id <> users.id)
AND (c_msg.created_at > '2023-11-20 08:00:00.0000000')
AND ((uccm.last_read_message_id IS NULL OR c_msg.id > uccm.last_read_message_id) AND
(uccm.last_unread_mention_when_emailed_id IS NULL OR c_msg.id > uccm.last_unread_mention_when_emailed_id) AND
(
(uccm.user_id = c_mentions.user_id AND uccm.following IS true AND cc.chatable_type = 'Category') OR
(cc.chatable_type = 'DirectMessage')
)
)
GROUP BY users.id, uccm.user_id
ORDER BY "users"."id" ASC
LIMIT 1000;
