Недавно мы удалили ВСЕ упоминания, и с тех пор загрузка процессора снизилась до 15–20%, что довольно хорошо, но из-за этого запрос выше не вернёт результатов (или вернёт лишь несколько, так как мы их удалили).
1 лайк
Приведенный выше запрос в любом случае должен возвращать результаты, так как он начинается с EXPLAIN VERBOSE, что означает возврат плана выполнения. Когда у вас будет время, не могли бы вы скопировать и вставить точный запрос из моего сообщения, выполнить его и поделиться результатами?
Limit (cost=123.37..22204.48 rows=1000 width=40)
Вывод: users.id, (array_agg(ARRAY[uccm.id, c_msg.id])), uccm.user_id
-> GroupAggregate (cost=123.37..339399.59 rows=15365 width=40)
Вывод: users.id, array_agg(ARRAY[uccm.id, c_msg.id]), uccm.user_id
Ключ группировки: users.id, uccm.user_id
-> Nested Loop (cost=123.37..336077.65 rows=417317 width=24)
Вывод: users.id, uccm.user_id, uccm.id, c_msg.id
Уникальность внутреннего соединения: true
-> Merge Join (cost=123.23..271629.01 rows=417317 width=28)
Вывод: users.id, group_users.group_id, uccm.id, uccm.user_id, c_msg.id
Условие слияния: (user_options.user_id = group_users.user_id)
-> Nested Loop Left Join (cost=121.72..221430.16 rows=132835 width=28)
Вывод: users.id, user_options.user_id, uccm.id, uccm.user_id, c_msg.id
Фильтр: (((uccm.user_id = c_mentions.user_id) AND (uccm.following IS TRUE) AND ((cc.chatable_type)::text = 'Category'::text)) OR ((cc.chatable_type)::text = 'DirectMessage'::text))
-> Nested Loop (cost=121.32..149930.76 rows=132967 width=42)
Вывод: users.id, user_options.user_id, uccm.id, uccm.user_id, uccm.following, cc.chatable_type, c_msg.id
Условие соединения: ((c_msg.user_id <> users.id) AND (cc.id = c_msg.chat_channel_id))
-> Nested Loop (cost=120.91..57868.92 rows=21066 width=54)
Вывод: users.id, user_options.user_id, uccm.id, uccm.user_id, uccm.chat_channel_id, uccm.last_read_message_id, uccm.last_unread_mention_when_emailed_id, uccm.following, cc.id, cc.chatable_type
Уникальность внутреннего соединения: true
-> Nested Loop (cost=120.63..51231.73 rows=21066 width=33)
Вывод: users.id, user_options.user_id, uccm.id, uccm.user_id, uccm.chat_channel_id, uccm.last_read_message_id, uccm.last_unread_mention_when_emailed_id, uccm.following
Уникальность внутреннего соединения: true
-> Merge Join (cost=120.21..36835.88 rows=21096 width=29)
Вывод: users.id, uccm.id, uccm.user_id, uccm.chat_channel_id, uccm.last_read_message_id, uccm.last_unread_mention_when_emailed_id, uccm.following
Уникальность внутреннего соединения: true
Условие слияния: (uccm.user_id = users.id)
-> Index Scan using user_chat_channel_unique_memberships on public.user_chat_channel_memberships uccm (cost=0.41..12177.25 rows=21618 width=25)
Вывод: uccm.id, uccm.user_id, uccm.chat_channel_id, uccm.last_read_message_id, uccm.following, uccm.muted, uccm.desktop_notification_level, uccm.mobile_notification_level, uccm.created_at, uccm.updated_at, uccm.last_unread_mention_when_emailed_id, uccm.join_mode, uccm.last_viewed_at
-> Index Scan using users_pkey on public.users (cost=0.42..23823.53 rows=237544 width=4)
Вывод: users.id
Фильтр: (users.last_seen_at < '2023-11-27 08:00:00'::timestamp without time zone)
-> Index Scan using index_user_options_on_user_id on public.user_options (cost=0.42..0.68 rows=1 width=4)
Вывод: user_options.user_id
Условие индекса: (user_options.user_id = users.id)
Фильтр: (user_options.chat_enabled AND (user_options.chat_email_frequency = 1))
-> Index Scan using chat_channels_pkey on public.chat_channels cc (cost=0.28..0.32 rows=1 width=21)
Вывод: cc.id, cc.chatable_id, cc.deleted_at, cc.deleted_by_id, cc.featured_in_category_id, cc.delete_after_seconds, cc.chatable_type, cc.created_at, cc.updated_at, cc.name, cc.description, cc.status, cc.user_count, cc.last_message_sent_at, cc.auto_join_users, cc.user_count_stale, cc.type, cc.slug, cc.allow_channel_wide_mentions, cc.messages_count, cc.threading_enabled, cc.last_message_id
Условие индекса: (cc.id = uccm.chat_channel_id)
-> Index Scan using index_chat_messages_on_chat_channel_id_and_created_at on public.chat_messages c_msg (cost=0.41..4.19 rows=12 width=16)
Вывод: c_msg.id, c_msg.chat_channel_id, c_msg.user_id
Условие индекса: ((c_msg.chat_channel_id = uccm.chat_channel_id) AND (c_msg.created_at > '2023-11-20 08:00:00'::timestamp without time zone))
Фильтр: ((c_msg.deleted_at IS NULL) 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)))
-> Index Only Scan using chat_mentions_index on public.chat_mentions c_mentions (cost=0.40..0.52 rows=1 width=8)
Вывод: c_mentions.chat_message_id, c_mentions.user_id, c_mentions.notification_id
Условие индекса: (c_mentions.chat_message_id = c_msg.id)
-> Index Only Scan using index_group_users_on_user_id_and_group_id on public.group_users (cost=0.42..44019.59 rows=760157 width=8)
Вывод: group_users.user_id, group_users.group_id
-> Index Only Scan using groups_pkey on public.groups (cost=0.14..0.16 rows=1 width=4)
Вывод: groups.id
Условие индекса: (groups.id = group_users.group_id)
(51 строк)
2 лайка
@sok777 спасибо за план запроса! Это очень помогает.
В вашем инстансе большое количество пользователей и большое количество записей user_chat_channel_memberships (как вы и упоминали здесь).
Прежде чем вы поделились планом тестирования, я пытался воспроизвести проблему на сайтах с большим количеством пользователей, но запрос работал нормально. Сейчас я вижу, что на тех сайтах нет большого количества записей user_chat_channel_memberships. Скорее всего, именно это является особенностью вашего сайта и стало причиной столь серьёзных проблем в вашем случае.
Насколько я понимаю, у вас сейчас нет проблем, потому что вы в какой-то момент удалили все упоминания, но я ожидаю, что этот запрос снова станет проблемным со временем, даже при небольшом количестве упоминаний. Поэтому я в любом случае займусь его оптимизацией.
Сейчас я работаю над устранением основной проблемы, которая приводила к созданию огромного количества записей chat_mention в базе данных. Пока это продолжается, важно держать @ all и @ here в списке отслеживаемых слов. Я опубликую обновление здесь, когда займусь этим, а после этого обязательно оптимизирую этот запрос.
6 лайков
Основная проблема была решена в
Проблем с производительностью больше быть не должно, и нет необходимости держать массовые упоминания в списке отслеживаемых слов.
Касательно этого:
Похоже, что жалоб на этот запрос нет, поэтому я его не оптимизировал. Пожалуйста, не стесняйтесь сообщать в случае возникновения проблем.
5 лайков