「UNICORN WORKER は 2*vCPU であるべきだ」という主張はすべて間違っているのですか？
私のサーバーは Intel Xeon E5-2686 v4 @ 2.30GHz—24vCPU+32GB RAM です。
UNICORN WORKER をいくつ設定すればよいですか？
8個ですか？それとも48個ですか？
私のサイトには7,000人以上のユーザーと、約1,000人の毎日アクティブなユーザーがいます。ユーザーは1日あたり3,000～7,000件の投稿を送信します。私たちのコミュニティは、クローラーや匿名ユーザーを含めて、1日あたり120,000～200,000件のページビューがあります。
それは多くの要因に依存します。データベースサイズとRAMの比較、ログインユーザーと匿名ユーザーのトラフィックの比率、Sidekiqキューをより忙しく保つプラグインがあるかどうか、YJITを実行しているかどうかなどです。
簡単なのは、ピーク時間中にMiniProfilerデータを確認し、フォーラムを閲覧してパフォーマンスが悪化していないかを確認し、ボトルネックを特定することです。
このCPUは古いものなので、通常よりも多くのUnicornワーカーから始めることをお勧めします。すべてのリクエストが通常よりも時間がかかるためです。しかし、PostgreSQLとRedisを同じサーバーで実行している場合、ワーカーが多すぎてもそれらを枯渇させることはできません。
まず16人のワーカーで実行してみて、サイトのパフォーマンスを評価してください。
Unicornワーカーが何をしているのか、人間が理解しやすい簡単な説明はありますか？ ユーザーのページリクエストはすべて、処理のためにUnicornワーカーに送信されるという印象を受けます。十分な数がない場合、ユーザーは待たなければなりません。数が多すぎると…RAMを少し消費するだけでしょうか？
それらはアプリケーションWebサーバーです。
「いいね！」 1
CPUが10年ものなので、性能が落ちてきているようです。Unicornのワーカーを増やすと同時に多くのユーザーに対応できるようになりますが、個々のリクエストが速くなるわけではありません。
YJITを有効にしてみてください。
「いいね！」 3
お使いのハードウェアでは、平均ログインリスト/最新時間は、アプリで約150ミリ秒、SQLで80ミリ秒になるはずです。
まず12人のワーカーで始めて、どのように動作するか確認してください。最も良いのは、メトリクスを追跡することです。ワーカーを増やすべきかどうかを知りたい場合は、リクエストがアプリワーカーを待ってキューイングされているかどうかを確認してください。
Discourse自体がPrometheusエクスポーター経由でエクスポートするメトリクスを追跡していますか？これらは、インスタンス全体のパフォーマンスを把握するのに役立ちます。
匿名ユーザーと通常の（管理者ではない）ユーザーのパフォーマンスはどのようになっていますか？
「いいね！」 5
(/stops laughing, logs into hosting provider … )
wow, is this not the default by now??
edit: ah of course you might have built with an old app.yml and not updated since
「いいね！」 1
ホスティングではデフォルトですが、RAMが不足している環境で実行している人もいるかもしれないので、デフォルトにするのは少々難しいです…
とはいえ、私たちのJSビルドはDiscourse自体よりもはるかに多くのRAMを使用するため、JSアセットをビルドできる人なら誰でも十分なRAMを余分に持っていると言えるでしょう 
「いいね！」 1
これらの画像では、何人のワーカーを設定していますか？
- キューイングが発生しているので、ワーカーを少し増やした方が良いと思います。
- Webの処理が非常に遅いため、YJITを有効にすることをお勧めします。
現在、ワーカーは8人しかおらず、YJITはすでに有効になっています。
ワーカーをあと何人増やすべきですか？
ちなみに、Falcoがその推奨をするために見ていたのはこちらです：
8 → 12に増やします。余裕ができ、キューがクリアされるはずです。
ちなみに、あの大きなスパイクは、他のリクエストが何か、おそらく共通のロックを待っていることを示しています。メガトピックの投稿かもしれません。
PostgreSQLの使用状況のメトリクスも取得できれば、有用でしょう。
メガトピックは弱点です。Improving Instance Performance (Megatopics, Database Size and Extreme Load) を参照してください。
これらを分割するか、代わりにチャットを使用することを検討してください（最大の8.9k返信のものはチャットルームとして明示されています）。
私たちのコミュニティのディスカッション文化はメガトピックスであり、Discourseを使い始める前から形成されていました。チャットには、ぼかしスポイラーや隠し詳細の機能がありません。
「いいね！」 1
どうすればよいですか
GitHub - prometheus-community/postgres_exporter: A PostgreSQL metric exporter for Prometheus を使用していますが、設定方法に関するメタガイドがあるかどうかはわかりません。
しかし、すでに prometheus をセットアップしているようですので、何をしているかわかっているようですね。
現在、サーバーRAMは16/32GB、UNICORN_WORKERS: 12、db_shared_buffers: "4096MB"です。
まだRAMに空きがあり、Webリクエストが数件キューに入っているため、UNICORN_WORKERSを24に増やしました。今日の午後、サーバーが突然シャットダウンし、再起動後にユーザーがすぐに殺到しました。これにより、アクティブなWebリクエスト数が非常に少なくなり、キューに入ったリクエスト数が多くなりました。数日前、24のUNICORN_WORKERSで150以上のアクティブなWebリクエストを処理できることを確認しましたが、今日の午後はわずか30のアクティブなWebリクエストでした。これは、ドメインを変更したばかりで、sidekiqによって多くの投稿が再ベーキングされているためです。これにより、サーバーに大きな負荷がかかっています。どうすればよいでしょうか？
