我们正在Unicorn下运行Ruby on Rails网络应用程序。我们的应用程序不受CPU的严格限制（我们有一个双核Xeon E5645系统，带12个内核，峰值平均负载约为6）。我们最初从40名Unicorn工人开始，但随着时间的推移，应用程序内存占用量增加了。因此，现在我们必须减少工作进程的数量。我认为标准（CPU内核数+ 1）公式也适用于Unicorn，但是我的同事试图说服我我们应该为每个CPU保留更多Unicorn实例，并提供此链接。但是，我不确定，为什么我们需要在空闲的Unicorn进程上花费这么多的内存。
我的问题是：每个CPU内核拥有一个以上Unicorn实例的原因是什么？是由于独角兽的某些建筑特色吗？我知道繁忙的Unicorn进程无法接受新的连接（我们正在使用UNIX域套接字来与Unicorn实例BTW通信），但是我认为引入积压就是为了解决这个问题。是否有可能克服每个CPU规则2至8个Unicorn实例？
Answers:
好的，我终于找到了答案。独角兽工人的最佳数量并不直接与CPU内核的数量有关，它取决于您的负载和内部应用程序的结构/响应能力。基本上，我们使用抽样探查器来确定工人的状态，我们试图使工人保持70％的闲置率和30％的工人实际工作。因此，样本中的70％应该是“正在等待select（）调用以从前端服务器获取请求”。我们的研究表明，只有三种有效的工作状态：0-30％的样本处于空闲状态，30-50％的样本处于空闲状态，50-70％的样本处于空闲状态（是的，我们可以获得更多的空闲样本这并不是真正的意义，因为应用程序的响应能力不会发生明显变化）。我们将0-30％的情况视为“红色区域”，将30-50％的情况视为“黄色区域”。
对于CPU绑定的作业，您说的是N + 1。
另一方面，独角兽不使用线程，因此每个IO操作。阻止该进程，另一个进程可能会启动并解析HTTP标头，连接字符串并执行服务用户所需的每个CPU密集型任务（尽早执行以减少请求延迟）。
而且您可能想要比核心更多的线程/进程。想象以下情况：req。A比要求多十倍。B，您有几个并发的A请求，而快速B请求只是排队等待A-req完成。因此，如果您可以预测大量请求，则可以将此数字用作调整系统的另一条准则。