我们正在 Unicorn 下运行 Ruby on Rails Web 应用程序。我们的应用程序并不严格受限于 CPU（我们有一个双 Xeon E5645 系统，带 12 个内核，峰值负载平均值约为 6）。我们最初使用 40 个 Unicorn 工作进程，但应用程序内存占用量随着时间的推移而增加。因此，现在我们必须减少工作进程的数量。我认为标准（CPU 内核数 + 1）公式也适用于 Unicorn，但我的同事试图说服我，我们应该为每个 CPU 保留更多 Unicorn 实例，并提供此链接。但是，我并不完全清楚为什么我们需要在空闲的 Unicorn 进程上花费这么多内存。
我的问题是：每个 CPU 核心有多个 Unicorn 实例的原因是什么？是因为 Unicorn 的一些架构特性吗？我知道繁忙的 Unicorn 进程无法接受新连接（顺便说一下，我们使用 UNIX 域套接字与 Unicorn 实例通信），但我认为 backlog 就是为了解决这个问题而引入的。无论如何，是否有可能克服这个每个 CPU 2 到 8 个 Unicorn 实例的规则？
答案1
好的，我终于找到了答案。Unicorn 工作器的最佳数量与 CPU 核心数量没有直接关系，它取决于您的负载和内部应用程序结构/响应能力。基本上，我们使用采样分析器来确定工作器的状态，我们尝试让工作器 70% 处于空闲状态，30% 处于实际工作状态。因此，70% 的样本应该是“等待 select() 调用以获取来自前端服务器的请求”。我们的研究表明，工作器只有 3 种有效状态：0-30% 的样本处于空闲状态，30-50% 的样本处于空闲状态，50-70% 的样本处于空闲状态（是的，我们可以获得更多空闲样本，但这样做没有实际意义，因为应用程序响应能力不会发生显着变化）。我们认为 0-30% 的情况为“红色区域”，30-50% 的情况为“黄色区域”。
答案2
对于 CPU 密集型作业，您关于 N+1 的说法是正确的。
另一方面，unicorn 不使用线程，因此每个 IO 操作都会阻塞该进程，而另一个进程可能会启动并解析 HTTP 标头、连接字符串并执行为用户服务所需的每个 CPU 密集型任务（尽早执行以减少请求延迟）。
您可能希望拥有比核心更多的线程/进程。想象一下以下情况：请求 A 比请求 B 多花费十倍的时间，您有几个并发的 A 请求，而快速的 B 请求只是排队等待 A 请求完成。因此，如果您可以预测繁重请求的数量，则可以将此数字用作调整系统的另一个指导方针。