Memory Leak - App crash every day


#1

Hi all, I could use some help on this memory leak issue.

I’m struggling to find out where the memory leaks come from in my app. My containers (standard size on galaxy) are crashing every day…
I took screenshots of the past 24 hours for one instance, (same instance for all screenshots) and hopefully someone here will see something obvious that I’ve unfortunately missed so far.

I’ve hunted global variables and set them to local, but it’s possible that I missed some.

I tried also to run a separate instance with a copy of the prod database and the container stays stable when I’m the only user connected.
So it’s obviously linked with the user activity and as our audience is growing every day (one positive point at least) this problem becomes always more urgent to solve.

Looking at the charts, the problem doesn’t seem to come from the publications as they are pretty well-balanced (created, deleted).

Please let me know if you need any information that could help you understand this issue better.

Thanks for your help,


How to find memory leaks in a Meteor app?
#2

Did you ever get to the bottom of this?

Trying to find some memory leak(s) in my app as well…


#3

@hemalr87 no, not yet. I’ve put aside this issue for (quite) some time, my server has to reboot every now and then but I will have to go through a whole code cleanup anyway. I’ll keep you posted if I can solve it and if I can point out the culprit in the process.

Please let me know if you make any progress on your side! good luck


#4

So it seems I may have fixed it on my end - caused by a db query that was inefficient. I.e. - the function changes the status of some returned documents, but not all. I modified the query to (should have been done like this from the get go) not even return the documents that have no chance of the status changing, and it (knock on wood) seems to have been the cause of the error. Stats are looking good so far…


#5

Looks familiar. Are you using observe / observe changes? There’s a serious memory leak bug in there that MDG still hasn’t fixed.

I suggest trying to switch to polling methods instead of pub-sub and avoid using observe(changes) at all cost. Worked for us.


Meteor perfomance issues with collection observeChanges
#6

We migrated our entire stack off Meteor for what ultimately ended up to be this bug.


#7

Does anybody have more information on that? If that’s the case, and the bug isn’t found and fixed, meteor is not a choice.


#8

That does look pretty serious. I wonder why it’s not getting any attention?

We were having some memory leak issues previously but with 1.6 they seem to have gone away.


#9

I have the same problem in my Meter 1.2 apps which are still on older versions and use the old mupx to deploy. Since I switched some to Meteor 1.4+ and the most recent mup, I don’t have to restart the server every couple of weeks anymore. However, I still don’t know if this has been fixed in Meter or if the new mup just restarts the app once it sees it became unresponsive.