SSR memory leaks

[captainn]

I’m getting a severe memory leak on Galaxy if I leave my SSR code. It causes my app to restart every half our or so. This is after only a handful of SSR renders (or even just one). I’m sure it’s something simple, but how do I get access to some kind of memory dump when this happens - preferably from the server running on my local machine (I’m sure it’s happening here too, I just have a lot more ram and restart more regularly development).

Hmm, can I just hook up the Chrome debugger (haven’t done that in a while, heh)

[minhna]

Is there anything in logs? I deploy my apps on my own server, I can see logs via
journalctl command.

[alawi]

I had memory leak with SSR before and I had to nullify all variables after each request and/or eliminate any file scoped constants to ensure GC is done properly. It could be some query result (or just user doc) being accumulated in memory after each request.

I’ve used heap dump in the past to capture the heap and send to S3 in a remote machine (basically a fork of heap save). I’ve not done it locally, but from this article it doesn’t seem to hard to achieve.

[captainn]

Okay something else weird - it only leaks in production. If I put the app up on Staging (and then hammer it, with more traffic than we get on the main site) it doesn’t leak memory. The only difference between staging and production is the database they each connect to (both on Atlas, both Replica Sets with 3 nodes, on Version 4.0.12 - staging is a “sandbox”), and on production we use a “professional” container to get access to APM - but the memory leaks and restarts were a problem before that.

Obviously, the production database is much larger (Atlas says 1.8Gig, which seems larger than it should be), and the number of connections - I get 30 on production, and only 4 on staging. I have no idea what that means - I guess I have my reading cut out for me.

[rjdavid]

We experienced something similar before wherein if a link of a page is posted in a facebook page, a handful of facebook bots plus traffic can kill an aws ec2 instance before it can spawn due to memory use.

We did not think it was a memory leak that time but we end up caching our ssr pages through redis. We are using your react-loadable fork for ssr

[captainn]

I guess it could be bots. This particular site gets almost no traffic according to the connections count in Galaxy (there are literally 0 right now). I’ll try sharing from staging and see what happens.

I’m also going to try heap save and see what that reveals.

Thanks for the tips all!

[captainn]

Another thing I just noticed - The CPU when the server is leaking memory spikes up to 60% every 30 seconds on the production server. This doesn’t happen on the staging server.