同意します。誰も読まないコンテンツに価値があるでしょうか？また、10,000 の投稿を最初から最後まで実際に読み通す人はいるのでしょうか？
一部のトピックが時間とともに完全に消える一時的なチャットであっても問題ありません。以前は「ファストレーン」と「スローレーン」のトラフィックと呼んでいたものです。
小規模アップデート:
マーク以上のすべてを閉じる（および制限を再設定する）ことが報告され、合意された後、パフォーマンスが向上しました。非常に大幅に改善されています。まだ「極度の負荷のため、これは一時的にログアウトしたユーザーが閲覧する形で全員に表示されています」というメッセージが表示されることがありますが、その頻度は大幅に減少しています。
その上で:
- 巨大なテーブルの削減方法について調査していただいたご尽力に感謝いたします。本当に助かりました。
- 他に「パフォーマンスのヒント」や「設定」で見落としているものはありますか？「上級者向け」のものでも、どのような情報でも大歓迎です。
再び、皆様のご協力とフィードバックに心から感謝申し上げます。
Postgres 12 は、@falco のテストではテーブルとインデックスのサイズを 20% 削減するため、役立ちます。
それには目標日付は決まっていますか？
今日、ベンチマークを開始しました。
Meta でしばらく実行させて、全社展開する前にパフォーマンスの回帰を確認する必要があります。
この件を再び取り上げてしまい申し訳ありませんが、これは PostgreSQL 移行とは異なる問題です。（サイズの問題により、まだ移行できていません。）
最後の再構築以降、データベースサイズが止まらず増え続けています：
最後の再構築は 5 月 17 日に行われ、それ以降 DB サイズは増加を続け、57.3GB に達しています。その大半は post_timings テーブルに存在します。
私の主な懸念は、PostgreSQL の更新（インデックスサイズを 20% 削減できますが、長期的にはこの問題を解決するものではありません）を行おうとしている点です。スタッフのコメントによると、このサイズは正常ではなく、このまま増え続け、維持コストが地獄のように高くなっていくでしょう。時間が経つほどサイズは増大し、維持が極めて困難な悪循環に陥ります。したがって、私の根本的な問題は変わりません。post_timings に関する何かに対処する方法はあるでしょうか？削除できるものはありますか？
テーブルを圧縮したりできるでしょうか？
皆様のご支援に感謝いたします。
現時点では回避する方法はありません。フォーラムが非常に大規模であれば、タイミングのテーブルも大きくなります。
Meta は非常に古いインスタンスですが、中規模であり、post_timings テーブルはわずか 4GB です。一方、2 年未満のインスタンスをホストしている別のケースでは、post_timings テーブルは現在 100GB を超えているはずです。
大規模なフォーラムをホストするには、より多くの費用がかかるのは事実であり、現時点では回避策はありません。
データベースを単独の 20 ドル droplet（80GB ディスク）に移し、ウェブを別の 10 ドル droplet に配置するのはどうでしょうか？かなり大規模なコミュニティに見えても、月額 30 ドルというコストは妥当に思えます。
@Falco さん、大変お世話になりました。
はい、おっしゃる通りです。宇宙に関しては「魔法」など存在しません。私は分割について検討していますが、その場合、アプリ側のパフォーマンスが低下してしまいます（長話になるので割愛しますが、テスト結果を記録しており、後ほどここに共有します。他の皆さんも必要であればご活用ください）。
以前お話ししたバックアップ復元に関するテストを実施しました。個人的には、これは良い機会だと考えています。現時点で確認できるのは、ディスク使用量が 30% 減少していることです（まだ何か見落としがないか、いくつかのテストを継続中ですが）。ただし、このアプローチには 小さな問題 もあります。そのため、即座のメリットは大きいものの、いくつかの問題が発生する可能性があります（特に、画像がキャッシュされているのか、あるいは保存された画像として機能していないのかが不明な点も課題です。なお、バックアップには画像が含まれています）。
これらの内容をまとめ、元の投稿（OP）を更新する予定です。パフォーマンスやこれまで行ってきた変更について懸念を持つ人のために、いくつかの補足メモを追加する予定です。
技術的な観点から、この問題に対して「返信の自動削除」タイマーを適用するのは良い解決策でしょうか？
実はこれはかなり良いアイデアで、使いやすさの問題を解決します（すでに述べた通り、誰も1万件のメッセージを読む気はないからです）。したがって、大きな疑問は、それがサーバーとデータベースに負荷をかけるかどうかです。
9000件の返信トピックのうち約8600件が削除されていることがパフォーマンスに良いかどうかはわかりませんが、どうやらそうではないような気がします。どう思いますか、@eviltrout？
「隠された」投稿は一定時間後にデータベースから完全に削除されると考えていましたが、どうやらそうではないようです。
したがって、パフォーマンスの観点からは、私のアイデアでは問題を解決できません。
このデータを「消去」する方法はありますか？
削除された投稿はソフト削除されます。ただし、検索エンジンにインデックスされることが多いため、大量に削除すると改善が見られる場合があります。しかし、それは推奨しません。トピックが大きくなりすぎた場合は、新しいトピックに移動する方法があれば、それが役立つかもしれません。
その意味を詳しく教えていただけますか？データベースとWebアプリを別サーバーに配置することで、サーバー間の多少のレイテンシは発生するものの、UnicornとPostmasterがCPUやRAMを競合せずに済むため、むしろパフォーマンスが向上するはずです。
サーバーは同じDOリージョンにあることを確認してください 
申し訳ありませんが、おっしゃる通りです。両方を解放することで、単一のマシン上ですべてを実行する場合よりもパフォーマンスが向上します（私は単一マシンで現在使用しているリソースと、これまでに適用しているチューニングと比較していました）。
これは非常に良いアイデアですね。私が抱えている「データコンテナの再構築ができない」という問題を解決できるよう努め、それがこの旅における次のステップになります。
この件についてあれこれ調べてみたのですが、理想的な方法を示すドキュメントが見つかりませんでした。そのようなガイドは存在しますか？
当社の標準的な単一 VPS 環境でも限界に達しつつあります。当社の独特な課題は、ホッケーの試合中に発生するゲームチャットです。これにより、アクティビティや負荷が急激に跳ね上がります。特に試合中に何らかの extraordinary な出来事が起きた場合です。
おそらく、最も混雑する時間帯にも耐えられるほど強力な環境が必要になるでしょう。あるいは、その時間帯にパフォーマンスを向上させる必要があるかもしれません。時間単位で課金できるVPSを探すのも一案です。一つの方法（前のアドバイスを踏まえて）は、ゲームが行われる数時間だけ、非常に高性能なVPSを有料で利用して、Webコンテナを移動させることです。
以下の手順が必要です：
-
PostgreSQL を別の場所（ドロレット、または Worry-Free Managed Database Hosting | DigitalOcean のようなホスト型サービス）で実行し、データをそちらに移行してください。
-
別々の PostgreSQL サーバーで Discourse を実行する に従ってください。
また、Discourse のコンテナ化された製品（Web_only と data）を使用しても実現可能ですよね？
私の経験上、これは現在のどのアプローチでも直接解決されるものではなく、線形な解決策も存在しません。実際、別々のマシンに分離しても、この問題に対する即効性のある解決策にはなりません。
また、大きなイベント（@ljpp が言ったようなゲームなど）が発生すると、激しい遅延や「サイトが非常に混雑しているため、ログインしていないユーザーとして表示されています」というメッセージが発生し、そのトピック内のユーザーだけでなく、サイト全体が影響を受けます。
そのため、私は「分離されたセットアップ」と「大型マシン」の 2 つのアプローチを試しましたが、どちらも同様の問題が発生します。私のインスタンスは Prometheus で監視され、ログは Grafana などで確認可能であり、ハードウェアやコンテナのパフォーマンスを非常に詳細に制御できます。しかし、何を行ってもこの問題は必ず発生することを確認しています。
大型マシンを背後に配置しても、わずかに遅延を遅らせることはできるかもしれませんが、エラーやセッションの切断が発生し、マシン自体はディスク、CPU、RAM のいずれもほとんど使用されません。これは「デフォルトのインストール」と「2 つのコンテナ」のインストールの両方で起こります。
異なるマシンを使用する場合でも、マシンの種類が同じであるか、一方が「CPU 最適化」で他方が「ディスク最適化」であるかなどに関わらず、問題は同じです。さらに、異なるマシン間の接続に失敗する可能性という追加のレイヤーも考慮する必要があります。この接続には遅延が避けられませんが、遅延の量は接続の設定方法や 2 つのマシン間の距離によって変化します。しかし、同じ挙動が発生します。
参考までに、この種の挙動は Babel プラグインなどでも見られますが、Babel プラグインははるかに多くの「同時」書き込みを処理できるようです。「チャット」は実際には隠しトピックですが、その違いは表示方法や「更新」/「プル」の仕組みにあります。この挙動の違いから、私はこれがアプリケーション上の相関関係であり、フロントエンド側の問題がアプリを「クラッシュ」させていると結論づけました（フロントエンドは私の専門外ですが、バックエンドは専門です）。これは、投稿時の操作や、1 分間に数十件のメッセージが投稿されるトピックに待機して「自動更新」を待つ人々によるものです。
これに、人間の要因も加わります。サイトが「もたつく」またはトピックが「期待通りに更新されない」と感じると、人々は F5 キーを連打してリロードし、さらに負荷がかかります。しかし、その点について人々を「教育」するのは大変でしょう