Memory leak in renderToStringWithData

[amannn]

Intended outcome:

I have a service which uses the renderToStringWithData function from react-apollo. I expect the function to not have any memory leaks.

Actual outcome:

The service crashes every now and then, because it runs out of memory. I read a tutorial on how to diagnose memory leaks and I think I found one that is caused by the mentioned function. I have the same issue with another node app which uses renderToStringWithData.

This graph shows the growing memory consumption of my reproduction with GitHunt:

How to reproduce the issue:

1. Clone https://github.com/amannn/GitHunt-React
2. Make sure you're on the memory-profiling branch.
3. Do the regular GitHunt setup.
4. yarn build
5. yarn start
6. ab -n 100 http://127.0.0.1:3000/ (sends a request to the server 100 times)
7. When the requests are through, stop the server. This will cause the profiling data to be written to stats.json.
8. Run python plot.py to see the graph.

The mentioned tutorial also outlines a method for getting more information about which objects are allocated and never released by garbage collection.

Version

• apollo-client@2.3.5
• react-apollo@2.1.6

[patroza]

We are seeing the same thing, same versions, however we use renderToString manually, and getDataFromTree from react-apollo separately

[ctbarna]

We are also trying to profile a memory leak in our app that appears to involve a branch of walkTree hanging. I had no luck tracking down why our app was leaking but decided to profile the GitHunt project under a couple other other scenarios (I ran with n=10000 for these tests):

Here it is with ssr={false} on the queries:

Here it is without even running getDataFromTree:

[mike-marcacci]

We have been seeing this in production for a while. One other thing to note is that a corresponding CPU "leak" is accompanies the increased memory usage. Note the drop where a deploy restarted all nodes:

I suppose this should be a suspect with any JS memory leak, but we might want to start by looking at anything explicitly passed to the next event frame (such as with setTimeout/setImmediate/setInterval/requestIdleCallback).

[mike-marcacci]

I'm behind from chasing my tail on all sorts of upstream issues today, so I can't really dive into this anymore, but my current suspicion is this setInterval which is never cleared internally or by react-apollo.

Everything in its scope is going to stay in memory indefinitely, and we're going to add a new scheduler every time we create an apollo client instance.

If this is correct, this also effects browser environments, but isn't problematic since they're so much shorter lived.

[benjamn]

Thanks for the excellent reproduction @amannn!

When I zoom in on small slices of the tail of my allocation profile, the newly created objects are almost all copies of query documents, so I suspect there’s some accidental cloning of queries happening somewhere, possibly compounded by subscription-related closures hanging around too long, like the setInterval idea @mike-marcacci mentioned.

[benjamn]

In addition to trying to create fewer clones of query documents (see commits referenced above), I believe this issue may be contributing to the leak, since the reproduction repository uses apollo-link-persisted-queries here. I just put together a PR to fix that leak here.