mysql - 很难根据允许的最大连接数正确设置 RAILS_MAX_THREADS

Question

我很难理解我必须做的数学运算才能找出 RAILS_MAX_THREADS 的正确数字基于我的基础设施。
我正在使用多容器来托管接受 HTTP 请求的 API 副本和运行 sidekiq(作业处理)的 API 副本。我使用的数据库的 max_connections 为 45。话虽如此，RAILS_MAX_THREADS 的数量应该是多少？ ?我正在为 RAILS_MAX_THREADS 使用 9和 WEB_CONCURRENCY .我阅读了一些关于它的文章，但我无法完全理解它。

Answer 1

即使你不使用 heroku，Heroku 的 puma sizing 文档也是最好的。
https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server
在他们说“dyno”的地方，对于非 Heroku 部署，您可以只阅读“主机”、“虚拟机”或“容器”。
如果您使用 9 表示 RAILS_MAX_THREADS和 WEB_CONCURRENCY ，并且您的 heroku 配置设置为以正常方式使用这些设置——那么每个主机将运行 9 个 puma 工作线程( WEB_CONCURRENCY )，每个工作线程将运行 9 个线程( RAILS_MAX_THREADS )，总共9*9=81 线程。
您确实需要为每个线程提供足够的数据库连接，因此您的 45 个数据库连接已经增加了近 2 倍。这仅适用于一个容器——如果你正在运行多个容器，每个容器都有这些设置，而不是将 81 乘以容器的数量——所以这对于你的数据库连接来说太多了!
因此，如果您无法更改最大数据库连接数，这是一个硬性限制，您需要减少数量。
否则，主要的限制因素是每个容器中有多少可用内存，以及多少 vCPU。理想情况下，您在容器 ( WEB_CONCURRENCY ) 上至少运行与 vCPU 一样多的工作程序——如果您有足够的 RAM 来执行此操作。 worker 占用大量内存。通常没有理由运行比 vCPU 多的工作线程，因此 9 是否有意义或是否大于所需取决于您的基础架构。
每个工作线程的最佳数量( RAILS_MAX_THREADS )取决于您的应用程序正在做什么，但作为一个好的经验法则，您可以从 5 开始。通常，9 可能比有用的多。
所以我会尝试 RAILS_MAX_THREADS 3-5。然后尽可能多的 WEB_CONCURRENCY 在不耗尽 RAM 的情况下(要查看应用程序在加载一段时间后将占用多少 RAM，您可能需要让它保持加载一段时间)。只要容器 * RAILS_MAX_THREADS * WEB_CONCURRENCY 小于您的数据库最大连接数 - 如果不是，请减少您的值，或者增加您的数据库最大连接数。