Node.js 100% CPU - gettimeofday call Node.js 100% CPU - gettimeofday call linux linux

Node.js 100% CPU - gettimeofday call


My guess is that someone manually implemented a blocking "setTimeout". This could happen if someone doesn't want to release control of the main JS thread in an effort to prevent a potential race condition.

For obvious reasons this is a bad practice for production code, but I've used it on occasion in debugging to force asynchronous processes to execute in a specific order.

You could look for something silly like this:

var mockAsyncFunction = function (cb) {    setTimeout(function () {        cb(null, 'dummy_result')    }, 5000);};var myResult = null;mockAsyncFunction(function (err, result) {    myResult = result;});var timeOut = 10000; // timeout in 10 sec.var timeStart = new Date().getTime();while (1) {    if (new Date().getTime() - timeStart > 10000) {        break;    }}console.log('DONE');

or something more nefarious with nextTick recursion like:

var timeStart = new Date().getTime();var recurseUntilDone = function () {    if (new Date().getTime() - timeStart < 10000) {        process.nextTick(recurseUntilDone);    } else {        console.log('Done recursing');    }};recurseUntilDone();


Use node-inspector to be able to pause your code when the CPU is 100% - my bet is also on some badly implemented loop checking state until a certain time has passed, but they can be hard to find.

Attach the debugger with --debug when starting node (ie. node index.js --debug) and in a separate window run node-inspector. Use Chrome to connect to your debug session (the url is outputted from node-inspector command) and wait until the problem occurs and pause the execution and you should be able to find it.


We saw this too, in both production and development. Also looking for an answer.We started investigating the node run-time, but the problem is so infrequent it's not getting any priority. Because it's completely cpu bound, no system calls, it's hard capture with an strace.

It won't be timed loop checking state, because a new Date().getTime() loop does not make any calls to gettimeofday (in node v0.10.29; it just does a long series of nanosleeps in one pid and just futex calls in the other. Clever, actually). Same for Date.now().