我喜欢node.js'的偶数模型,但它只需要你到目前为止 - 当你有一个函数(比如,HTTP连接的请求处理程序)在CPU上做了很多繁重的工作时,它仍然是“阻塞的” “直到它的功能恢复。这是可以预料的。但是,如果我想稍微平衡一下这一点,那么使用操作系统调度进程的能力,给定的请求需要更长的时间来处理但整体响应时间更短?
我的生产代码使用节点非常简单的集群模块来分叉许多工作人员,这些工作人员的数量等于系统CPU的核心数量。分叉比这还要糟糕 - 每个核心可能有两三个工人?我知道这里会有内存开销,但内存不是我的限制。我所做的阅读提到你要避免“超额订阅”,但在现代系统中你肯定不会因为有两三个进程在处理器上争夺时间而疯狂。
答案 0 :(得分:3)
我认为你的想法听起来不错;特别是因为许多处理器支持hyperthreading。超线程不神奇,并且不会突然使应用程序的速度或吞吐量翻倍,但当第一个线程需要时,可以有意义让另一个线程准备好在核心中执行等待内存请求被填满。
启动多个工作人员时要小心:Linux内核确实更喜欢在同一处理器上保持进程在整个生命周期内执行以提供强大的缓存关联。这足够了。但是我看到几个渴望CPU的进程争夺单个核心或更糟糕的单个超线程实例,而不是系统重新平衡所有核心或所有兄弟的进程。运行ps -eo pid,psr,comm
(或您喜欢的ps(1)
命令,检查处理器的亲和力;添加psr
列。
要解决此问题,您可能希望以明显有限的CPU亲和力启动您的工作人员:
taskset -c 0,1 node worker 1
taskset -c 2,3 node worker 2
taskset -c 4,5 node worker 3
taskset -c 6,7 node worker 4
或许也可以开始八个,每个HT兄弟一个,或八个并将每一个限制在他们自己的一组CPU中,或者可能是十六个,每个核心限制四个或每个兄弟两个等等(你可以坚持尝试微观管理。如果可以的话,我建议保持简单。)有关详细信息,请参阅taskset(1)
联机帮助页。