А, понятно, этот запрос будет работать с трудом. После обновления до последней версии, пожалуйста, извлеките запрос из mini_profiler, выполните над ним explain analyze и поделитесь результатами с нами.
На Meta (RDS db.r6g.large 30 ГБ) это выглядит так:
Я попробую снова запустить explain analyze, но нам пока не удалось успешно выполнить этот запрос.
Обновление: этот коммит ничего не изменил. База данных по-прежнему постоянно нагружена на >95% после обновления и убивает все старые выполняющиеся запросы. В версии beta4 для этого форума она работала стабильно с нагрузкой 20–30%. Мы уже выполнили авто-vacuum и реиндексацию схемы.
Как отключить эту функцию? Неправильно просто увеличивать размер экземпляра базы данных для решения этой проблемы; похоже, что проблема в том, как вычисляется этот запрос, учитывая, что до этого обновления он выполнялся отлично.
Запрос удалось завершить примерно за 21 минуту
Также стоит отметить, что мы используем PG 10.17, так как наши результаты значительно отличаются.
Мы временно исправили проблему с помощью патча, перенаправив все маршруты */private-messages-all/* на */private-messages/*. В результате раздел «Все ящики» теперь содержит то же самое, что и «Личные сообщения», но хотя бы нам больше не приходится постоянно сталкиваться с 100% загрузкой процессора.
Код патча:
# name: discourse-private-messages-perf-hotfix
# version: 0.0.1
# authors:
# Prepend to override existing routes
Discourse::Application.routes.prepend do
scope path: nil, constraints: { format: /(json|html|\*\/\*)/ } do
scope "/topics", username: RouteFormat.username do
# Reroute all */private-messages-all/* routes to go to */private-messages/* instead (personal messages)
# Former is expensive, latter is cheap, potentially saves significant database CPU usage
get "private-messages-all/:username" => "list#private_messages", as: "topics_private_messages_override", defaults: { format: :json }
get "private-messages-all-sent/:username" => "list#private_messages_sent", as: "topics_private_messages_sent_override", defaults: { format: :json }
get "private-messages-all-new/:username" => "list#private_messages_new", as: "topics_private_messages_new_override", defaults: { format: :json }
get "private-messages-all-unread/:username" => "list#private_messages_unread", as: "topics_private_messages_unread_override", defaults: { format: :json }
get "private-messages-all-archive/:username" => "list#private_messages_archive", as: "topics_private_messages_archive_override", defaults: { format: :json }
end
end
end
Загрузка процессора базы данных нашего форума после развертывания вышеуказанного патча:
@tgxworld Тебе стоит ещё раз посмотреть, что именно делают маршруты */private-messages-all/*. Очевидно, что в их реализации есть проблема: она недостаточно эффективна для крупных баз данных форумов. Либо в реализации не используются правильные индексы базы данных, либо генерация запросов приводит к крайне затратным запросам (особенно в PSQL 10, не уверен насчёт версий 12/13?).
Текущая реализация фактически парализовала наш форум, увеличив загрузку процессора с ~15% до постоянных 100% и вызвав замедление работы всех остальных функций форума. Я не вижу причин, по которым запросы для личных/групповых ящиков выполняются за <50 мс, а запросы для «всех ящиков» занимают более 20 минут.
Ты можешь использовать дамп анализа, который @forkythetoy опубликовал чуть выше, чтобы увидеть выполнение запроса длительностью более 20 минут.
@Falco Я только что заметил, что вы объединили нашу тему здесь, но, похоже, речь идет о другом эндпоинте. Этот отчет об ошибке касается эндпоинта private-message-topic-tracking-state, а мы обсуждаем */private-messages-all/*. Это, возможно, вызвало путаницу, приношу извинения. (Я изначально дал ссылку на эту тему, что, вероятно, и стало причиной неразберихи)
Эндпоинт private-message-topic-tracking-state работает быстро на нашем форуме, поэтому для нас это не является проблемой.
Для нас этот запрос занимает около 200–300 мс времени базы данных. Чуть дольше, чем можно было бы ожидать, но всё ещё в пределах нормы, да.
Однако мы используем Postgres 13.
@Hooksmith У меня есть исправление в очереди
@Hooksmith @forkythetoy Вы сможете обновиться до PG 13? Это минимальная версия, требуемая Discourse на данный момент. Кроме того, мне сложнее сравнивать планы выполнения запросов, когда запросы выполняются на разных версиях PG.
Мне пришлось откатить это изменение, так как производительность нового запроса слишком сильно различается у разных пользователей.
@blattersturm Вы всё ещё замечаете низкую производительность отслеживания состояния тем?
Не уверен, не обновлялся уже несколько дней. Есть ли какие-то коммиты, которые стоит взять, чтобы проверить, что-то улучшилось?
Нет, ничего не изменилось, но если вы сможете предоставить мне EXPLAIN ANALYZE по этому запросу, это было бы полезно.
Обратите внимание, что мы пока отменили объединение всех ящиков из-за проблем с производительностью.
Эта тема была автоматически закрыта через 14 дней. Новые ответы больше не принимаются.
