4

We've got a Vue.js (v2.2.6) app running in production with server-side rendering based on the Hacker News demo app structure. We've got a memory leak that causes the process to run out of memory and crash after around 6-12 hours, and we've started taking heap snapshots on the server to try and track the issue.

However, we've been digging through these for days and haven't really gotten anywhere. The thing that sticks out (as you can see in the below screenshot) is that there are many instances of VueComponent and Vue$2 being created and never deleted from memory. I don't know enough about the internals of Vue's server-side rendering to know if this is a real lead and where to look from there if it is.

enter image description here enter image description here

Has anyone run into something like this or have any ideas where we might look to determine what could be causing this?

James Simpson
  • 13,488
  • 26
  • 83
  • 108

1 Answers1

6

I finally tracked this down by switching to a more powerful debugging tool than using heap snapshots alone: LLDB and the llnode plugin. This should be very familiar if you have used Joyent's SmartOS and mdb, and it gives you a lot more data to drill into than the standard heap snapshot.

I used the dumpme node module to trigger a core dump inside my production application (there are other ways of doing this, but I found this easiest).

I then followed the instructions found at https://developer.ibm.com/node/2016/09/27/advances-in-core-dump-debugging-for-node-js/ and started tracing the references to the VueComponents that were being held in memory.

> lldb node -c core
(lldb) plugin load ./node_modules/llnode/llnode.so
(lldb) v8 findjsobjects
(lldb) v8 findjsinstances VueComponent
(lldb) v8 inspect ...

In this case, it turned out that there was a recursive setTimeout that was never getting cleared when the component was destroyed, so the reference to the entire application stayed in memory.

James Simpson
  • 13,488
  • 26
  • 83
  • 108