Node running VERY hot since 1.4 background update

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 :frowning:

  • killing app and restarting did not fix the problem
  • removing all packages did not fix the problem
  • restarting machine did not fix the problem
  • uninstalling and reinstalling meteor completely did not fix the problem

what has fixed the problem… updating to meteor 1.4…

1 Like

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. :disappointed:

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?

1 Like

I have the same issue on different meteor project <= 1.3

A minimal workaround worth posting here has been found. Hopefully a permanent fix will be available soon.

For version 1.3.x (and potentially earlier) users on Mac OS X, use an absolute path to launch meteor via the matching version of the tool, for example:

~/.meteor/packages/meteor-tool/1.3.5_1/mt-os.osx.x86_64/meteor --settings settings.json

This restores the previous behavior of minimal CPU usage during idle periods.

Hi all, thanks for letting us know. We’ve acknowledged the issue and will be providing updates here: