ChatGPT解决这个技术问题 Extra ChatGPT

Node.js on multi-core machines

Node.js looks interesting, BUT I must miss something - isn't Node.js tuned only to run on a single process and thread?

Then how does it scale for multi-core CPUs and multi-CPU servers? After all, it is all great to make fast as possible single-thread server, but for high loads I would want to use several CPUs. And the same goes for making applications faster - seems today the way is use multiple CPUs and parallelize the tasks.

How does Node.js fit into this picture? Is its idea to somehow distribute multiple instances or what?

It looks like Ryah is starting to get serious about including built-in multi-core support in node: github.com/joyent/node/commit/…
PM2 process manager use cluster module internally to spread your NodeJS apps to all cores available : github.com/Unitech/pm2
@broofa, Those are not real threads and child processes have no shared memory. Also see What's the Nodejs equivalent of Java's real threading and volatile-static variables?.

C
Community

[This post is up-to-date as of 2012-09-02 (newer than above).]

Node.js absolutely does scale on multi-core machines.

Yes, Node.js is one-thread-per-process. This is a very deliberate design decision and eliminates the need to deal with locking semantics. If you don't agree with this, you probably don't yet realize just how insanely hard it is to debug multi-threaded code. For a deeper explanation of the Node.js process model and why it works this way (and why it will NEVER support multiple threads), read my other post.

So how do I take advantage of my 16 core box?

Two ways:

For big heavy compute tasks like image encoding, Node.js can fire up child processes or send messages to additional worker processes. In this design, you'd have one thread managing the flow of events and N processes doing heavy compute tasks and chewing up the other 15 CPUs.

For scaling throughput on a webservice, you should run multiple Node.js servers on one box, one per core and split request traffic between them. This provides excellent CPU-affinity and will scale throughput nearly linearly with core count.

Scaling throughput on a webservice

Since v6.0.X Node.js has included the cluster module straight out of the box, which makes it easy to set up multiple node workers that can listen on a single port. Note that this is NOT the same as the older learnboost "cluster" module available through npm.

if (cluster.isMaster) {
  // Fork workers.
  for (var i = 0; i < numCPUs; i++) {
    cluster.fork();
  }
} else {
  http.Server(function(req, res) { ... }).listen(8000);
}

Workers will compete to accept new connections, and the least loaded process is most likely to win. It works pretty well and can scale up throughput quite well on a multi-core box.

If you have enough load to care about multiple cores, then you are going to want to do a few more things too:

Run your Node.js service behind a web-proxy like Nginx or Apache - something that can do connection throttling (unless you want overload conditions to bring the box down completely), rewrite URLs, serve static content, and proxy other sub-services. Periodically recycle your worker processes. For a long-running process, even a small memory leak will eventually add up. Setup log collection / monitoring

PS: There's a discussion between Aaron and Christopher in the comments of another post (as of this writing, its the top post). A few comments on that:

A shared socket model is very convenient for allowing multiple processes to listen on a single port and compete to accept new connections. Conceptually, you could think of preforked Apache doing this with the significant caveat that each process will only accept a single connection and then die. The efficiency loss for Apache is in the overhead of forking new processes and has nothing to do with the socket operations.

For Node.js, having N workers compete on a single socket is an extremely reasonable solution. The alternative is to set up an on-box front-end like Nginx and have that proxy traffic to the individual workers, alternating between workers for assigning new connections. The two solutions have very similar performance characteristics. And since, as I mentioned above, you will likely want to have Nginx (or an alternative) fronting your node service anyways, the choice here is really between:

Shared Ports: nginx (port 80) --> Node_workers x N (sharing port 3000 w/ Cluster)

vs

Individual Ports: nginx (port 80) --> {Node_worker (port 3000), Node_worker (port 3001), Node_worker (port 3002), Node_worker (port 3003) ...}

There are arguably some benefits to the individual ports setup (potential to have less coupling between processes, have more sophisticated load-balancing decisions, etc.), but it is definitely more work to set up and the built-in cluster module is a low-complexity alternative that works for most people.


can you offer any advice for running different nodejs based services on one box? E.g. Say I have 1 server, and want to run myservice1.js on CpuCore1, and myservice2.js on CpuCore2. Can I use cluster for this? or is it only useful for creating cloned services?
You should post a question for that! (and I'll copy this comment over as your 1st answer). What you are wanting to do is actually really really simple. You wouldn't really need "cluster", you'd just run two different node services. Two scripts, two processes, two ports. Eg, you could have serviceA listen on 3000 and serviceB listen on 3001. Each of those services might use "cluster" to have 1+ workers and recycle them periodically, etc. Then you could configure Nginx to listen on port 80 and to forward to the correct service based on the incoming "Host" header and / or the URL path.
Thanks. I've posted a related question already - you described pretty much what I had in mind, but I'm unsure about how to target CPU cores (when using something like forever).
Great answer ddopson. What is the best way to have two node processes communicate with each other on the same machine? Is there a faster protocol than TCP when they're on the same machine?
@Serob_b - well, yes. Running a Node.js app on multiple machines is very common. There's no library needed to do so. You just run your code on multiple machines and distribute load between them. Architecting your software so that it scales (ie, it stores state in some sort of external data service rather than keeping state in memory) - that's your job.
C
Chandra Sekar

One method would be to run multiple instances of node.js on the server and then put a load balancer (preferably a non-blocking one like nginx) in front of them.


node.js is about as fast as nginx, you could put a node.js load balancer in front of your node.js servers if you wanted to as well :)
ryan specifically said not to do this until node was more stable. Best way is to run nginx in front of node.
as for nginx in front of node, it won't solve certain problems like if you have an in-memory queue. 2 node instances will not be able to access each other's queue.
As well, nginx doesn't support HTTP 1.1 fully, so things like WebSockets can not be proxied.
@mikeal, resopollution - I'm strongly on the Nginx side. I hard-crashed Node.js multiple times (no stacktrace, just dies). I've never crashed Nginx. Nginx out-of-the-box is configured with all sorts of sane throttles. Node.js by default will continue accepting new connections in preference to serving existing ones until the box goes down... yes, the entire box; I crashed the kernel on a CentOS5 box by stress-testing Node (now THAT really isn't supposed to happen). I've come around a bit, and I see a bright future for Node, potentially including dedicated LB-type roles. Just not yet.
b
broofa

Ryan Dahl answers this question in the tech talk he gave at Google last summer. To paraphrase, "just run multiple node processes and use something sensible to allow them to communicate. e.g. sendmsg()-style IPC or traditional RPC".

If you want to get your hands dirty right away, check out the spark2 Forever module. It makes spawning multiple node processes trivially easy. It handles setting up port sharing, so they can each accept connections to the same port, and also auto-respawning if you want to make sure a process is restarted if/when it dies.

UPDATE - 10/11/11: Consensus in the node community seems to be that Cluster is now the preferred module for managing multiple node instances per machine. Forever is also worth a look.


Forever and Cluster do very different things. You might even use both. Forever restarts a process when it dies. Cluster manages multiple workers. You'd use Forever to manage your master process...
also, the learnboost module is largely supplanted by the version of Cluster baked into Node v0.6.x (warning: the API surface does differ)
@broofa How is the default IPC compared to lets say using Redis or Memcache wile just sending string/data/arrays in between processes? Which way would be faster?
@broofa, IPC has huge overheads compared to real shared memory that Java and C are capable of doing.
@Pacerier True, but shared memory only solves the problem of how to scale in the context of a single host, without addressing the macro issues needed to scale across many hosts. I.e. How to run in the Cloud.
d
dYale

You can use cluster module. Check this.

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

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

    cluster.on('exit', function(worker, code, signal) {
        console.log('worker ' + worker.process.pid + ' died');
    });
} else {
    // Workers can share any TCP connection
    // In this case its a HTTP server
    http.createServer(function(req, res) {
        res.writeHead(200);
        res.end("hello world\n");
    }).listen(8000);
}

m
maazadeeb

Node Js is supporting clustering to take full advantages of your cpu. If you are not not running it with cluster, then probably you are wasting your hardware capabilities.

Clustering in Node.js allows you to create separate processes which can share same server port. For example, if we run one HTTP server on Port 3000, it is one Server running on Single thread on single core of processor.

Code shown below allow you to cluster your application. This code is official code represented by Node.js.

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

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

    Object.keys(cluster.workers).forEach(function(id) {
        console.log("I am running with ID : " + cluster.workers[id].process.pid);
    });

    cluster.on('exit', function(worker, code, signal) {
        console.log('worker ' + worker.process.pid + ' died');
    });
} else {

    //Do further processing.
}

check this article for the full tutorial


C
CyberFonic

Multi-node harnesses all the cores that you may have.
Have a look at http://github.com/kriszyp/multi-node.

