I’m seeking some expert guidance on optimizing a Discourse multisite setup. I have a single web VM and a separate database VM on a major cloud provider. While both machines have decent specs, I’m finding that my system gets overwhelmed by a large volume of background jobs, which seems to be stressing the database. My current app.yml configuration is: UNICORN_WORKERS: 4 UNICORN_SIDEKIQS: 4 DISCOURSE_SIDEKIQ_WORKERS: 10 DISCOURSE_DB_POOL: 8 Based on my observations, the bottleneck isn’t hitting a hard connection limit, but rather the sheer volume of jobs competing for database resources at the same time. The queues in Sidekiq are constantly backing up, which makes the site feel slow, even for basic administrative tasks. I’m looking for a generic approach to tune the system for stability and performance. Specifically, I’d like to understand the best practices for: Sidekiq Concurrency: How should DISCOURSE_SIDEKIQ_WORKERS be sized in a multisite environment to handle a high job volume without stressing the database? Queue Separation: Is it recommended to run separate Sidekiq processes to handle different queues (e.g., critical vs. low priority)? This would ensure that heavy jobs don’t block more urgent ones. I’m not looking for a solution that requires a major architectural change or moving to a different web server at this time, as I want to keep the process as simple and low-risk as possible. I’m hoping to get advice on a safe and effective path forward. Thanks!

Discourse should be able to adapt those based on your system resources. Note that it is safe to re-run ./discourse-setup script if you have recently increased your system resources. The script can adapt to the increased resources and adjust your .yml accordingly

[画像] emonunix: How should DISCOURSE_SIDEKIQ_WORKERS be sized in a multisite environment to handle a high job volume without stressing the database? Sounds like you need fewer? I’m pretty sure that it already knows to prioritize the high priority jobs.

@itsbhanusharma @pfaffman Thanks for your help. I appreciate you both taking the time to share your expertise.

[画像] emonunix: database resources at the same time If the database is the bottleneck, have you considered moving to larger instance type for your cloud database?

Discourse Multisite の最適化：データベースと Sidekiq のボトルネック

製品サポートインストール

Falco (Falco) 2025 年 9 月 22 日午後 5:04 5

データベースがボトルネックになっている場合、クラウドデータベースのインスタンスタイプを大きくすることを検討しましたか？

トピック		返信	表示
Issue: Extremely Slow Sidekiq Processing After Large Imports on Multisite Instance Product Support	2	229	2025 年 4 月 23 日
UNICORN_WORKERS vs UNICORN_SIDEKIQS, DISCOURSE_DB_POOL? Self-hosting	6	2782	2020 年 2 月 23 日
How to adjust parameters for large and heavy traffic site? Product Support	4	614	2022 年 3 月 11 日
Multiple discourse instances in a single server Product Support	5	4897	2018 年 5 月 30 日
Large number of queued jobs Product Support	5	1689	2017 年 7 月 3 日

Discourse Multisite の最適化：データベースと Sidekiq のボトルネック

関連トピック