Memory Leak - App crash every day

help
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.

05
053518×1772 363 KB

55
553514×2042 585 KB

43
433490×1718 430 KB

39
393610×2000 562 KB

47
473472×2076 521 KB

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,

1 Like
2

Did you ever get to the bottom of this?

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

1 Like
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

1 Like
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…

1 Like
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.

3 Likes
6

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

1 Like
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.

10

Did anyone here figure out a solution or find out why the cause of the memory leak?

We’re starting to see the same problem with the memory just going up slowly and crashing the app a few times a day…

We use observers multiple places and it would be a rather big job if we had to rewrite that part of it…

11

Hi Emil,
No, I never really figured out what caused the issues. I actually killed this project which had memory leaks.
I’m working on another project that runs well and stable. It also has a much cleaner code structure.
Sorry that I cannot help more.

12

I think should you check code in your app to reduce publications (such as use lamhieu:hypersubs to reduce same subscriptions, use method instead of subscriptions if not need real-time tracking or try mixmax:smart-disconnect). All just is tips to optimal for your app.

1 Like
13

with my experiences, Meteor publication is very useful but we should use publication/subscription with ONLY ONE document. I mean you subscribe a document with its _id field as the key.
I don’t use publication/subscription to get a list of documents. In case I need to auto reload the list of documents, I update the list events to a document and subscribe to that document. On the events changed, use method to fetch new/updated documents.

14

In my case, the issue has not resurfaced since identifying and fixing the inefficient db query. Based on my singular sample size, it may be worth investigating.

1 Like