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

Question

我们正在运行一个Rails应用程序，在Unicorn下运行。我们的应用程序没有严格的CPU限制(我们有一个双Xeon E5645系统w/12核，峰值负载平均值在6左右)。我们最初是从40个Unicorn员工开始的，但随着时间的推移，应用程序内存占用增加了。因此，现在我们必须降低工作进程的数量。我认为标准( CPU核数+ 1)公式也适用于Unicorn，但我的同事试图说服我，我们应该为每个CPU保留更多的Unicorn实例，并提供了此链接。然而，我不太清楚为什么我们需要把这么多内存花在空闲的Unicorn进程上。

我的问题是:每个CPU内核有多个Unicorn实例的原因是什么？是因为独角兽的建筑特色吗？我知道繁忙的Unicorn进程不能接受新的连接(我们使用UNIX域套接字与Unicorn实例BTW通信)，但我认为引入待办事项正正是为了解决这个问题。是否有可能克服每个CPU规则的2到8个Unicorn实例？

Answer 1

好吧，我终于找到答案了。Unicorn工作人员的最佳数量并不直接连接到CPU核心的数量，这取决于您的负载和内部应用程序结构/响应能力。基本上，我们使用抽样分析器来确定工人的状态，我们试图使70%的工人空闲，30%的人从事实际工作。因此，70%的示例应该“等待select()调用从前端服务器获得请求”。我们的研究表明，只有3种工作人员的有效状态: 0-30%的样本闲置，30-50%的样本闲置，50-70%的样本闲置(是的，我们可以获得更多的空闲样本，但由于应用响应没有显著变化，其中没有真正的意义)。我们认为0-30%的情况是“红区”，30-50%的情况是“黄区”。

Answer 2

关于面向CPU的作业，N+1是正确的。

另一方面，独角兽不使用线程，所以每个IO操作。阻塞进程和另一个进程可能会启动和解析HTTP报头，连接字符串，并执行为用户服务所需的每一个CPU密集型任务(更早地这样做，以减少请求延迟)。

您可能希望有更多的线程/进程，而不是核心。想象一下以下情况: req。A比雷克多十倍。B，您有几个并发的A请求，而快速B请求只是排队等待A-req完成。因此，如果您可以预测大量请求的数量，您可以使用这个数字作为另一个准则来调优系统。