問題: マルチサイトインスタンスでの大量インポート後、Sidekiq処理が極端に遅くなる

[emonunix (Emon Bhuiyan)]

単一のアプリケーションでマルチサイトを実行している複数のDiscourseサイトを運用しています。最近、大規模なユーザーインポート（6サイト全体で数十万人のユーザー）を行いました。インポート後、Sidekiqのバックグラウンドジョブ処理が非常に遅くなっています。Sidekiqダッシュボードには大量のバックログが表示され、ジョブのクリア率が予想よりもはるかに低くなっています。

環境の詳細:

• VMは16CPU / 16GB RAMにアップグレードされました。
• しかし、Sidekiqインターフェースでは、スレッドが5つしか表示されず、リソースのごく一部しか使用されていないようです。
• メインのインポートキュー（マルチサイトの親として「nursingjobs」）はすべての子サイトのジョブを処理していますが、ジョブのスループットは非常に低いです。
• サーバーメトリクス：CPUは時々80〜90％、メモリは約6.7 / 7.2GBです。

求めていること:

• インポート後の大規模なバックログをクリアするために、Sidekiq /バックグラウンドジョブ処理を高速化する。
• Discourseが利用可能なすべてのリソース（CPU / RAM）を活用していることを確認する。
• 調整が必要なスレッド/プロセスの制限があるかどうかを理解する。

質問:

1. インポート後の高スループットのために、Sidekiq / Discourseを構成する最良の方法は何ですか？
2. 大規模なマルチコアシステムでのUNICORN_SIDEKIQSおよびDISCOURSE_SIDEKIQ_WORKERSの推奨設定は何ですか？
3. Sidekiqの同時実行数を増やす際に、DBプールエラーを回避するために調整すべきPostgresまたはその他のapp.yml設定はありますか？
4. インポート後に大規模なSidekiqバックログを迅速かつ安全にクリアするためのベストプラクティスはありますか？

Sidekiqの統計/スクリーンショットは、必要であれば利用可能です！

[supermathie (Michael Brown)]

これらのすべての質問の答えは、より多くの場合、DISCOURSE_SIDEKIQ_WORKERSを増やすことです。

おそらく32に設定するのが良いでしょう。これは、あなたが多くの空きCPUを持っていることを知っているからです。その後もしばらく動作させてもまだたくさんのCPUが利用可能であれば、もっと増やしても構いません。

通常の運用には、例えば8や12に戻すのも良いでしょう。

PostgreSQLのmax_connectionsが十分であることを確認してください。マルチサイトを運営しているので、すでに引き上げていると思いますが、注意してください。

[emonunix (Emon Bhuiyan)]

@supermathie ありがとうございます。動作するようになりました。
config を以下のように更新しました。

  UNICORN_WORKERS: 8
  UNICORN_SIDEKIQS: 7
  DISCOURSE_SIDEKIQ_WORKERS: 10
  DISCOURSE_DB_POOL: 20

CPU を以下のように増やしました。

8vCPU
16GB Memory