2

I continuously deploy a Node.js API server. The memory usage of the running process grows as I deploy new versions of the service despite minimal code and dependency changes. Further, memory usage is not consistent across similar environments despite being the exact same code and version of Node.js (v8.12.0) and similar usage and uptimes.

For example, in one older environment, the API server uses ~600MB after a restart and in another younger, but identical, environment, it is ~370MB after a restart.

To investigate the memory usage, I took a heap snapshot using the Chrome Dev Tools. The summary showed that the heap was about 88% Strings:

snapshot statistics

Looking at the ~900k Strings in the snapshot, the vast majority of them appears to be strings containing the old versions of API server code:

snapshot strings

As the "filename" shows in the details section at the bottom, this string is the entire code of a very old version of a source file. There are hundreds of versions of (seemingly all) old source files. These files have been removed from the server during the release process but somehow end up in the API process heap.

I've attempted to start the process with reduced --max-old-space-size and it causes the program to crash while it starts.

I cannot determine how/why the previous source code is ending up as strings in the process heap. I deploy using a symlinked current directory that points at the latest release. Perhaps also relevant is that I use babel to transpile our source code (once upon a time for async/await, now for ES6 imports).

Why does Node.js add old source files as strings to the heap and how do I prevent this from happening?

mwakerman
  • 138
  • 1
  • 10

2 Answers2

1

So this ended up being caused by the babel cache. Still getting to the bottom of it but removing the 200MB ~/.babel.json file that had been growing in the api users's home directory appears to have fixed the problem. The service is now happily running using about 90MB of memory. Following these instructions to disable the cache when starting the application has solved it for me.

mwakerman
  • 138
  • 1
  • 10
0

I don't know how the nodejs internals works. But, there could be a chance that the cache of node is somehow resolving the symlinks and storing the old scripts.

Have you tried to move/remove the old releases from where are they located?

thblckjkr
  • 1
  • I've just tried removing the symlink entirely and deploying directly using the full release directory path. It does not appear to have made a difference to the processes memory usage: still about 600MB (have not performed another heap snapshot). – mwakerman Feb 05 '19 at 07:22