30 minute build times with 3GB RAM usage

1 
Meteor 1.5.2.1
Node 8.3.0
npm 5.4.2
OSX 10.10

I’m new to meteor. In three days I built an MVP of an internal application we needed. I spent all of the fourth day trying to get the project to build and deploy on the server. I used maybe 20 or so packages. All standard stuff like axios, moment, and react-bootstrap.

I had to raise node.js memory because the build was failing at 1.5GB of RAM usage(!)

After 30 minutes building, meteor finally produced a bundle. I had to rsync the build up to the server because the server didn’t have 2.88GB of free RAM for me to run the compile there.

export TOOL_NODE_FLAGS="--max-old-space-size=4096"
export METEOR_PROFILE=1
meteor reset

Prior to trying to build the project the max memory usage while running $ meteor was only 1GB. Something happened and I’m unsure how to fix it.

I have tried meteor reset I’ve removed the .meteor packages, I’ve created a new meteor project and re-imported the packages and my codebase.

Checking out the largest OS meteor project I could find (Rocket.chat) I still encoutered rather long build/run times (and even long build times). After using create-react-app, next.js, and others I’m wondering why meteor is taking so long and using so many resources.

.meteor/packages

meteor-base@1.1.0             
mobile-experience@1.0.5     
mongo@1.2.2                
reactive-var@1.0.11       
tracker@1.1.3              

es5-shim@4.6.15              
ecmascript@0.8.2              
shell-server@0.2.4           

react-meteor-data
alanning:roles
twbs:bootstrap
accounts-base@1.3.3
accounts-password@1.4.0
service-configuration@1.0.11
themeteorchef:bert
fortawesome:fontawesome
aldeed:collection2-core@2.0.1
audit-argument-checks@1.0.7
ddp-rate-limiter@1.0.7
dynamic-import@0.1.3
static-html
http

package.json

"dependencies": {
    "@cleverbeagle/dates": "^0.5.1",
    "@cleverbeagle/seeder": "^1.2.0",
    "axios": "^0.16.2",
    "babel-runtime": "^6.26.0",
    "bcrypt": "^1.0.3",
    "commonmark": "^0.28.1",
    "core-js": "^2.5.1",
    "fs": "0.0.1-security",
    "handlebars": "^4.0.10",
    "jquery": "^2.2.4",
    "jquery-validation": "^1.17.0",
    "juice": "^4.1.1",
    "lodash": "^4.17.4",
    "meteor-node-stubs": "^0.2.11",
    "prop-types": "^15.5.10",
    "react": "^15.6.1",
    "react-addons-pure-render-mixin": "^15.6.0",
    "react-bootstrap": "^0.31.2",
    "react-dom": "^15.6.1",
    "react-router-bootstrap": "^0.24.3",
    "react-router-dom": "^4.2.2",
    "react-select": "^1.0.0-rc.10",
    "sendgrid": "^5.2.3",
    "simpl-schema": "^0.3.2",
    "to-markdown": "^3.1.0"
  },
  "devDependencies": {
    "babel-jest": "^20.0.3",
    "babel-preset-es2015": "^6.24.1",
    "babel-preset-react": "^6.24.1",
    "enzyme": "^2.9.1",
    "eslint": "^4.8.0",
    "eslint-config-airbnb": "^15.1.0",
    "eslint-plugin-import": "^2.7.0",
    "eslint-plugin-jsx-a11y": "^5.1.1",
    "eslint-plugin-meteor": "^4.1.6",
    "eslint-plugin-react": "^7.3.0",
    "jest": "^20.0.4"
  },
2

Posting the output of your build when you set METEOR_PROFILE=1 would probably be the most useful bit of info here.

1 Like
3

I know this topic is a bit old but I was wondering what resolution you found or conclusion you made. I am seeing my meteor bundle build take close to 3Gb or memory as well. This runs up against some constraints for building in the cloud. I can either deal with LONG build times while my build instance swaps to disk to handle the memory needs or I could bump up my current hosting plan to accommodate this… neither which is ideal. Can the bundle build process be tweaked to build more efficiently?

1 Like
4

The Meteor-up workflow gets around this by building on the dev machine and only pushing the tarball to the server before extracting it into a docker container and running npm install to ensure native deps are compiled correctly for the target.