For simpler needs, you can start up multiple copies of node on different port numbers and put a load balancer in front of them.


W
Will Stern

As mentioned above, Cluster will scale and load-balance your app across all cores.

adding something like

cluster.on('exit', function () {
  cluster.fork();
});

Will restart any failing workers.

These days, a lot of people also prefer PM2, which handles the clustering for you and also provides some cool monitoring features.

Then, add Nginx or HAProxy in front of several machines running with clustering and you have multiple levels of failover and a much higher load capacity.


PM2 is great for production use. The monitoring tools have helped me work out memory problems with apps.
A
Alister

The cluster module allows you to utilise all cores of your machine. In fact you can take advantage of this in just 2 commands and without touching your code using a very popular process manager pm2.

npm i -g pm2
pm2 start app.js -i max

m
mikeal

Future version of node will allow you to fork a process and pass messages to it and Ryan has stated he wants to find some way to also share file handlers, so it won't be a straight forward Web Worker implementation.

At this time there is not an easy solution for this but it's still very early and node is one of the fastest moving open source projects I've ever seen so expect something awesome in the near future.


T
TheDeveloper

Spark2 is based on Spark which is now no longer maintained. Cluster is its successor, and it has some cool features, like spawning one worker process per CPU core and respawning dead workers.


The original question and a lot of these answers are a few months old and with node moving so fast I appreciate you adding the blurb about Cluster. After looking at Cluster and its examples, it looks exactly like what I (or the OP?) want for Node, thanks!
O
Oleksii Trekhleb

You may run your node.js application on multiple cores by using the cluster module on combination with os module which may be used to detect how many CPUs you have.

For example let's imagine that you have a server module that runs simple http server on the backend and you want to run it for several CPUs:

// Dependencies. const server = require('./lib/server'); // This is our custom server module. const cluster = require('cluster'); const os = require('os'); // If we're on the master thread start the forks. if (cluster.isMaster) { // Fork the process. for (let i = 0; i < os.cpus().length; i++) { cluster.fork(); } } else { // If we're not on the master thread start the server. server.init(); }


Y
Yi Jiang

I'm using Node worker to run processes in a simple way from my main process. Seems to be working great while we wait for the official way to come around.


why node worker example.js can't run, my node is 0.3.3 pre version
R
Roy

The new kid on the block here is LearnBoost's "Up".

It provides "Zero-downtime reloads" and additionally creates multiple workers (by default the number of CPUs, but it is configurable) to provide the best of all Worlds.

It is new, but seems to be pretty stable, and I'm using it happily in one of my current projects.


S
Someone Special

💢 IMPORTANT DIFFERENCE - ROLLING RESTART

I have to add an important difference between using node's build in cluster mode VS a process manager like PM2's cluster mode.

PM2 allows zero down time reloads when you are running.

pm2 start app.js -i 2 --wait-ready

In your codes add the following

process.send('ready');

When you call pm2 reload app after code updates, PM2 will reload the first instance of the app, wait for the 'ready' call, then it move on to reloads the next instance, ensuring you always have an app active to respond to requests.

While if you use nodejs' cluster, there will be down time when you restart and waiting for server to be ready since there is only one instance of the app and you are restarting all the cores together.


Y
Yunat Amos

I searched for Clusterize an app for all CPU cores available and found my myself here. Where I found this keyword Is Pm2 command

pm2 examples

This is what I found

Clusterize an app to all CPU cores available: $ pm2 start -i max

If you need to install pm2 use these commands

npm install -g pm2

yan add -g pm2

or

Use this link Here


F
Fire Crow

It's also possible to design the web-service as several stand alone servers that listen to unix sockets, so that you can push functions like data processing into seperate processes.

This is similar to most scrpting/database web server architectures where a cgi process handles business logic and then pushes and pulls the data via a unix socket to a database.

the difference being that the data processing is written as a node webserver listening on a port.

it's more complex but ultimately its where multi-core development has to go. a multiprocess architecture using multiple components for each web request.


M
Martin Tajur

It's possible to scale NodeJS out to multiple boxes using a pure TCP load balancer (HAProxy) in front of multiple boxes running one NodeJS process each.

If you then have some common knowledge to share between all instances you could use a central Redis store or similar which can then be accessed from all process instances (e.g. from all boxes)


Unless you've got single core CPUs in those servers, that's not going to utilise all your CPU capacity (unless you're doing something else too).