CPU使用率が非常に高く、通常は85%程度になっています。
以前は unicorn.conf.r と表示されていました。
これは UNICORN_WORKERS が高すぎる/低すぎる設定になっていることを示唆していますか？
サーバーには64GBのRAM（通常は40GB程度空きがあります）と6コアがあり、サーバー上には4つのDiscourseインスタンスがあり、それぞれ UNICORN_WORKERS: 8 に設定されています。
原因や試すべきことについて、何かアイデアやヒントはありますか？（フォーラムの1つは読み取り専用モードで、あまりトラフィックがありません。ワーカー数を少なく設定すべきでしょうか？）
わかりませんが、コアで処理できる数よりもはるかに多くのワーカーを使用しているのではないでしょうか？
はい。ユニコーンワーカーの数を減らすこともお勧めします。
ユニコーンワーカーを減らすことを試してみてはどうでしょうか。
皆さん、返信ありがとうございます。どこで読んだのかはもうわかりませんが、コアごとにワーカーを2人設定するものだと思っていました。フォーラムごとにワーカー数を減らし、最も忙しいフォーラムには多く、あまり忙しくないフォーラムには少なく割り当てました。今後1週間監視し、改善が見られない場合はまた報告します。
編集: ここで読んだと思います。(Users kicked out of topic, more memory required? - #10 by Stephen)。
あなたの場合、コアごとに2つのワーカーを割り当てていません。6つのコアがあれば12のワーカーになりますが、8つのワーカーを使用する4つのインスタンスがあるため、合計32になります。
はい…ワーカーの総数がコア数の2倍を超えないように調整しましたが、それでも疑問に思っています。正しい/標準的なアドバイスは何でしょうか？あなたが言ったことですか、それとも（Nate’s post）にあるように、Jeffがコアあたり1ワーカーと引用しているものですか？
私の実験では、コアあたり1ワーカーだとタイムアウトが発生します（サーバー負荷は低下しますが）。より多くのワーカーだとパフォーマンスは向上しますが、負荷は高くなります（私のサーバーではまだ許容範囲内です）。
現在、新規インストールのスケーリングを処理している discourse-setup を確認してください。
# UNICORN_WORKERS: 2GB以下の場合は2 * GB、または2 * CPU（最大8）
if [ "$avail_gb" -le "2" ]
then
unicorn_workers=$(( 2 * $avail_gb ))
else
unicorn_workers=$(( 2 * $avail_cores ))
fi
unicorn_workers=$(( unicorn_workers < 8 ? unicorn_workers : 8 ))
利用可能なコア数の2倍を使用する2番目のステートメントは、2GB以上のRAMを搭載したシステムではデフォルトです。あなたの問題は、Discourseの問題というよりも、インスタンス（ホストリソース）間の綱引きによるもののように見えます。
最後のアップグレード後、OPの1日後に同じ現象が発生しました。そのため、ユニコーンワーカーの数とは関係ないと思います。unicorn.conf.r*プロセスは疑わしいです。なぜなら、このトピックの元の投稿が、その用語のウェブ全体での唯一のヒットだからです。 unicorn.conf.rb の方が普通だと思います。
増加はちょうど4日前の最後のアップグレード時に発生しました。OPが5日前に投稿したことに注意してください。Discourseで何かが変更されました。
数年間、同じインスタンスで同じ数のユニコーンワーカーを使用してきましたが、何も変更していません。ただ3.4.0.beta4-devに再構築しただけです。
参考までに、サイドキックには長時間実行中のジョブや失敗したジョブはありません。
最新のDiscourseにアップグレードしたばかりですが、unicorn.conf.r*はもう見られなくなりました（CPU使用率80％前後の負荷は、今はrubyになっていますが、頻度は低くなっているようです）。負荷は以前と同じくらいです（ただし、ワーカー調整後の負荷よりは低いです）。
最新バージョンにアップグレードしましたか？どのようなハードウェアを使用しており、フォーラムはどのくらい忙しいですか？
はい、3.4.0.beta4-dev です。それが高 CPU 使用率の原因です。他に変更はありません。
RAM 8 GB、vCPU 2 基、SSD 160 GB で十分な空き容量があります。
本番サイトの CPU 使用率を上記に投稿しましたが、同時に約 30 人のユーザーがオンラインになっています。しかし、同じ問題が発生しているテストサイトがあり、そこにはトラフィックもプラグインも全くありません。更新前後の CPU 使用率（スパイクは毎日のバックアップです）：
マーク、私たちの状況は関係があるかどうかわかりません。私の場合は、スティーブンが言ったことが大きな要因だったと思います。
最近、他の2つのインスタンスを同じサーバーに移行しましたが、以前はコア数の多いサーバー（ただし、それ自体に問題があったため、コア数が少なくても全体的にパフォーマンスが良かったXeonに戻りました）を使用していたため、ユニコーンワーカーが8に設定されていたことを忘れていました。
そのため、このサーバーでユニコーンワーカーを減らすと負荷は軽減されましたが、タイムアウトが発生し始めました。ワーカーを増やすとタイムアウトはなくなりましたが、負荷は高くなりました。ただし、許容範囲内でした。ワーカーを増やしても増加した負荷を処理できると思いますが、今の状態は当面良好です。
とはいえ、インスタンスを同じサーバーに移行したところ、予想通りの範囲内で動作していました（負荷は増加しましたが、それほど大きな増加ではありませんでした）。アップデートによって負荷が増加したように感じましたが、確信はありません。また、Discourseには機能が追加されるにつれて、より強力なハードウェアが必要になったり、時には「遅く」感じられたりすることがあることを念頭に置く必要があります（古いバージョンのDiscourseインスタンスでは、明らかに機敏に感じられましたが、もちろん新しいバージョンすべての機能はありませんでした）。
とはいえ、最新のDiscourseアップデート（PG 15を使用）以降、負荷は実際には少し減少したと思います。
マーク、あなたに何を提案すべきかわかりません。ワーカーやdb_shared_buffersやdb_work_memなどの他の設定を試してみてはどうでしょうか？「アップデート後のCPU使用率が高い - インスタンスのパフォーマンス調整が必要ですか？」といった専用のスレッドを開始してみてはどうでしょうか。 
今夜アップグレードしたところ、サイトのCPU使用率にすぐに違いが見られました。これは、アップグレード前、最中、および後のグラフです。これは1時間の期間を表します。
DOで実行されている標準のDiscourseシングルコンテナインストール - 8 GB RAM、2 vCPU、100 GB SSDで、十分なスペースがあります。
12時間後の様子を見てみましょう。
アップグレードから15時間後の結果です。CPU使用率は3倍に劇的に増加しました。負荷係数は4倍に増加しました。
| 最小平均. | アップグレード前 | アップグレード後 |
|---|---|---|
| 5 | .11 | .4 |
| 15 | .10 | .45 |
24時間表示：
Javaが主なCPU使用率です。最新のアップグレードで何かが劇的に変わりました。
Discourseチームがトラブルシューティングに必要な情報は？
このトピックはバグに移動すべきでしょうか？
どうやら私の問題はユニコーンワーカーではなかったようです。@sam が @LotusJeff の スレッド に続くアップデートを行った後、サーバーの負荷は以前の状態（最大値の半分未満）に戻りました…
これで私の問題も解決しました。
サーバーの他の2つのフォーラムを最近移動した後、サーバーを監視していなければ、おそらく気づかなかったでしょう。何人がそれに気づかずに影響を受けたのか疑問です。
Discourseチームは、このような問題の警告措置を講じていますか？たとえば、管理者が特定のトピック用に設定できるボランティアプログラム、「アップグレードの前/後XX時間/日/週以内にサーバー負荷をDiscourseに送信する」など。または、ローカルで追跡し、アップグレード後にサーバー負荷の増加が検出されたときに管理者に警告する方が良いでしょう。その後、必要に応じてここに投稿できます。
サーバーへの移行を約2週間前に行ったばかりなので、サーバーを綿密に監視しているため、おそらく影響に気づかなかったでしょう。移行後のさまざまな検証（バックアップの実行など）を行っています。数ヶ月後であれば、影響に気づくことはなかったでしょう。
Discourseでは、毎日の負荷テストが実行されていることを期待します。以前、コミットされたコードで毎日再構築されるサーバーがありました。一日中サーバーを使用するシミュレートされたユーザーがいました。ユーザー視点とサーバー視点から主要なパフォーマンスメトリックを測定しました。これにより、メモリリーク、非効率的なコード、および予期しないUXの変更を積極的に検出できました。
Samとチームには、それでも称賛を送りたいと思います。phpBBの世界から来た者として、このような問題が解決・是正されるのに何十年もかかっていたことを考えると、迅速な対応は素晴らしかったです。（シドニー時間と比較して、CT時間の午前2時まで起きていなければならなかったとしても。）
