100GB以上のデータベースでプロファイル読み込みが遅い

こちらの投稿のフォローアップです:Slow Page Loads on User Profiles

これらの変更が適用されたため、Discourse へのインポートを再度テストしています。プロファイルの読み込みは改善されました(特に、データがキャッシュされた後の初期読み込み後)が、一部のプロファイルの読み込みにはまだ 5〜10 秒かかっています。ここでもっとできることはありますか?問題となっているクエリは以下のもののようです:

「いいね!」 2

Discourse はどのようにインストールしましたか?

「いいね!」 1

Docker コンテナを手順に従ってインストールしてください。

「いいね!」 1

メモリはどれくらいですか?データベースのサイズはどのくらいですか?

「いいね!」 1

この VM は 8 コア、RAM 32 GB です。データベースは約 40 GB だと思いますが、現時点では 100% 確信はありません。

「いいね!」 1

プロフィールページの読み込みが遅い問題は、以下の状況でも発生しますか?

  • 匿名(ログインしていない)ユーザーとしてユーザープロフィールページを表示する場合
  • 一般ユーザーのプロフィールページとスタッフユーザーのプロフィールページを表示する場合を比較した場合
「いいね!」 2

はい、両方ともそうです。通常ユーザーでテストし、ログアウトしても、動作はほぼ同じでした。

エクスポートとリストアを試みました(参考:https://meta.discourse.org/t/restore-failing-check-free-disk-space/173783)が、動作には変化が見られませんでした。また、これらのプロフィールページを表示しようとすると、頻繁にエラーが発生することも付記しておきます。これはページ読み込みを試みて数秒後に現れます。

リストア後のデータベースサイズは現在 104 GB です。

そのトピックは主に、そのルートで発生していた多数の N+1 クエリに関するものでしたが、これらはすべて現在修正されています。

プロフィールページには、ユーザーの非常にパーソナライズされた完全な要約を出力するため、いくつかの重たいクエリが含まれていますが、適切なサイズのデータベースであれば、500ms 未満でレンダリングできるはずです。

それは小規模な VM としては大きなデータベースです。すべて(Web + DB + Redis)を同じ VM で実行していますか?

最新の PostgreSQL 13 を実行していますか?PostgreSQL 13 アップデートで説明されているオプションのパフォーマンスタスク(vacuumreindex の両方)を実行してみてください。

「いいね!」 3

問題を抱えているユーザーは、投稿数が非常に多いユーザーです。投稿数の少ないユーザーのプロフィールページは、予想通り即座に読み込まれます。

もしかすると、私の期待値を見直す必要があるかもしれません。Discourse にとって 8 コアと 32 GB の RAM は小さい方なのでしょうか?(はい、単一コンテナインストールとして稼働しています。)現在のソフトウェアでは、このボードを 2 コアと 8 GB の RAM で問題なく運用できています。

データベースについては、新しく構築されたコンテナなので、13.1 から開始しました。リストア直後に VACUUM や再インデックスが必要になるでしょうか?

「いいね!」 1

そのサイズのデータベースであれば、VACUUM は間違いなく推奨されます。

「いいね!」 3

あなたの投稿の直後にこれらを開始しました。バキュームは非常に短時間で完了しましたが、再インデックスは開始から24時間以上経った今も進行中です。これは正常でしょうか?どれくらいかかることが想定されていますか?リソース(もしあれば)のボトルネックをどうやって確認できますか?postmaster はほとんどの場合 2〜4 コア以上を使用しておらず、RAM も十分にあるように見えます。

「いいね!」 1

再インデックスがまだ実行中であることをお知らせできず残念です。

@Falco @codinghorror @pfaffman

@Ghan と私は過去 1 年間、コミュニティへのインポートが正しく機能するように改善と確認を重ねてきました。しかし、私の頭にある疑問は以下の通りです:2500 万を超える投稿を持つコミュニティをインポートする際に、他に考慮すべき点はありますか?

Discourse 上に、それほどの規模のコミュニティは存在するのでしょうか?

公開されている顧客リストを確認したところ、少なくとも私が確認できる範囲では、私たちの規模に近い顧客はいませんでした。しかし、数千から数万の顧客がリストに含まれていない可能性も想像できます。私たちはインポートを完了させ、自環境では正常に動作していますが、大量の投稿を持つアカウントのプロファイル読み込み問題や、今回の再インデックス化の問題など、常に新たな課題に直面しています。

この移行を円滑に進めるためのアドバイスはありますでしょうか?

「いいね!」 1

別の投稿から db:stats の Rake コマンドを見つけました。
Reindex がまだ実行中なので、これらの数値が完全に確定したかどうかはわかりません。

「いいね!」 3

はい、別のトピックでも述べた通り、1GB のデータベースを持つインスタンスも、500GB のデータベースを持つインスタンスもあります。ただし、それらのインスタンスは完全に異なるサイズの VM で稼働しています。

あなたのサーバーのディスクパフォーマンスはどうですか?古い回転式ハードディスクを使用していますか?

「いいね!」 2

ホストサーバーでは、ZFS ミラーリングで構成されたデュアル 1.2 TB の Intel P3600 NVMe SSD が搭載されています。

「いいね!」 2

次に確認すべきは PostgreSQL のチューニングです。app.yml でデフォルト設定を使用されていますか?

「いいね!」 1

はい。ランチャーがホストマシン上のリソースに基づいて自動的にいくつかの値を設定するのか、それともチューニングに関する推奨ガイドラインがあるのか、確信が持てませんでした。データベースのチューニングに関するガイドはありますか?

app.yml にはいくつかのコメントがありますが、これは主に小規模なセルフホストサイト向けに最適化されています。おそらく、そこにある設定値を増やす必要があるでしょう(正確な設定名は覚えていません)。さらに詳しい情報は、より一般的な PostgreSQL のドキュメントを参照してください。

Discourse があなたのコミュニティ規模に対応できないわけではありません。単に小規模な運用とは異なり、やや複雑になるという点です。

「いいね!」 3

ありがとうございます、必ず確認させていただきます。Postgres は詳しくありませんが、長年 MySQL を運用してきた経験から、同じ原則が適用されることを願っています。

確かにそうですね。必要な変更の種類について一定の進展が見られれば、その後は非常にスムーズに進むと感じています。

「いいね!」 3