Sidekiq ワーカーのデータベースプーリングについて、どなたか明確な説明をいただけますでしょうか？
現在、DISCOURSE_DB_POOL を 15 に設定しており、Sidekiq ワーカーはそれぞれ 10 の同時実行性を持つ 2 つのワーカーがあります。Sidekiq のドキュメントを読んだところ、Sidekiq スレッドは DB プールを共有するとのことなので、Sidekiq ワーカーから最大 15 * 2 = 30 の DB 接続が発生すると予想されます。しかし、この理解にもかかわらず、予想される最大 30 を超える DB 接続のスパイクが観測されています。
これらのスパイクは約 15 分ごとに発生し、主に PeriodicalUpdates スケジュールジョブに関連しているようです。
これらのスパイクを回避するのに役立つ洞察をどなたか提供していただけますでしょうか？
@david この分野で素晴らしい功績を上げられていることに気づきました。何か洞察をいただけますでしょうか？
申し訳ありませんが、これがどのように機能するかについての詳細はすぐにはわかりません。
UNICORN_SIDEKIQS 環境変数をカスタマイズしたかどうかを確認する価値があるかもしれません。これは、起動されるサイドキック プロセス の数を示します（それぞれに多くのスレッドがあります）。
グラフには具体的に何が表示されていますか？「同時接続数」ですか？それとも「作成された接続数」ですか？後者の場合、接続が非常に迅速に作成および破棄されている可能性があります。
そして最後の質問ですが、ここでどのような問題を解決しようとしていますか？接続数によって問題が発生していますか？
ご連絡ありがとうございます。
以下に関連する設定を示します。
これは、それぞれ10スレッドを持つ2つのSidekiqプロセスがあることを意味します。
グラフは、現在のクライアント接続数を示しています。
(PostgreSQLの前面にあるRDSプロキシ)の接続プールサイズを正しく設定しようとしています。そのために、アプリケーション側の接続プーリングについてより深く理解する必要があります。なぜアプリケーションは期待どおりにDISCOURSE_DB_POOL設定を尊重しないのでしょうか？
DISCOURSE_DB_POOLが期待どおりに機能している場合、なぜDB接続にそのような大きなスパイクが見られるのでしょうか？これらのスパイクは、PeriodicalUpdatesスケジュールジョブの実行と一致しているようです。
他に質問があればお知らせください。この謎を解明するお手伝いに感謝します。
データベースプーリングを設定するために、DISCOURSE_DB_POOL 環境変数以外に設定ファイルは必要ですか？
プロキシに100％問題がないと確信していますか？
はい、ここではプロキシに問題があるとは思いません。
