ログで一貫してこれが発生しています。値は 100k から 1.35m の間ですが、100k 付近の読み取り値はかなり一般的です。
Redis のネットワーク接続のパフォーマンスが非常に低下しています。 最後の RTT 測定値は [97069, 103986, 98459, 100762, 381617] でした。理想的には 1000 未満であるべきです。 Redis が Sidekiq と同じ AZ またはデータセンターで実行されていることを確認してください。 これらの値が 100,000 に近い場合、Sidekiq プロセスが CPU で飽和している可能性があります。同時実行性を減らすか、https://github.com/mperham/sidekiq/discussions/5039 を参照してください。
これは、Redis が十分な CPU を使用できていないことを示唆しているのでしょうか？サーバー自体の CPU と RAM には十分な余裕があるように見えます。
また：
Sidekiq がメモリを過剰に使用しています (使用量: 3570.19M)。'www.example.com' のために再起動します。
これは、Discourse stable 3.3.2 のオールインワン app.yml を使用しています。
app.yml から：
UNICORN_SIDEKIQS: 9
DISCOURSE_SIDEKIQ_WORKERS: 5
ホストにもこの構成を追加しました：
Sidekiq ダッシュボードの情報：
Redis が 1024M のメモリ使用量を超えることができないように見えます。
何かアイデアがあれば、ぜひ教えてください！ 
これに続いて、Jobs::PostAlert でも同様の問題が発生しています。
これらのジョブは、4つのSidekiqと5つの（デフォルトの）スレッドを使用している場合、現在のテストでは15分までかかることがよくあります。Sidekiqの1秒あたりのジョブ処理速度は、主にそれらのジョブが同時にいくつ実行されているか、そして他のジョブにいくつのスレッドが空いているかに依存するようです。
Sidekiqを6以上に増やす（スレッド5）とキューのクリア速度は上がりますが、Postgresはかなり定期的にクラッシュします（おそらく、同時に実行されるJobs::PostAlertジョブが多すぎるためだと推測されます）。
これはStable 3.3.2での話です。リンクされたスレッドからの変更と修正は、私の間違いでなければ、すでに3.3.2に実装されているようです。
Postgresは決してクラッシュするべきではなく、一般的にはPostgresのバグか、何らかのより大きな問題を示しています。
ログはありますか？
「いいね！」 2
Ed_S
(Ed S)
4
カーネル設定の変更後、サーバーを再起動しましたか？
lscpu
も役立つかもしれません
「いいね！」 1
Falco
(Falco)
5
UNICORN_SIDEKIQSをそれほど高く設定しないでください。ワーカーのみを増やしてください。
これは決して起こるべきではありません。
考えられる原因は以下の通りです。
- リソースが不足している
a) サイトがサーバーリソースを超えて成長した
b) リソースの割り当てを誤っている
- スタックにバグがある
まず、以下のように設定してみてください。
UNICORN_SIDEKIQS: 1
DISCOURSE_SIDEKIQ_WORKERS: 20
これにより、サーバーからRAMが解放されるはずです。
さらに詳しい情報が必要な場合は、問題のジョブをPostgreSQLコンソールで実行し、ボトルネックが何であるかを報告してください。
「いいね！」 1
お待たせして申し訳ありません、そしてご返信ありがとうございます。
Redisが遅かった主な原因は、THPがまだ有効になっていたことだと考えています（そう思っていたのですが）：
PGのクラッシュについては、私にとっての主な解決策は、app.ymlにこれを追加することでした。
docker_args:
- "--shm-size=34g"
値をdb_shared_buffers + 2GBに設定し、db_shared_buffersはホストマシンの合計RAMの25%です。
デフォルトの512mを上書きしています：
「いいね！」 1
Ed_S
(Ed S)
7
あなたの投稿履歴を遡って確認したところ、Very slow Sidekiq issue … massive numbers of unread user notificationsで、32コア128GBのサーバーで、非常に大規模でアクティブなユーザーベースで運用していたことがわかりました。その文脈からすると、34Gがそれほど大きな数値ではないことは理解できます！ただし、参考として、あなたのセットアップの規模（日次および月次のアクティブユーザー数、データベースバックアップのサイズ、サーバー設定のRAM、スワップ、ディスク、CPUなど）を知ることが役立つ（そして興味深い）かもしれません。あるいは、大小さまざまな統計を共有するスレッドを立てるのも良いかもしれません。
