每个 CPU 独角兽进程的最佳数量

Question

我们正在 Unicorn 下运行 Ruby on Rails 网络应用程序。我们的应用程序不受 CPU 限制（我们有一个双 Xeon E5645 系统，带有 12 个内核，峰值负载平均值约为 6）。我们最初有 40 个 Unicorn 工作人员，但随着时间的推移，应用程序内存占用量增加。所以，现在我们必须减少工作进程的数量。我认为标准（CPU 内核数 + 1）公式也适用于 Unicorn，但我的同事试图说服我我们应该为每个 CPU 保留更多 Unicorn 实例并提供此链接。然而，我不确定为什么我们需要在空闲的 Unicorn 进程上花费这么多内存。

我的问题是：每个 CPU 内核有多个 Unicorn 实例的原因是什么？是因为 Unicorn 的一些建筑特性吗？我知道忙碌的 Unicorn 进程无法接受新连接（顺便说一句，我们使用 UNIX 域套接字与 Unicorn 实例进行通信），但我认为引入 backlog 正是为了解决这个问题。无论如何，是否有可能克服每个 CPU 规则的 2 到 8 个 Unicorn 实例？

Answer 1

好的，我终于找到了答案。Unicorn worker 的最佳数量与 CPU 内核数量没有直接关系，它取决于您的负载和内部应用程序结构/响应能力。基本上我们使用采样分析器来确定工人的状态，我们尽量让工人保持 70% 的空闲和 30% 的实际工作。因此，70% 的样本应该是“等待 select() 调用以获取来自前端服务器的请求”。我们的研究表明，worker 只有 3 种有效状态：0-30% 的样本空闲，30-50% 的样本空闲和 50-70% 的样本空闲（是的，我们可以获得更多的空闲样本，但有不是真正的重点，因为应用程序响应没有显着变化）。我们将 0-30% 的情况视为“红色区域”，将 30-50% 的情况视为“黄色区域”。

Answer 2

对于 CPU 密集型作业，您说的对 N+1 是正确的。

另一方面，独角兽不使用线程，因此每个 IO 操作。阻止进程，另一个进程可能会启动并解析 HTTP 标头、连接字符串并执行为用户提供服务所需的每个 CPU 密集型任务（提前执行以减少请求延迟）。

并且您可能希望拥有比内核更多的线程/进程。想象以下情况：req。A 需要十倍于 req。B，你有几个并发的 A 请求，快速 B 请求只是排队等待 A-req 完成。因此，如果您可以预测大量请求的数量，则可以使用此数量作为调整系统的另一个指南。