ログで一貫してこれが発生しています。値は 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のバグか、何らかのより大きな問題を示しています。
ログはありますか？
「いいね！」 1
Ed_S
(Ed S)
4
カーネル設定の変更後、サーバーを再起動しましたか？
lscpu
も役立つかもしれません
Falco
(Falco)
5
UNICORN_SIDEKIQSをそれほど高く設定しないでください。ワーカーのみを増やしてください。
これは決して起こるべきではありません。
考えられる原因は以下の通りです。
- リソースが不足している
a) サイトがサーバーリソースを超えて成長した
b) リソースの割り当てを誤っている
- スタックにバグがある
まず、以下のように設定してみてください。
UNICORN_SIDEKIQS: 1
DISCOURSE_SIDEKIQ_WORKERS: 20
これにより、サーバーからRAMが解放されるはずです。
さらに詳しい情報が必要な場合は、問題のジョブをPostgreSQLコンソールで実行し、ボトルネックが何であるかを報告してください。
