users (memory usage)


Have you been experiencing a high memory usage lately?



Yes I do :smile: :


Yes, I’ve started to receive these too…

The first time it happend I immediately moved up to 512mb instances, but now I’m getting suspicios because it’s happened again… the code hasn’t changed since before it was fine for months on the lower number of instances.


I’m on the same boat here. Most users aren’t aware of this new issue because most of the time modulus doesn’t send notifications of restarts due to “exceeding the memory limit.” My project has restarted about 25+ times in the past 2 days, and I only received a notification 3 times. It doesn’t matter how much memory I add to my project, the memory usage just keeps going up and restarting when it reaches certain point.

I have not made any changes to my code for over 2 months. Project restarts only take about ~5 seconds, but it is really annoying if you have an active user base.
(This issue seems to only be affecting projects with an active user base)


Yep, saw my first notification yesterday. Has any raised the issue the Modulus support?


I’ve just raised a ticket with Modulus support. Let’s see what they say.


JUN 29, 2015 | 08:43AM EDT
David Berger replied:
Hey Russell,

If you check your administration page here: and scroll down to servo size, you will see your servo is currently set to 192 MB. This is the limit that is being hit.

Looking at your metrics page here: you will notice that your project is consistently sitting around 180-185 mb. These snapshots are taken every 30 seconds, and since it is easy for a project to spike and consume an extra 12 mb within 30 seconds you won’t usually see the graph sit at exactly 192mb.

I would recommend increasing the size of your servo in the administration panel of your project. After you select the new servo size, perform a full STOP and a full START of your project (as opposed to a project RESTART).

$ modulus project stop
$ modulus project start


David Berger
Support Engineer
Modulus |


Hey all,

I work at Modulus and can provide some insight into this. Meteor applications have always been on the high end of the memory spectrum compared to all other apps. The reason you see notifications now is that we just released that particular notification. You won’t see one for every restart, because we don’t want to spam your inbox for spin-crashing or misbehaving sites - we limit them to once roughly every 24 hours.

I can also confidently say we haven’t made changes to our environment that would have an impact on Meteor applications. In reality the CLI converts it to its underlying Node.js app on every deploy, so by the time it hits our environment there’s no different between it and a Node app. It is possible the Meteor runtime, or some side-effect of demeteorization, did introduce a memory leak, but we don’t know for sure.

We do recommend a minimum of 512MB for production Meteor apps. 396MB will work for many smaller or non-production sites. Any smaller than that and you’ll likely run into issues as soon as you put some load on it.


I feel like there is a memory leak somewhere. I’ll run tests when I have some free time, and get back with the results.

Does anyone know why Kadira shows a lower memory usage than Modulus metrics? @arunoda


Modulus shows the memory usage for the entire container, not just the Meteor application. This metric will then include things like our process monitor and a few other tiny services. The servo memory limit is only applied to the parent process and any children, so there is a disconnect between what you see on the graphs and the limit, but they’re very close. The overhead per container should be less than 20MB in most cases.