New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.meteor/tools/meteor.js CPU usage is > 100% #1506

Closed
DerMambo opened this Issue Oct 16, 2013 · 18 comments

Comments

Projects
None yet
9 participants
@DerMambo

DerMambo commented Oct 16, 2013

Since the newest release i've got a problem with the cpu usage of a meteor process. My project is not that small anymore, but it worked perfectly before.

I am using MacOS X 10.8.4.

If i "ps | aux grep node" i get the following:

Manuel          4474 101,4  3,3  6272464 274544 s003  R+   11:59am  17:45.05 /Users/Manuel/.meteor/tools/a80b2d5689/bin/node /Users/Manuel/.meteor/tools/a80b2d5689/tools/meteor.js --settings ./config/local.json

As you can see the CPU is over 100%.

If I stop and start my meteor app the CPU usage of this process is between 15-40%. If the auto-restart on code change applies the CPU usage increases really fast.

My meteor app itself has just normal CPU usage.

I am running the app with
mrt --settings "./config/local.json"

Using:
Meteorite version 0.6.12
Release 0.6.6.1

Any hints? This is really annoying ;)

@zhouzhuojie

This comment has been minimized.

zhouzhuojie commented Oct 16, 2013

Same here.

Recently I updated to 0.6.6.1, and for my app, the CPU usage problem can be clearly reproduced as:

  • First start meteor app
  • After you modifying your files twice (i.e. restarted (x2) ), the CPU usage is going up over 100% for a very long time, the browser also stuck there.
  • Kill meteor with ctrl-c, and it works again.

Running with meteor --release 0.6.6 and meteor --release 0.6.5.1 works fine.

@glasser

This comment has been minimized.

Member

glasser commented Oct 16, 2013

Definitely only after 2 restarts?

Maybe the clearIntervals aren't quite working...

@jagill

This comment has been minimized.

Contributor

jagill commented Oct 16, 2013

We are seeing this too. On 0.6.6, starting up meteor runs about 1.5%, loading a page and modifying files leaves it at about 2.5%. On 0.6.6.1, startup up meteor (no page, no reloads) hovers about 13%. This seems to be independent of the number of hot pushes.

EDIT: I'm on OS X 10.8.5 on a '11 MacBook Air.

@glasser

This comment has been minimized.

Member

glasser commented Oct 16, 2013

It is definitely expected to use more CPU on 0.6.6.1 than 0.6.6. The change
between the versions was replacing the use of an efficient but unstable
filesystem watch api (which was stabler in the older version of Node used
before 0.6.6) with a frequent poll. Hopefully the next Meteor release can
include potential upstream bug fixes to allow us to use fs.watch again.

But if CPU grows more and more each restart... That's definitely unexpected.

@dweldon

This comment has been minimized.

dweldon commented Oct 20, 2013

@glasser I've never had good luck with the node watch api (that's probably why there are so many npm modules to do the same thing). Could you just use one of them instead? We use chokidar and it seems to work great on both linux and OS X.

@nathan-muir

This comment has been minimized.

Contributor

nathan-muir commented Oct 22, 2013

This is also a big problem for my project. I can't develop on 0.6.6.1/0.6.6.2 without getting a bunch of "Failed to receive keepalive! Exiting." errors.

Cpu usage for single a single core on first start, while idle (no clients):

  • v0.6.5.1 / v0.6.6 - 0% to 2.5%
  • v0.6.6.1/ v0.6.6.2 - 50% to 90%

After a few edits on v0.6.6.1 cpu usage spikes to 100% and stays there.

Project Size:

  • Packages: ~40 packages, ~500 files, ~120 folders
  • Application: ~400 files, ~120 folders

System Specs:

  • Fedora 19
  • i7 4770
  • 32gb ram
  • node v0.10.20

glasser added a commit that referenced this issue Oct 22, 2013

Ensure 500 ms of directory watch downtime.
Should help with #1506.

Fingers crossed for an eventual usable fs.watch.
@glasser

This comment has been minimized.

Member

glasser commented Oct 22, 2013

daf0a48 makes some improvements here. Keeps the CPU below 100% at least.

Really hoping for a better upstream API.

@jagill

This comment has been minimized.

Contributor

jagill commented Oct 23, 2013

Upstream as in in node-land? I was at a talk by the node guys, and they said they basically gave up on figuring out a good cross-browser file-watching api. They're waiting for the community to handle that. So I wouldn't hold your breath!

Some libs like chokidar try to be smart about when they use polling vs inotify/etc.

@glasser

This comment has been minimized.

Member

glasser commented Oct 23, 2013

How long ago was this talk?

@jagill

This comment has been minimized.

Contributor

jagill commented Oct 23, 2013

The talk was on May 9th (http://www.meetup.com/Node-js-Serverside-Javascripters-Club-SF/events/117996462/). They said that making fs module independent was a lot of work, but mostly successful. Then they thought they'd turn their attention to fs.watch/watchFile, but gave up with their tail between their legs after a few months.

Maybe things have changed since then? Things move fast in node-land.

@jagill

This comment has been minimized.

Contributor

jagill commented Oct 23, 2013

@glasser

This comment has been minimized.

Member

glasser commented Oct 23, 2013

There has definitely been work on fs.watch in Node core since August.

On Tue, Oct 22, 2013 at 9:10 PM, James Gill notifications@github.comwrote:

Here's where Bert B is talking about it:
http://www.youtube.com/watch?feature=player_detailpage&v=1C5-A-BgPM8#t=682


Reply to this email directly or view it on GitHubhttps://github.com//issues/1506#issuecomment-26879570
.

glasser added a commit that referenced this issue Nov 1, 2013

Ensure 500 ms of directory watch downtime.
Should help with #1506.

Fingers crossed for an eventual usable fs.watch.
@avital

This comment has been minimized.

Contributor

avital commented Nov 2, 2013

We just cut a release candidate for 0.6.6.3 that should solve this issue. Give it a whirl by running meteor update --release 0.6.6.3-rc1 in your app directory. Let us know if you encounter any problems.

@nathan-muir

This comment has been minimized.

Contributor

nathan-muir commented Nov 2, 2013

Hi @atival, looks much better.

Just running meteor, with no clients, load average is ~0.30, with a range of about 15%-50% cpu.

@zhouzhuojie

This comment has been minimized.

zhouzhuojie commented Nov 4, 2013

Hi, @avital, thanks for your team's the new release. For my app, it keeps cpu running under 40% now.

@avital

This comment has been minimized.

Contributor

avital commented Nov 4, 2013

Resolved in Meteor 0.6.6.3

@avital avital closed this Nov 4, 2013

@dennismonsewicz

This comment has been minimized.

dennismonsewicz commented Apr 1, 2014

I am seeing my CPU usage spike when running 0.7.2. In Chrome I have to kill the current tab process before things calm down

@Slava

This comment has been minimized.

Member

Slava commented Apr 1, 2014

@dennismonsewicz looks like an unrelated issue. The original thread is about CPU usage of server-side node process (specifically the proxying/watcher process and not the application one).

You can open a separate issue following Contributing Guidelines;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment