On an application we are building with Meteor 1.2.1, ES6, and webpack, when running on MacOS X El Capitan, one of the two “node” processes never goes below 100%, usually around 120% with the app not doing anything (150% while building). Using fs_usage shows that that process is constantly polling the file system, from 20000 to 28000 calls to stat64 per second, going round and round on all files below the project root, including .meteor and the 25000 files below node_modules. This seems to be the file_watcher part : the other process, shown in Kadira, remains below 1% and only shows use of sockets, not disk files.
I’ve tried running with --once : same result.
I’ve also tried running with: METEOR_WATCH_FORCE_POLLING=1 METEOR_WATCH_POLLING_INTERVAL_MS=10000 meteor
and it doesn’t reduce that stat64 rate : same result.
The problem does not appear on Linux workstations for the same app. It doesn’t happen with --production either.
Are you starting your project from a package.json script as described here? It caused my CPU to spike over 100% as well so I dropped it. Starting up from the command line had no problems. I was also running on 1.2.1, ES6 & El Capitan but not webpack.
It does indeed corroborate what I had found: the Meteor webpack:webpack packages relies on webpack:watchpack, which itself relies on chokidar, which can use fsevents or (not sure it has been committed) kqueue, or polling. BUT it does not appear to expose the options is passes to chokidar.
Although this issue does not provide a way to a solution, it seems to go in the same direction.
Not for me: they were reinstalled when running meteor, and the same problem resumed. Guess I’ll have to modify the webpack package to expose chokidar options, possibly force fsevents use or manually set the polling rate.