问题：在多站点实例中大规模导入后，Sidekiq 处理速度极慢

支持
1

我们运行了几个 Discourse 站点，使用 multisite 在单个应用程序下进行管理。最近，我们进行了一批大规模的用户导入（跨 6 个站点导入了数十万用户）。导入后，Sidekiq 处理后台作业的速度非常慢。Sidekiq 仪表板显示积压了大量作业，并且作业清除的速度远低于预期。

环境详情：

  • VM 已升级到 16 个 CPU / 16GB RAM。
  • 然而，在 Sidekiq 界面中，我们只看到 5 个线程，并且似乎只使用了少量资源。
  • 主导入队列（“nursingjobs”作为 multisite 父级）正在处理所有子站点的作业，但作业吞吐量非常低。
  • 服务器指标：CPU 有时在 80-90%，内存约为 6.7/7.2GB。

我们的目标是：

  • 加快 Sidekiq/后台作业处理速度，以清除导入后的大量积压作业。
  • 确保 Discourse 能充分利用所有可用资源（CPU/RAM）。
  • 了解是否存在需要调整的线程/进程限制。

问题：

  1. 导入后，配置 Sidekiq/Discourse 以实现高吞吐量的最佳方法是什么？
  2. 对于大型多核系统，UNICORN_SIDEKIQS 和 DISCOURSE_SIDEKIQ_WORKERS 的推荐设置是什么？
  3. 在提高 Sidekiq 并发性时，是否有需要调整的 Postgres 或其他 app.yml 设置，以避免数据库池错误？
  4. 导入后，快速安全地清除大量 Sidekiq 积压作业的任何最佳实践？

图像显示了 Sidekick.io 仪表板，其中显示了进程计数、失败实例、延迟以及三个带有删除选项的队列任务。(由 AI 标注)
图像显示了 Sidekick.io 仪表板，其中显示了进程计数、失败实例、延迟以及三个带有删除选项的队列任务。(由 AI 标注)1920×590 139 KB

如果需要，可提供 Sidekiq 统计数据/截图！

3

对于所有这些问题的答案，大致上就是提高 DISCOURSE_SIDEKIQ_WORKERS。

我建议将其调高到大约 32，因为你知道你有很多备用的 CPU 资源。如果经过一段时间后，你仍然有大量的 CPU 资源剩余，随时可以将其调得更高。

在正常操作时，你可能可以将其调低到，比如说 8 或 12。

确保你的 max_connections 在 Postgres 中足够。你可能已经因为运行多站点而将其提高，但还是要注意监控。

2 个赞
4

感谢 @supermathie，现在可以正常工作了。
我已将配置更新为如下：

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

并增加了 CPU 到

8vCPU
16GB 内存
1 个赞