You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It appears to have been written to target the pre Node 0.10 behavior of nextTick (intending the processing of the next task to run in the next tick of the event loop). The implementation of process.nextTick changed in Node 0.10 and now schedules the callback for the end of the current tick (behavior is documented here).
This was causing operations coming down from oplog to starve the event queue and causing all of our webservers to stop accepting/servicing connections simultaneously while the event loop was blocking (sometimes up to 1.5 mins).
Changing process.nextTick over to setImmediate fixes the problem and implements the (I think) original intent of the code. We've been running it in production over the last week and observing much better CPU characteristics on our servers (and no event loop starvation).
PR to follow.
The text was updated successfully, but these errors were encountered:
Who would have thought nextTick was actually never intended to run in the next tick? (my reading of various node channels on this issue is that nextTick was never supposed to be used for the purpose outlined here, and people ending up doing so due to a misunderstanding the intention of nextTick, precipitated by a poor choice of name).
It appears to have been written to target the pre Node 0.10 behavior of
nextTick
(intending the processing of the next task to run in the next tick of the event loop). The implementation ofprocess.nextTick
changed in Node 0.10 and now schedules the callback for the end of the current tick (behavior is documented here).This was causing operations coming down from oplog to starve the event queue and causing all of our webservers to stop accepting/servicing connections simultaneously while the event loop was blocking (sometimes up to 1.5 mins).
Changing
process.nextTick
over tosetImmediate
fixes the problem and implements the (I think) original intent of the code. We've been running it in production over the last week and observing much better CPU characteristics on our servers (and no event loop starvation).PR to follow.
The text was updated successfully, but these errors were encountered: