Meteor Node Process CPU Usage Nears 100%

While I don’t have a specific answer to your question, I have experience dealing with CPU issues for our production meteor app for so I can give you a list of things to investigate.

  1. Upgrade to the latest version of meteor and the appropriate node version (see the changelog). As of this writing that’s meteor 0.8.2 and node 0.10.28.

  2. Read this and this article. The latter makes a great point that you really should always try to delay activation of subscriptions until you need them. In particular you may not need to publish anything for users who are not logged in. In my experience, meteor CPU problems have everything to do with subscriptions.

  3. Be careful with observe and observeChanges. These are expensive and are easy to abuse. In particular:

    • Make sure you are calling stop() on your handles when they are no longer needed (consider using a package like publish-with-relations so this is done for you).
    • Fetch only the collections and fields that you absolutely need. Observe works by continually diffing objects (requires lots of CPU). The fewer and smaller objects you have, the less there is to compute.
  4. Consider using smart-collections before it is retired. Use oplog tailing – this can make for a night and day difference in performance and CPU usage in your app.

  5. Consider making some things not reactive (also mentioned in the articles above). For us that was a big win. We had one extremely expensive join that was used on two frequently accessed pages on the site. When it got to the point where the CPU was pegged at 100% about every 30 minutes I gave up on reactivity for that element and just did the join on the server and shipped the data to the client via a method call. I also created a server-side expiring cache for these results and stored them by user (special thanks to Matt DeBergalis for this suggestion).

  6. Do a preventative nightly restart. I have a cron job that tells forever to restart our app once a day in the middle of the night. That brings the CPU down from ~10% to 1%. This seems like black magic, but the fact that the CPU usage changes after a reset leads me to believe this is a good idea.

Updated thoughts (1/13/14)

  • We migrated to oplog tailing as soon as it was available (meteor 0.7) and that made a big difference. Note that in order to get access to the oplog, you’ll probably need to either host your own db or run a dedicated instance on the hosting provider of your choice. I’d also recommend adding the facts package to actually tell if its working.

  • There was a memory leak discovered in publish-with-relations, and as of this writing the atmosphere version (v0.1.5) hasn’t been bumped to reflect these changes. If you are using it in production, I strongly recommend checking out the HEAD version and running it locally.

  • We stopped doing nightly restarts a couple of weeks ago. So far everything has been fine (fingers crossed).

Updated thoughts (7/2/14)

  • A few months ago we switched over to using an Elastic Deployment on mongohq. It’s affordable, the performance has been great, and they even have a blog post which tells you how to enable oplog tailing.

  • I’d strongly recommend checking out kadira to help diagnose performance issues in your app. Also check out the academy articles which have a number of good tips in them.

Leave a Comment