我已经阅读了所有我能在Heroku上找到的关于Puma和dyno类型的文章，但我无法得到一个直接的答案。
我看到有人提到Puma工人的数量应该由核心的数量决定。我找不到任何Heroku显示性能- m或性能- l动态有多少内核的地方。
在这篇文章中，Heroku暗示了一种方法:https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server我认为他们建议将线程设置为1，并增加Puma工作线程的数量，直到你开始看到R14(内存)错误，然后退出。然后增加线程的数量，直到CPU达到最大值，尽管我不认为Heroku报告CPU利用率。
有人能提供指导吗?
(我也想决定是否应该使用一个性能- l或多个性能- m dynos，但我认为一旦我弄清楚如何设置工人，这将是清楚的;线程)
我目前的路线图是这样的:
-
heroku run "cat /proc/cpuinfo" --size performance-m --app yourapp -
heroku run "cat /proc/cpuinfo" --size performance-l --app yourapp - 写下你拥有的进程信息
- 搜索英特尔处理器的型号类型，系列，型号，步数，并查找该处理器有多少核心或模拟。
- 看看这个https://devcenter.heroku.com/articles/dynos#process-thread-limits
- 用
standard-2X/standard-1X做一些小实验来测定PUMA_WORKER的值。 - 像这样计算:
(Max Threads of your desired dyno type could support) / (Max Threads of baseline dyno could support) x (Your experiment `PUMA_WORKER` value on baseline dyno) - (Number of CPU core)
例如，如果PUMA_WORKER在我的standard-2X动态上为3作为基准，那么performance-m上的PUMA_WORKER数字将开始测试它:
你还应该考虑你的应用程序消耗了多少内存，并选择最低的内存。
EDIT:以前我的答案是在ps:exec可用之前写的。您可以阅读官方文档，了解如何ssh进入正在运行的动态服务器。这应该比以前容易多了。
目前在AWS的生产环境中运行的应用程序面临同样的问题(我们正在使用ECS)，并试图定义两者之间的良好匹配:
- 每个实例的vCPU/Ram数量
- 实例数
- 每个实例运行的puma_threads数(每个实例有一个puma进程)
为了更好地理解我们的应用程序是如何使用puma_threads池的，我们做了以下操作:
- 将puma指标导出到cloudwatch(线程运行+积压)，然后我们看到大约有15个并发线程，积压开始增长
- 将其与vCPU(使用率)进行比较，我们看到我们的vCPU从未超过25%
综合这两个信息，我们决定采取上述行动。
最后我想分享这篇文章，我发现关于这个话题非常有趣。