private-message-topic-tracking-state.json 加载缓慢

贡献 错误
25

哦，我明白了，这个查询会有些吃力。更新到最新版本后，能否请您从 mini_profiler 中提取该查询，对其运行 explain analyze 并与我们分享结果？

在 Meta（RDS db.r6g.large 30GB）上，结果如下：

1 个赞
26

我会再尝试运行 explain analyze，但我们一直未能成功完成该查询。

27

更新：此提交未做任何更改。更新后数据库仍持续以超过 95% 的负载运行，并终止所有旧查询。在 beta4 版本时，该论坛的数据库负载稳定在 20-30%。我们已执行过自动清理（auto-vacuum）和模式重建索引（schema reindex）。

如何禁用此功能？单纯升级数据库实例似乎并非正确的解决方案。鉴于该查询在此更新前运行良好，问题似乎出在查询的计算方式上。

28

查询在约 21 分钟后成功完成。

另外需要注意的是，我们使用的是 PG 10.17，因为我们的输出结果似乎存在较大差异。

1 个赞
29

我们暂时通过猴子补丁修复了该问题，将所有 */private-messages-all/* 路由重定向到 */private-messages/*。结果是“所有收件箱”的内容与“个人”相同，但至少我们不再需要持续应对 100% 的 CPU 占用。

猴子补丁代码：

# name: discourse-private-messages-perf-hotfix
# version: 0.0.1
# authors: 

# 前置以覆盖现有路由
Discourse::Application.routes.prepend do
  scope path: nil, constraints: { format: /(json|html|\*\/\*)/ } do
    scope "/topics", username: RouteFormat.username do
      # 将所有 */private-messages-all/* 路由重定向到 */private-messages/*（个人消息）
      # 前者开销大，后者开销小，可能显著节省数据库 CPU 使用
      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

部署上述猴子补丁后，我们论坛数据库的 CPU 使用率如下：

image
image819×299 13.9 KB

@tgxworld 你需要再次检查 */private-messages-all/* 路由的具体实现，显然其中存在问题，对于大型论坛数据库来说效率太低。要么是未使用正确的数据库索引，要么是查询生成导致了极其昂贵的查询（尤其在 PSQL 10 上，PSQL 12/13 尚不确定）。

当前的实现几乎让论坛瘫痪，CPU 使用率从约 15% 飙升至持续的 100%，并导致所有其他论坛功能性能变慢。我不明白为什么“个人/群组收件箱”查询耗时不到 50 毫秒，而“所有收件箱”查询却需要 20 多分钟才能完成。

你可以使用 @forkythetoy 刚才发布的 analyze 转储文件，查看之前 20 分钟以上的运行记录。

1 个赞
30

@Falco 我刚刚注意到您将我们的话题合并到这里了，但这似乎涉及的是另一个端点。此错误报告针对的是 private-message-topic-tracking-state 端点，而我们讨论的是 */private-messages-all/*。这可能会导致此处的一些混淆，对此我表示歉意。（我最初链接的是这个，可能引发了混淆）

在我们的论坛上，private-message-topic-tracking-state 响应很快，所以这对我们来说不是问题。

31

对我们来说，这条查询的数据库耗时约为 200-300 毫秒。虽然比预期稍长，但仍在正常范围内，没错。

不过，我们使用的是 Postgres 13。

1 个赞
32

@Hooksmith 我已经有一个修复方案在推进中

5 个赞
33

@Hooksmith @forkythetoy 你们能否升级到 PG 13？这是目前 Discourse 要求的最低版本。此外，当查询未使用相同的 PG 版本执行时，我也更难比较查询计划。

我不得不回退此更改，因为新查询的性能在不同用户之间存在过大差异。

1 个赞
34

@blattersturm 你仍然发现主题追踪状态的性能很慢吗？

35

不确定，已经好几天没有进行升级了。有没有什么提交可以合并看看是否有改进？

36

没有，什么都没变。但如果你能提供该查询的 EXPLAIN ANALYZE 结果，那会很有帮助。

1 个赞
37

请注意，由于性能方面的考虑，我们暂时恢复了所有收件箱。

3 个赞
38

此主题在 14 天后自动关闭。不再允许新回复。