Monitoring the Garbage Collection of a node application

Throw away by https://undraw.co/

Monitoring a running nodejs application in production is a critical activity which allows detecting applications performance degradation automatically without manually testing and looking at it.

Besides monitoring only the total memory utilisation, the monitoring of Garbage Collection performance over time can expose more information about a potential problem in the application which can lead to a memory leak.

Running a node app with the --trace_gc flag will write GC information to the logs at every GC event. Following is the output after running an example app, e.g. node --trace_gc app.js

From the GC logs you can observe that there are two types of entries:

  • Scavenge (new space garbage collection) — an often running and fast GC which is responsible for cleaning up relatively small objects from the new space on the heap

How to read the GC cycle entries?

Both types of entries contain data separated by single or multiple spaces.

The Scavenge cycle

[30420:0x103e45000] 99 ms: Scavenge 3.8 (5.7) -> 3.3 (8.2) MB, 0.6 / 0.0 ms (average mu = 1.000, current mu = 1.000) allocation failure

The Scavenge entry contains:

  • The process id and memory address — [30420:0x103e45000]

The Mark-sweep cycle

[30420:0x103e45000] 8168 ms: Mark-sweep 6.4 (9.7) -> 4.5 (7.1) MB, 2.6 / 0.0 ms (+ 0.2 ms in 3 steps since start of marking, biggest step 0.1 ms, walltime since start of marking 13 ms) (average mu = 1.000, current mu = 1.000) finalize incremental marking via task GC in old space requested

The Mark-sweep entry contains the same data as Scavenge with some extra information regarding the marking phase:

  • The time it spent in incremental marking — + 0.2 ms

Now that you have enabled monitoring for Garbage Collection cycles of a node app what are some of the indications one should watch after.

  • GC cycle duration. Longer Scavenge or Mark-sweep cycles leads to longer latency for application requests because of the node being single-threaded every GC cycle will interrupt the execution of the application

Conclusion

Tracking down memory leaks is a challenging activity which cannot be done without data and internal insight about what exactly the application is doing to manage its memory.

Node has a built-in mechanism to output information about V8 engine’s Garbage Collection cycles. Which you can use to monitor how often the GC cycles happen, how long it takes and how much memory it frees up by comparing the total heap used before and after the GC cycle.

Thank you for your attention and if you found this post useful and would like to read more about random web development topics, just clap for this article or drop a comment here. As always you can find me on Twitter@andrejsabrickis

Writing JS, TS, Vue, #C, and fostering teams to release customer value n-times a day. Creator of billid.app and writer on abrickis.me

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store