そのメッセージは意味のあるものです。システムにリソースが空いているという事実は、誤った設定の可能性を示唆しており、誤った識別ではありません。
unicorn_workers はいくつありますか？
ホストに他に何もロードされていないと仮定して、16個（コアあたり2個）を割り当てましたか？
ローカルのPostgresを使用している場合、db_shared_buffers はいくつですか？
メッセージは、VM/ホストのリソースではなく、Discourseに割り当てるリソースに関連しています。
db_shared_buffers を予約メモリの 25%、ユニコーンワーカーを CPU あたり 2 に設定します。微調整が必要になる場合があります。
リソースプールが信頼できないと感じる場合は、VM 外のリソースも管理する必要があることは明らかです。Discourse を実行しているほぼすべての人が、何らかの VPS で実行しています。
私はディスコースの専門家ではないので、利用可能なメモリ/CPUに基づいてそれらを設定する必要があることを覚えているように、インストールスクリプトを実行しただけです。
テスト前の状態にワーカーを復元し、再度確認します。
正直なところ、これらの設定で問題はありませんでしたが、無関係であるか、部分的にしか関係がない可能性もあります。
ワーカーのコア数を2倍にし、db共有バッファの予約メモリの25%にするという提案を覚えておきます。
予約メモリとは、コンテナが実行されている予約メモリのことですか？というのも、それは常に「ホストが利用可能なメモリと同じだけ」であるように見えるからです:eyes:
discourse-setup は次のように設定します。
# db_shared_buffers: 1GBあたり128MB、2GBあたり256MB、または256MB * GB、最大4096MB
# UNICORN_WORKERS: 2GB以下は2 * GB、または2 * CPU、最大8
「最大」は、特に大規模コミュニティではこれらの数値を超えてメリットが見られるため、額面通りに受け取ることはできません。
したがって、あなたのケースでは、最大8人のワーカーと4096MBが指定されるはずです。Discourse で利用可能なワーカーと共有バッファを減らすと、VM のリソースがすべて消費される前に上限に達します。
@mpalmer 氏の次の投稿は依然として良いガイダンスです。
これは、リクエストが長すぎる間キューに入れられた場合にトリガーされるように見えます。つまり、リクエストが処理速度よりも速く入ってくる場合です。なぜこれほど多くリクエストがあるのか、あるいはなぜ処理がこれほど遅いのか疑問に思うかもしれません。Discourseレベルでは、このスレッドで既に議論されている調整可能な設定や、例えばExtreme load errorなどで説明されているものがあります。
Linuxレベルでは、以下を確認します。
uptime
free
vmstat 5 5
ps auxrc
更新情報：ワーカーを増やすことで問題が解決しました
フォローアップです。
それ以来、問題はなさそうでしたが、ここ数日、フォーラムが時々「遅い」と感じています。遅いというのは、リクエストの処理（返信の送信、編集など）に時間がかかるということで、ちょうど今、同じメッセージが再び表示されていることに気づきました。
設定したGrafanaダッシュボードを確認したところ、CPU使用率が限界に達していることがわかりました。
docker statsを簡単に実行したところ、以下のようになりました。
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
2c81f3b51e74 app 800.14% 18.18GiB / 29.38GiB 61.87% 57.1GB / 180GB 31.1TB / 7.45TB 282
5164921ee233 grafana 0.05% 98.36MiB / 29.38GiB 0.33% 2.05GB / 284MB 7.26GB / 6.17GB 17
400e496902d7 prometheus 0.67% 139.1MiB / 29.38GiB 0.46% 101GB / 3.82GB 28GB / 27.6GB 14
e2af5bfa922f blackbox_exporter 0.00% 13.71MiB / 29.38GiB 0.05% 169MB / 359MB 295MB / 27.4MB 14
581664b0fe9a docker_state_exporter 8.59% 11.86MiB / 29.38GiB 0.04% 533MB / 8.67GB 65.2MB / 6.16MB 15
408e050e9dc9 discourse_forward_proxy 0.00% 5.926MiB / 29.38GiB 0.02% 40.1GB / 40.1GB 36.8MB / 9.68MB 9
fbba6c927dd8 cadvisor 9.13% 385.5MiB / 29.38GiB 1.28% 2.25GB / 135GB 85.1GB / 2.65GB 26
8fe73c0019b1 node_exporter 0.00% 10.74MiB / 29.38GiB 0.04% 112MB / 1.84GB 199MB / 2.82MB 8
9b95fa3156bb matomo_cron 0.00% 4.977MiB / 29.38GiB 0.02% 81.4kB / 0B 49.4GB / 0B 3
553a3e7389eb matomo_web 0.00% 8.082MiB / 29.38GiB 0.03% 2.15GB / 6.36GB 215MB / 2.36GB 9
adf21bdea1e5 matomo_app 0.01% 78.13MiB / 29.38GiB 0.26% 8.63GB / 3.74GB 59.8GB / 3.07GB 4
96d873027990 matomo_db 0.06% 36.8MiB / 29.38GiB 0.12% 3.11GB / 5.76GB 4.16GB / 8.35GB 13
原因として考えられることはありますか？
アプリの再起動を試しましたが、再起動直後もロードは同じ量まで上昇し続けています。
どのプロセスが最も多くのリソースを使用しているかを確認する方法はありますか？ Sidekiqダッシュボードを確認しましたが、実行中/キュー内のプロセスのリストと実行の平均時間しか表示されません。一部は遅い（数分かかる）ですが、現在処理中または失敗中のものは何も見えません。
そしておそらく
ps auxf
アップデート中にエラーが発生しました
api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })
修正にご協力ください。
8 vCPU マシンでロードアベレージが 8 を超えているということは、サーバーが過負荷状態であることを意味します。
8 つのユニコーン、多数の PostgreSQL PID、およびサーバー上のその他のすべてが、着信リクエストを十分に速く処理できません。少なくともメモリは十分にあります 
Discourse がユニコーンの CPU でこのようにボトルネックになるのは少し珍しいです。私がこれまでに見たほとんどの場合、それは不正なプラグインが原因でした。app.yml を共有していただけますか？
また、ホームページとトピックページの読み込みの両方の MiniProfiler 結果を共有してください。
このスクリーンショットでは列ラベルが切れているようですが、最初の3つのうちの1つが平均値であれば、問題は解決したことになります。
出力ありがとうございます。参考までに、vmstat の最初の統計行はあまり役に立ちません。5 行すべてが、必要な全体像を示しています。
申し訳ありません、ここを更新するのを忘れました。
結局、私の推測通りでした。ホスト上に別のVPSが展開され、それを消費していました。
チケットがオープンしてから24時間以内に、別のホストに移動しました。
Contabo、ブラボーです 
これは「ディスコース」に関連するものではありませんが、他の人がインスタンスに問題がある他の理由を理解するのに役立つ可能性があるため、モデレーターにこれらの最後の返信をここに残すようお願いします。
