Repository navigation
Add GC Insights #4496
Description
As more and more enterprise customers are using Node.js, the demand for Node.js monitoring increased as well. Node.js already supports a bunch of ways for retrieving interesting information, but GC information is lacking. Many platforms, e.g. the JVM, support means to programmatically retrieve information about GCs. It would be useful if Node.js had these features too.
The main users for GC insights will probably be monitoring products. The way these products currently access GC information is via native addons that make use of AddGCEpilogueCallback. An example open source implementation of this is node-gcstats. Strongloop, Ruxit, Instana and others have their own, probably similar implementations.
Users of such monitoring tools, or more generally users interested in GC activity, need to compile native addons in order to access this information. It is hard to explain why users need to do this (or have a package such as build-essential installed). This gets increasingly harder in Java shops which are used to having everything in the platform. Building these addons automatically on install only reduces this problem, but doesn't remove it.
Node.js used to contain post-gc event infrastructure, but it was removed at the end of last year (Dec 2014) by @bnoordhuis with the following commit:
lib,src: remove post-gc event infrastructure
Remove the 'gc' event from the v8 module and remove the supporting
infrastructure from src/. It gets the axe because:
- There are currently no users. It was originally conceived as
an upstreamed subset of StrongLoop's strong-agent GC metrics,
but the strong-agent code base has evolved considerably since
that time and has no use anymore for what is in core.- The implementation is not quite sound. It calls into JS land
from inside the GC epilog and that is unsafe. We could fix
that by delaying the callback until a safe time but because
there are no users anyway, removing it is all around easier.PR-URL: #174
Reviewed-By: Trevor Norris trev.norris@gmail.com
I believe that we got users of such functionality (mainly through monitoring products) and that we could fix the implementation (the second argument in the commit comment). For these reasons, I propose to add the removed functionality back to the v8 module and improve on it, e.g. by scheduling work via uv_queue_work. I am willing to do this work and open a PR.
Disclaimer: I am working for Instana and we have a Node.js sensor with GC information.
Activity
trevnorris commentedon Dec 31, 2015
are there specific data points you'd like to retrieve from the GC, or simply be able to call a callback before/after the GC? also, I believe this API only addresses the GC calls that interrupt the main thread, and not for those collections happening off the main thread.
bripkens commentedon Jan 1, 2016
I'd opt for a minimum set of metrics in the beginning.
endTime - startTime) andFurther information, e.g. heap statistics, could be retrieved in user-land via
v8.getHeapStatistics()in the callback. In combination with PR#4463 (v8.getHeapSpaceStatistics()), we can get pretty close tonode --log_gc --trace_gc. On the other hand, we won't get information about freed handles, marking steps, holes… My current assumption is that most users do not need to know about handles, marking steps, fragmentation or any more of the low-level metrics. For this reason, I believe that the metrics listed above (when did what type of GC occur and how long did it take) are sufficient for most use cases.I traced the usage of the v8
GCTracerand specifically whenGCTracer#Stop(…)(source) is called. As far as I know, this is the class responsible for printing information tostdoutwhen v8 is executed with GC tracing enabled, e.g.--trace_gc. Turns outGCTracer#Stop(…)is only used inHeap#CollectGarbage()(source, call location). In the same method we also have a call path toPerformGarbageCollection(source) and from that method toCallGCPrologueCallbacks(source) and CallGCEpilogueCallbacks (source).What I want to say: The GC prologue and epilogue callbacks are called whenever the GC Tracer runs. As such it should be sufficient for our use case as well.
trevnorris commentedon Jan 1, 2016
@nodejs/ctc Thoughts?
ofrobots commentedon Jan 2, 2016
One thing to note is that this use-case has some overlap with tracing and trace-event (some background). Now that blink's trace-event has landed in V8 4.9, once we implement a trace-event buffer in Node.js, we should be able to expose the trace stream to user space which could include these gc trace events.
bripkens commentedon Jan 3, 2016
That is some very big overlap. I like where the trace-event discussions are going. If trace-event works out and is controllable via Node.js, my proposal would be completely obsolete. Still got some questions in my head and will post them to the WG.
I'll update this issue once these questions are resolved. Thank you @ofrobots.
Fishrock123 commentedon Jan 4, 2016
@ofrobots could you explain what that does in some more detail?
In general I think this sounds useful. (Although I don't know this area in any great detail.)
megastef commentedon Jan 19, 2016
+1 - today monitoring GC activites needs modules like memwatch-next, gc-profiler or gc-stats. I hear sometimes complains from windows users having problems to compile those native modules ...it would be great to have this available in node!
megastef commentedon Apr 14, 2016
Hi, any progress for this issue? It looks windows support here dainis/node-gcstats#18 stucks as well. I just want to know if it makes sense to invest more time in gc-stats windows support/providing pre-compiled modules for gc-stats.
Fishrock123 commentedon Apr 14, 2016
Nothing of note so far.
bnoordhuis commentedon Feb 7, 2017
I think this has been superseded by nodejs/diagnostics#84. I'll go ahead and close this out but let me know if I should reopen.