Meteor won't start with "max-old-space-size" - solved

help
1

If I set max-old-space-size anything over 4095 meteor won’t start. No error, no message, nothing. Even meteor reset won’t work.
Before I had max-old-space-size=8192, a few days ago I updated a project to 1.7.0.3 and even projects I didn’t update won’t start now.
This is happening on my development pc (windows 10). I didn’t dare to deploy anything since than.

1 Like
2

How are you setting this parameter?

What version of Meteor was it on before the update?

3

I have a batch file that contains the following line and also sets up other environment variables before calling meteor run.
set NODE_OPTIONS=–max-old-space-size=8192

Project I was working on was METEOR@1.6.0.1.
I didn’t update that project. I updated a sample I downloaded which had METEOR@1.4.3.2
Instead of running it with 1.4.3.2, I ran “meteor update”. Didn’t specify which version to update.
METEOR@1.7.0.3 was installed on my development pc first time.
After I was done with the sample, I noticed my project doesn’t start anymore.
I played around and found the limit 4095. It works fine with 4095 but no more.

4

Okay, I’m officially :confused: right now! These are some comments in no particular order, which may help you isolate the issue.

  • The NODE_OPTIONS environment variable was added at (I think) Node v6.12. Prior to that, it would have been ignored. Node v6 never made it into Meteor, so NODE_OPTIONS would only have any effect from Meteor v1.6 onwards (Node v8).
  • Running Meteor in development mode (using the meteor command) always uses the correct version of Node for the version of Meteor the project is using. In other words, your 1.6.0.1 project should be running (as it always has) with Node v8.9.3. If you were successfully using --max-old-space-size with that before, it should still be okay. It may be worth confirming the Node version by running meteor node -v in the 1.6.0.1 app’s root.
  • Deploying a Meteor app (if done correctly) uses the version of Node you supply. It’s not so much a Meteor app at that point, as a Node app. For obvious reasons that should match the version used when you developed it.
  • It may be worth checking your system’s memory. Do you have a guaranteed 8GiB free? If not, you will end up using swap space to extend memory, which is s-l-o-o-o-w. If you have no swap space configured, it will most likely fall over.
1 Like
5

I just tried with a few different projects I have on development pc. With all node versions below “meteor node -v” will print the node version if I set --max-old-space-size=4095 and it will NOT print with --max-old-space-size=4096

v8.11.3
v8.9.4
v8.9.3
v4.8.4
v4.8.1

I have 32GB memory installed on development pc. I verified it when I tested that I have more than 10GB free, no swap at all.

6

It gets weird !!!

When I start v1.6.0.1 project I see 3 node.exe instances in task manager.
2 of them are 64 bit and running from %LOCALAPPDATA%.meteor\packages\meteor-tool\1.6.0_1\mt-os.windows.x86_64\dev_bundle\bin
1 is 32 bit and running from %LOCALAPPDATA%.meteor\packages\meteor-tool\1.7.0_3\mt-os.windows.x86_32\dev_bundle\bin

32bit process looks idle, 0% cpu, 2.7MB memory consumption.

Checking %LOCALAPPDATA%.meteor\packages\meteor-tool\1.7.0_3 folder, it looks like only 32bit is installed with update.

Why running a v1.6.0.1 project would start node.exe from v1.7.0.3 in the first place ?

7

It sort of looks like you’ve got a mix of the old Meteor tool (32-bit) and the new chocolatey tool (64-bit). Maybe the 32-bit is an unterminated relic?

8

NODE_OPTIONS would affect the memory allocation for your app process. But if startup is an issue, then try changing the memory allocation of the build tool, which can be done by setting TOOL_NODE_FLAGS.

Meteor 1.7.0.3 build was slow for my app too, worse than 1.6.0.1 just like your case. It was quite slow even with TOOL_NODE_FLAGS=–max-old-space-size=8192, and slightly better with TOOL_NODE_FLAGS=–max-old-space-size=8192 --no-expose-gc (see this github issue), but still slower than 1.6.0.1

The new Meteor 1.7.1 seems to be performing much better. Last checked with 1.7.1-beta.19 and build is faster than even 1.6. Just waiting for it to be released before committing to the upgrade

9

Problem was caused by updating a project older than 1.6.x A clean re-install solved the problem.

2 Likes