能否有人澄清一下 Sidekiq worker 数据库连接池的问题？
目前，我们已将 DISCOURSE_DB_POOL 设置为 15，每个 Sidekiq worker 的并发数为 10。在阅读了 Sidekiq 文档后，似乎 Sidekiq 线程共享数据库连接池，因此我预计 Sidekiq worker 最多会产生 15 * 2 = 30 个数据库连接。然而，尽管我们有这样的理解，但我们观察到数据库连接的峰值超过了预期的最大值 30。
这些峰值大约每 15 分钟出现一次，并且似乎主要与 PeriodicalUpdates 计划任务相关。
谁能提供一些见解来帮助我们避免这些峰值？
@david 我注意到您在这方面做了出色的工作。您能分享一些见解吗？
恐怕我不知道所有这些细节是如何运作的。
也许可以检查一下您是否自定义了 UNICORN_SIDEKIQS 环境变量。这表明启动了多少个 sidekiq 进程（每个进程都会有很多线程）。
您的图表具体显示的是什么？是“并发连接”吗？还是“创建的连接数”？如果是后者，也许一些连接被创建和销毁得非常快。
最后一个问题：您在这里试图解决什么问题？连接数是否引起了什么问题？
感谢您的回复。
以下是我们相关的配置：
这意味着我们有 2 个 Sidekiq 进程，每个进程有 10 个线程。
图表显示了当前的客户端连接数。
我们正在尝试正确配置连接池的大小（位于 PostgreSQL 前面的 RDS 代理）。为此，我们需要更好地了解应用程序端连接池的工作原理。为什么应用程序没有按预期遵守 DISCOURSE_DB_POOL 配置？
如果 DISCOURSE_DB_POOL 按预期工作，为什么我们会看到如此大的数据库连接峰值？这些峰值似乎与 PeriodicalUpdates 计划作业的运行时间一致。
如果您有更多问题，请告知我。感谢您帮助揭开这个谜团。
除了 DISCOURSE_DB_POOL 环境变量之外，我们还需要其他配置文件来配置数据库连接池吗？
您能100%确定是代理的错吗？
是的，我不认为代理服务器在这里有问题。
