private-message-topic-tracking-state.json の読み込みが遅い

貢献 バグ
25

ああ、なるほど、そのクエリではうまくいかないかもしれませんね。最新版にアップデートした後、mini_profiler からクエリを抽出し、explain analyzeを実行して結果を共有していただけますか？

Meta (RDS db.r6g.large 30GB) では、以下のような結果になります：

「いいね！」 1
26

explain analyzeを再度実行してみますが、そのクエリが正常に完了したことはありません。

27

更新：このコミットは何も変更していません。更新後もデータベースは常に 95% 以上で稼働し続けており、すべての古い実行中のクエリを殺しています。ベータ 4 では、このフォーラムでは 20〜30% の安定した稼働率でした。すでに自動バキュームとスキーマの再インデックスも実行済みです。

この機能を無効にするにはどうすればよいでしょうか？この問題を解決するためにデータベースインスタンスを大型化する必要があるとは考えにくく、この更新前は問題なく動作していたという事実から、このクエリの計算方法に何か問題があるようです。

28

クエリは約21分後に完了しました。

なお、出力結果に大きな違いが見られるため、現在PG 10.17を使用しています。

「いいね！」 1
29

この問題は、*/private-messages-all/* のすべてのルートを一時的に */private-messages/* にリダイレクトする形で、モンキーパッチを適用して対応しました。その結果、「すべての受信トレイ」の内容は「個人用」と同じになりますが、少なくともこの方法であれば、CPU 使用率が常に 100% になるという問題に対処する必要がなくなります。

モンキーパッチのコード:

# 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 において、12/13 については不明です）。

現在の実装はフォーラムを事実上機能不全に陥らせ、CPU 使用率を約 15% から常に 100% に引き上げ、他のすべてのフォーラム機能のパフォーマンスを低下させています。個人用/グループ受信トレイのクエリが 50ms 未満で完了するのに、なぜ「すべての受信トレイ」のクエリが 20 分以上も完了するのに時間がかかるのか、理由が見当たりません。

先ほど @forkythetoy さんが投稿した analyze ダンプを使用して、20 分以上のランタイムが発生していた様子を以前から確認できます。

「いいね！」 1
30

@Falco 直ちに気づいたのですが、私たちのトピックをここにマージされましたが、これは実際には別のエンドポイントに関するもののようです。このバグ報告は private-message-topic-tracking-state エンドポイントに関するものですが、私たちは */private-messages-all/* について話しています。これがここで混乱を招いている可能性があり、申し訳ありませんでした（最初はこれにリンクしており、それが混乱のきっかけになったかもしれません）。

private-message-topic-tracking-state は当フォーラムでは高速に動作するため、これが私たちの問題の原因ではありません。

31

私たちの環境では、このクエリはデータベース処理に約200〜300msを要しています。期待されるより少し長いですが、まだ正常範囲内と言えます。

ただし、当社は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日後に自動的に閉鎖されました。新しい返信は許可されていません。