I haven’t updated to 1.4 (I’m still at 1.2.1) but I can see there has been an update in the background as the cli now proposes I update to 1.4.
BUT suddenly this morning, since 1.4 has become available, running a meteor dev server is absolutely killing my CPU. On a macbook pro 2012 i5, the meteor node process is at 170%.
I think this must be related to the update, anyone else seeing this ?
i’m not having that issue, also working on a macbook pro (although i’m using the 2016 model).
i was running with my old dev mongo, and have also since reset. no issues yet anyway. only been working maybe 3 hours on it now.
thanks for the response - are you using 1.4 ? I’m still on 1.2.1, maybe that has something to do with it ? Yesterday evening cpu usage was normal
oh hold on, if you haven’t updated to 1.4 why would that update be slowing you down.
i misread your post and thought you were saying that you did the update and the CPU is maxing out.
I am using 1.4 though.
No idea, nothing else has changed since yesterday aside from the background update.
Thanks for your help though !
As mentioned in a parallel thread
Meteor downloads the update in background, so that when you enter meteor update or meteor create, it’s using the latest recommended release.
maybe this update has affected my version 1.2.1 ?
I also had issues, and it was definitely due to the downloading on the background. At first it was taking extremely long to startup – higher than normal CPU usage, and memory usage slowly climbing. I let it do it’s thing and came back several minutes later to find an unresponsive OS. Memory (including swap) was completely full.
I killed the process, rebooted, and started meteor up again to start with clean resources. Finally didn’t have to wait several minutes to get the “App running at:…” prompt, but saw that there were still downloads in the background. I monitored my resources, CPU usage was steady but unnecessarily high (really… it’s just a download, no?) – and the memory usage was steadily climbing… quickly. Finally after the download finished CPU usage stopped, and now meteor had climbed to almost 2GB of memory… in under a minute, this is over 3x normal usage.
After killing the process yet again, and restarting meteor I found everything was back to normal.
This is also happening to me, tried killing/restarting the node process several times to no avail. Will try to wait it out. I’m using 1.3.5.1.
Same here. Left long enough (1-2 hrs) the 1.4 dev server managed to get the OS X out-of-memory dialog to pop up and say it was suspending applications. I had to hard-reboot.
Current load average:
Load average: 20.32 24.44 15.14
All appears to be the Meteor dev server.
Having the same issue:
Same problem for me. I tried letting meteor run for a while, problem persisted. Activity Monitor is not showing much network activity and the CPU use is still VERY high even when disconnected from the internet.
The only unusual thing I’ve noticed is that CollectionFS is repeatedly querying cfs.<myFileCollection>.filerecord with:
{
"$and" : [
{
"$or" : [
{
"$and" : [
{
"copies.dataFiles" : {
"$ne" : null
}
},
{
"copies.dataFiles" : {
"$ne" : false
}
}
]
},
{
"failures.copies.dataFiles.doneTrying" : true
}
]
}
]
}
edit: formatting
an update, after an afternoon pretty much wasted 
what has fixed the problem… updating to meteor 1.4…
Having the exact some problem on my Macbook. My app runs on 1.3.2, and as soon as the 1.4 update arrived (I didn’t upgrade my app yet), running meteor locally would take 3x longer than usual to start, then crush the CPU at 100% the entire time the dev server was running.
I deleted the ~/.meteor directory, and re-ran the meteor install script, and now when I run my app, the message in the console gets stuck on Downloading meteor-tool@1.3.2_4... for 15+ minutes and I can’t run my app.
Like @kelbongoo my next step will be to prematurely upgrade my app to 1.4 and hope that fixes the problem. 
Same experience here on OS X 10.11. Since my system downloaded the 1.4 version of the Meteor tool a few days ago, my 1.3.5.1 app now burns CPU. Frustrating.
When running meteor shell a second Node instance starts and consumes lots of CPU as well.
Tried killing and reinstalling Meteor in ~/.meteor but this didn’t have any effect.
Ditto (OSX 10.11.5). No problem with 1.4.0 apps, but starting a 1.3.5.1 app sends CPU to 100+%, where it stays until the node process is terminated (by stopping the app).
Don’t know if this is the reason, but looking at a long running node process for a 1.3.5.1 app it looks like it tries to do something with a 1.4 mongo executable?
Not sure…though I don’t see anything referring to 1.4 for files/ports when I run meteor shell, which also spins up CPU to 100+% in its own node process.
No meaningful disk or network activity from either node process, as you observed.
From meteor shell:
/Users/myktra/Documents/art/src/aidpub/meteor
/Users/myktra/.meteor/packages/meteor-tool/.1.3.5_1.18cblfp++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/bin/node
/Users/myktra/.meteor/packages/meteor-tool/.1.3.5_1.18cblfp++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/fibers/bin/darwin-x64-v8-3.14/fibers.node
/Users/myktra/.meteor/package-metadata/v2.0.1/packages.data.db-shm
/Users/myktra/.meteor/packages/meteor-tool/.1.3.5_1.18cblfp++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/sqlite3/lib/binding/node-v11-darwin-x64/node_sqlite3.node
/usr/lib/dyld
/private/var/db/dyld/dyld_shared_cache_x86_64h
/dev/ttys003
/dev/tty
/dev/tty
->0x4f20a72d45244e19
->0x4f20a72d37209f99
count=1, state=0xa
count=0, state=0x12
->0x4f20a72d37209ed9
->0x4f20a72d44cbadd9
->0x4f20a72d45242959
->0x4f20a72d37207e99
/
->0x4f20a72d3cd102e9
->0x4f20a72d45443661
->0x4f20a72d437100f1
->0x4f20a72d4517f2e9
->0x4f20a72d44883ca1
->0x4f20a72d44883e31
->0x4f20a72d43710411
->0x4f20a72d45445be1
/Users/myktra/.meteor/package-metadata/v2.0.1/packages.data.db
/Users/myktra/.meteor/package-metadata/v2.0.1/packages.data.db-wal
/Users/myktra/.meteor/package-metadata/v2.0.1/packages.data.db-shm
localhost:58123->localhost:58122
Hi folks, relevant thread going on over on GitHub, prob should continue observations there and report back when a fix is available here, yes?
