Meteor bundle on production 100% CPU

deployment
1

Hello, I have this problem…

Locally on OS X my meteor app works great, but on the production Ubuntu14.04, it sets the CPU to 100% just by running the app… without any visits

I used the “meteor build ../ --architecture os.linux.x86_64” command to create the bundle. On the server the installation of the npm packages went smooth…

Any idea, why this is happening?

Also, my ubuntu server has 4 cores and if I use pm2 to run in cluster mode, it eats all of them

EDIT:
Copied the full meteor project to my server. Running the app with the meteor command works fine and shows decent CPU usage.

Created the production bundle inside the server and running the bundle eats all the CPU…

So, running with meteor works good, using the node option makes the CPU cry

4 Likes
3

Hi, I have the exact same issue.

Meteor version is 1.4.2 and node v6.9.1

When I start the (built) application the CPU usage is normal until I login in. After logging in the CPU stays at 100%.
I tried to profile the application but couldn’t figure out what is wrong.

2 Likes
4

Me too,
Has anyone solved this bug?
I found this related issue https://github.com/meteor/meteor/issues/4314.

5

I’ve seen this with node 6 - can you try with node 4.6.1?

2 Likes
6

As a temporary solution what I did was to install meteor on the server and start the application with the command:

meteor node main.js

instead of

node main.js

It’s been a couple of hours and CPU usage seems normal.
However I’m not sure if it is advised to start an application - in production - like this.

I will.

7

That will use Meteor’s bundled node for 1.4.2 - which is node 4.6.1

1 Like
8

Meteor isn’t ready for Node 6, so you have to use Node 4 on your server

2 Likes
9

meteor 1.4.1.3 on Ubuntu 16.04:
same problem with
pm2 start main.js

10

Good to know, thanks!

I’ll have to revert back to 4.6.1

Thank you guys, this issue was driving me crazy!

1 Like
11

Just tested it on my server and I can confirm that everything works as intended with node v4.6.1

@orloff make sure that the node version you’re using is the 4.6.1

12

checked:
node --version
v4.6.1
inactive server 1 vCPU, 1.7 GB shows 100% CPU

13

@marcosncom

I have faced the same problem before. For me the problem is, I forgot to remove the autopublish and insecure packages from meteor. Therefore the entire collection was being published to the client during the startup that causes the high CPU usage during the deployment.

In your case you might have some different problem. But I just wanted to give a heads up.

14

Thank you guys, I’ll try with node 4.6.1 then… I’m using the latest 6 LTS too.

15

@orloff

I successfully verified that using node 4.6.1 works properly, the problem is with pm2. I use pm2 to run clusters and there is a problem there:

Running node main.js works but pm2 start main.js does not, pm2 fails even when I type and pass the
--interpreter=~/.nvm/versions/node/v4.6.1/bin/node parameter to be sure the proper version of node is used.

Let me know if you have the same problem or find a solution

16

i use process.json for pm2, working without mistakes, but shows 100% CPU on VM, and it is only small meteor app

17

In my case, the problem was that PM2 in cluster mode only uses the node version where PM2 resides… I installed PM2 using node v6, so, in cluster mode will always use that version.

Running the app in single fork mode works as long as you apply nvm use 4 (in case you are using nvm) before running the app

Also, be sure to run npm install in /programs/server with the proper version of node too, I had the node modules installed with v6 and that was causing trouble using v4

If you don’t have multiple versions of node installed then the problem is more interesting than that.

2 Likes
18 
$ sudo pm2 kill
[PM2] Stopping PM2...
[PM2][WARN] No process found
[PM2] All processes have been stopped and deleted
[PM2] PM2 stopped
$ ps aux | grep node
root     12028  0.3  4.0 1201556 70132 ?       Ssl  14:52   0:04 node /opt/bundle/main.js
orloff    14709  0.0  0.0  12944   924 pts/0    S+   15:11   0:00 grep --color=auto node

:grinning:

1 Like
19

I have the same issue on the windows 8.1 x64 environment with node v6.9.1.

To replicate the issue:

  1. meteor create meteorTest
  2. remove insecure and autopublish packages so we can rule out other factors.
  3. create a dummy meteor method at server\method.js , like the below:

Meteor.methods({

test:function(inputString){
    return inputString;
}

});

  1. build it by running meteor build --directory ../meteorTest-build
  2. install all dependencies (need c++ compiler from VS2015):

cd program\server
npm install
set MONGO_URL=mongodb://localhost:27017
set ROOT_URL=http://localhost
set PORT=8080

  1. run node main.js or meteor node main.js to do the comparison
  2. browser http://localhost:8080
  3. On the browser console, run Meteor.call('test','hi123',function(err,result){ console.log(result) });

When using the meteor node, cpu usage level returns to zero after the call, while using the node v6.9.1 causes the cpu usage level goes to 25% and stuck, which means whole cpu core is consumed…

But the problem is that I cannot use meteor node with forever on node v6.9.1 . At last, I switch to node v4.6.2 via https://github.com/coreybutler/nvm-windows , so that I can keep both versions of node while using forever to run meteor.

20

I had the same issue with the latest pm2 version (2.1.6) and node 6.9.1. I removed autopublish and insecure that I forgot, downgraded node to 4.6.1.

Autopublish and insecure don’t seem to change anything to the CPU usage, but that’s always a good thing to do.

The node version on my ubuntu server is the deal breaker. I tried switching back and forth from 6.9.1 or 6.9.3 (LTS) and 4.6.1 and I go from 100% usage with node 6 to 1 or 2% with node 4.

Is this because Meteor’s node version is tied to node 4 ? I thought it would use the bundled version anyway ?

21

I’m currently experiencing the same problem
Almost no load in dev mode, but once bundled and running as a docker container. It consumes 100% cpu.
Node version of the container is 4.6.1 and I’m not using pm2.