为了利用 Node.js 中的多处理器，为什么我们 fork 的集群数量是 CPU 核心数？答案

【问题标题】：To take Advantage of Multi-Processor in Node.js, why the number of clusters we fork is CPU cores count?为了利用 Node.js 中的多处理器，为什么我们 fork 的集群数量是 CPU 核心数？
【发布时间】：2020-06-05 21:05:30
【问题描述】：

我知道这可能是个愚蠢的问题。我不擅长操作系统知识。

通常我们 fork 的集群/进程的数量是 CPU 内核数，例如 Nodejs offical Doc 显示。

const cluster = require('cluster');
const http = require('http');
const numCPUs = require('os').cpus().length;

if (cluster.isMaster) {
  console.log(`Master ${process.pid} is running`);

  // Fork workers.
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`worker ${worker.process.pid} died`);
  });
} else {
  // Workers can share any TCP connection
  // In this case it is an HTTP server
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end('hello world\n');
  }).listen(8000);

  console.log(`Worker ${process.pid} started`);
}

但我很困惑，如果我们将集群分叉的数量超过 CPU 内核的数量，会发生什么？

是经验值、最佳实践还是其他原因？

【问题讨论】：

标签： node.js express operating-system v8

【解决方案1】：

但我很困惑，如果我们将集群分叉的数量超过 CPU 内核的数量，会发生什么？

什么都不会发生，一切都会继续工作，但是每个内核放置多个 CPU 密集型线程或进程不会使应用程序更快 - 如果有的话，它可能只会让速度变慢，因为内核会浪费一部分上下文的时间在线程之间切换。

如果您有 CPU 密集型操作，那么每个内核的最佳线程/进程数始终为 1。对于 I/O 密集型操作来说，这并不重要，因为大多数情况下进程不会进行任何计算.

【讨论】：

这很有趣。我想知道如果你有阻塞代码，是否还有一个应用程序可以使用比核心更多的分支？鉴于每个 fork 都有自己的事件循环，在减少阻塞代码对其他请求的影响方面是否有一些好处？

【解决方案2】：

考虑一个理想的情况，您在系统中运行的所有东西都是基于节点的应用程序服务器。

这是不切实际的，因为您的机器上至少要运行 5-10 个进程来维护您的系统环境。

还假设事件循环线程（又名应用程序线程，又名主线程）是在 node.js 进程中执行最有用工作的线程。

同样，这不是真的，因为 node.js 进程中很少有辅助线程来维护异步事件驱动的编程模型。

再次假设通过连接的客户端测量的服务器吞吐量是每个进程如何能够利用空闲 CPU 的直接函数，并且作为请求-响应周期的一部分，进程执行的所有操作都是纯粹受 CPU 限制。

这可能是也可能不是 TRUE。如果服务器与外部服务器（如 DB、Web 服务等）有进一步的连接，它们会在 I/O 通道中启动，然后线程继续处理其他请求。但是由于所有的 I/O 操作都是非阻塞的，并且所有潜在的阻塞操作都是异步的，所以主线程将相对只运行 CPU 绑定的操作，整个电路中只有一个阻塞调用 - 轮询没有就绪 I/O 时阻塞的函数。

Cluster 模块建议使用 # of CPUs 作为集群成员计数，假设上述假设场景，在没有任何更好和全面的推理的情况下，它提供了相对最佳的性能。

希望这会有所帮助。

【讨论】：