问题 我有一个运行数百个 sidekiq 后台进程的 Rails 应用程序。它们都连接到一个 PostgreSQL 数据库，该数据库不太愿意提供 250 个连接——它可以，但如果所有 sidekiq 进程不小心向数据库发送查询，它就会崩溃。
选项 1 我一直在考虑在数据库前面添加 pgBouncer，但是我目前无法使用它的事务模式，因为我高度依赖于设置 search_path 在每个作业处理开始时确定要在哪个“国家”(PostgreSQL 模式)上工作(公寓 gem )。在这种情况下，我将不得不使用基于 session 的连接池模式。然而，据我所知，这将要求我在每次作业处理后断开连接，将连接释放回池中，这在性能方面会非常昂贵，不是吗？我错过了什么吗？
选项 2 使用基于应用程序层的连接池当然也是一个选项，但是我不太确定如何使用 sidekiq 为 PostgreSQL 做到这一点？
选项 3 是我没想到的？
最佳答案
选项 1:您是对的， session 需要您断开并重新连接，这会增加开销。成本如何取决于访问模式，即连接/tcp 握手等占完成的总工作的多少以及您需要什么样的延迟。绝对值得进行基准测试，但如果连接时间很短，那么开销将非常明显。
选项 2/3:您可以限制或限制您的 sidekiq 作业。这里有一些项目正在解决这个问题......
队列限制
- Sidekiq Limit Fetch :限制能够同时运行指定队列的工作人员数量。您可以暂停队列并动态调整队列分布。还跟踪每个队列的事件工作人员数量。支持全局模式(多个 sidekiq 进程)。还有一个额外的阻塞队列模式。
- Sidekiq Throttler : Sidekiq::Throttler 是 Sidekiq 的中间件，它增加了在每个工作人员的基础上对作业执行进行速率限制的能力。
- sidekiq-rate-limiter : Redis 支持，每个 worker 的作业处理速率限制。
- Sidekiq::Throttled : 并发和阈值限制。
我从这里得到了上面的内容
https://github.com/mperham/sidekiq/wiki/Related-Projects
如果您的应用程序每个进程必须有一个连接，并且您无法在更多线程可以使用连接的地方将其分解，那么它就是 pgBouncer 或基于应用程序的连接池。连接池实际上会以某种方式节流或限制您的应用程序以节省数据库。
关于postgresql - 如何管理从 sidekiq 到 PostgreSQL 的连接池？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/36096563/