Closed ghost closed 5 years ago
@notsonotso an ng team member told me this has to do with poor recursion handling in @ngtools/webpack
, i'm curious what webpack's faults are?
@zackschuster its mere existence
Started happening to me using macOS 10.13 On Windows it builds fine, both machines using the same configuration and have 16 gigs of ram.
I went back to version 1.2.x and didn't have any exceptions there.
1.3.x and 1.4.x all gave the memory exception.
@filipesilva Is there any news regarding to this issue? I'm curious why a semi-large project needs more than 2 gigs to build. I am not familiar with the inner workings of the compilation process, but it seems rather high to me.
EDIT:
using the --build-optimizer flag causes the issue, it was working fine, but I recently upgraded the cli and I see that it uses a newer build-optimizer (0.0.31), maybe memory leak on the optimizer?
@MrBlaisee you mean 20* Go
!!
try ng build --aot --sourcemaps=false
,
it seems there is problem with sourcemaps
.
Lol with or without sourcemap it depend how long node is working! Hope this will be fixed one day
I am using 6.9.4 Nodejs and Angular 4.5, Angular-cli 1.4.6 but no lucks
We need hacks above.
Got an issue resolved on one of the machine using below:
Try this out: In "ProjectDirectory\node_modules\.bin" modify webpack.cmd to:
@if EXIST "%~dp0\node.exe" ( "%~dp0\node.exe --max_old_space_size=4096 " "%~dp0..\webpack\bin\webpack.js" % ) ELSE ( @SETLOCAL @set PATHEXT=%PATHEXT:;.JS;=;% node --max_old_space_size=4096 "%~dp0..\webpack\bin\webpack.js" % )
and try to build. Basically, its going to use --max_old_space_size=4096 with node webpack build.
See if that helps.
Angular 5 and angular-cli 1.5. Have problems --aot
95% emitting
<--- Last few GCs --->
152742 ms: Mark-sweep 1261.4 (1434.1) -> 1261.4 (1434.1) MB, 471.1 / 0.0 ms [allocation failure] [scavenge might not succeed].
153236 ms: Mark-sweep 1261.4 (1434.1) -> 1261.4 (1434.1) MB, 493.7 / 0.0 ms [allocation failure] [scavenge might not succeed].
153757 ms: Mark-sweep 1261.4 (1434.1) -> 1268.2 (1418.1) MB, 520.5 / 0.0 ms [last resort gc].
154333 ms: Mark-sweep 1268.2 (1418.1) -> 1275.0 (1418.1) MB, 575.8 / 0.0 ms [last resort gc].
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 000003AFBC7CFB61 <JS Object>
1: DoJoin(aka DoJoin) [native array.js:~129] [pc=00000055CD16A7F7] (this=000003AFBC704381 <undefined>,w=0000011B90EE0C21 <JS Array[539]>,x=539,N=000003AFBC
7043C1 <true>,J=000003AFBC7AE4E1 <String[1]: >,I=000003AFBC7B46F1 <JS Function ConvertToString (SharedFunctionInfo 000003AFBC752DC9)>)
2: Join(aka Join) [native array.js:180] [pc=00000055CD1D6A52] (this=000003AFBC704381 <undefined>...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
Also hit this memory issue. Can be 'resolved' by using the build script node --max-old-space-size=4096 ./node_modules/@angular/cli/bin/ng build --prod
but hopefully this bug will be fixed soon. Why does it need over 2GB of memory?!
Also facing the same issue currently, our app has over 50 components spread across 6 modules.
We are experiencing the same issue... eclipsing 3GB of memory in a medium-large application. We have ~20 modules each with 5-8 components.
Hey all, I'm seeing a lot of new reports of this happening after 1.5 is out. One of the changes we did for 1.5 was to use Build Optimizer by default on Angular version 5 projects. Build optimizer does indeed use a lot of memory (https://github.com/angular/devkit/issues/240).
Can you tell me if turning off build optimizer helps with your memory crashes? You can do it with --build-optimizer=false
. Turning off sourcemaps can also help via --sourcemaps=false
.
If these options don't help, can you post here the full failure log please, including command run?
--build-optimizer=false
helps in my case.
I have a large app (30 modules, 263 components).
With @angular: 4.4.6 ; @angular/cli: 1.4.9 I can get a --prod build with --max_old_space_size=6144
but with @angular: 5.0.0 ; @angular/cli: 1.5.0 I run out of memory even with --max_old_space_size=8192
. I can get a build with --max_old_space_size=10240
, but my CI does not support that configuration.
> node --max_old_space_size=8192 ./node_modules/@angular/cli/bin/ng build --prod
<--- Last few GCs --->
387148 ms: Mark-sweep 4983.1 (8230.5) -> 4987.2 (8230.5) MB, 860.4 / 0.0 ms [allocation failure] [scavenge might not succeed].
387947 ms: Mark-sweep 4987.2 (8230.5) -> 4987.3 (8230.5) MB, 798.9 / 0.0 ms [allocation failure] [scavenge might not succeed].
388816 ms: Mark-sweep 4987.3 (8230.5) -> 5002.0 (8214.5) MB, 869.3 / 0.0 ms [last resort gc].
389619 ms: Mark-sweep 5002.0 (8214.5) -> 5017.0 (8214.5) MB, 802.0 / 0.0 ms [last resort gc].
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0x2199619cfb39 <JS Object>
1: DoJoin(aka DoJoin) [native array.js:~129] [pc=0x29bfc23b9949] (this=0x219961904381 <undefined>,w=0x3864fdc19d1 <JS Array[537]>,x=537,N=0x2199619043c1 <true>,J=0x2199619ae4b9 <String[1]: >,I=0x2199619b46c9 <JS Function ConvertToString (SharedFunctionInfo 0x219961952dc9)>)
2: Join(aka Join) [native array.js:180] [pc=0x29bfc2ccdb52] (this=0x219961904381 <undefined>,w=0x3864fdc19d1 <JS ...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: node::Abort() [/Users/*****/.nvm/versions/node/v6.11.0/bin/node]
2: node::FatalException(v8::Isolate*, v8::Local<v8::Value>, v8::Local<v8::Message>) [/Users/*****/.nvm/versions/node/v6.11.0/bin/node]
3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/Users/*****/.nvm/versions/node/v6.11.0/bin/node]
4: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [/Users/*****/.nvm/versions/node/v6.11.0/bin/node]
5: v8::internal::Runtime_StringBuilderJoin(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/*****/.nvm/versions/node/v6.11.0/bin/node]
6: 0x29bfae0092a7
Angular CLI: 1.5.0
Node: 6.11.0
OS: darwin x64
Angular: 5.0.0
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router
@angular/cli: 1.5.0
@angular-devkit/build-optimizer: 0.0.32
@angular-devkit/core: 0.0.20
@angular-devkit/schematics: 0.0.35
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.0
@schematics/angular: 0.1.0
typescript: 2.4.2
webpack: 3.8.1
However, with --build-optimizer=false
I can build with --max_old_space_size=6144
> node --max_old_space_size=6144 ./node_modules/@angular/cli/bin/ng build --prod --build-optimizer=false
Date: 2017-11-04T23:08:35.111Z
Hash: afdf23d865ad76d6c3a7
Time: 252357ms
chunk {0} 0.5fdb723fb2afdf8bc41a.chunk.js (common) 657 kB [rendered]
chunk {1} 1.9d7656022b2d3d139dc3.chunk.js () 9.23 MB [rendered]
chunk {2} 2.0fd8e1693141dc5c5223.chunk.js () 3.15 MB [rendered]
chunk {3} main.46f18abd9489952e107d.bundle.js (main) 3.43 MB [initial] [rendered]
chunk {4} polyfills.0acd42e0b1fa025cc794.bundle.js (polyfills) 222 kB [initial] [rendered]
chunk {5} styles.27285cfcd50901377a47.bundle.css (styles) 583 kB [initial] [rendered]
chunk {6} vendor.6b76d39b8f45ef045486.bundle.js (vendor) 1.1 MB [initial] [rendered]
chunk {7} inline.e8ad567f621efe38acfe.bundle.js (inline) 1.52 kB [entry] [rendered]
Tests with angular-cli 1.5
ng build --prod build-optimizer=false --sourcemaps=false (I canceled after 12 minutes running)
node --max_old_space_size=4096 node_modules/@angular/cli/bin/ng build --prod build-optimizer=false --sourcemaps=false (work after 4,2 minutes)
@filipesilva, @hansl, Before anything, thanks so much for this project- Angular has been great for our team. We love the framework and we love the CLI so thanks for all your hard work.
This memory issue seems like it is becoming a real problem. I'm looking for some messaging from the Angular team around expectations here, and I'd be happy to give whatever data is necessary to help move it forward.
Our team is an enterprise team with a medium-large app. We ran into this memory issue a while back, and upped the max_old_space_size
to 1GB and then later 2GB. Each time it solved our problem for a few months. But as the app continues to grow we've run into it again now and we can't do this forever. Our toolchain uses Bitbucket pipelines, which like many other CI's maxes out available memory (3GB is our max given our other needs), so we're beginning to run up against a wall.
I've been taking some benchmarks with our app, it looks like you're correct in your post above: 1.5.0, with --build-optimizer=false
uses equivalent memory to 1.4.5.
Our app has ~180 components and ~30 services across ~22 modules. I'd like to think it is constructed in a reasonably smart manner, following best practices and general clean code design. The build --aot --build-optimizer=false --sourcemaps=false
for this project using 1.5.0 now takes about 2925 GB of memory.
Two general questions for you and others, about (1) expectations and (2) short-term alleviation:
(1) Is Angular built for enterprise development? If so, this issue seems to be of the highest priority and the community deserves more frequent and clear messaging on this. If not, your users need to know this because lots of decisions across hundreds of companies ride on that.
(2) Are there any recommendations from the Angular team about ways to alleviate this issue?
Again, I'd be happy to test any theories/provide data about our large application to help get to the bottom of this, and again, thanks for all the hard work you've done on this.
In our case, the build optimizer nor the sourcemaps flags were effective. Downgrading to @angular/cli 1.4.9 fixed it.
Worked without either flag set false:
ng build -prod
@angular/cli: 1.4.9
node: 6.9.2
os: linux x64
@angular/common: 4.4.6
@angular/compiler: 4.4.6
@angular/core: 4.4.6
@angular/forms: 4.4.6
@angular/http: 4.4.6
@angular/platform-browser: 4.4.6
@angular/platform-browser-dynamic: 4.4.6
@angular/router: 4.4.6
@angular/cli: 1.4.9
@angular/compiler-cli: 4.4.6
typescript: 2.3.4
DIDN'T Work even with both flags set false:
ng build -prod --build-optimizer=false --sourcemaps=false
Angular CLI: 1.5.0
Node: 6.9.2
OS: linux x64
Angular: 4.4.6
... common, compiler, compiler-cli, core, forms, http
... platform-browser, platform-browser-dynamic, router
... tsc-wrapped
@angular/cli: 1.5.0
@angular-devkit/build-optimizer: 0.0.32
@angular-devkit/core: 0.0.20
@angular-devkit/schematics: 0.0.35
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.0
@schematics/angular: 0.1.0
typescript: 2.3.4
webpack: 3.8.1
...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
We have not tried the hacks above on changing the old space memory... our application isn't apparently as big as some of the others on this thread, but yet fails on cli 1.5.0.
@filipesilva: --build-optimizer=false and --sourcemaps=false works for me with cli 1.5. Without them, I was getting "JavaScript heap out of memory". Thanks for your help!
Happens for me also. Wired part is error thrown after bundle files generated.
Angular CLI: 1.5.0 Node: 8.9.0 OS: win32 x64 Angular: 5.0.0
<--- Last few GCs --->
[12192:00000000004C39A0] 236834 ms: Mark-sweep 1420.3 (2200.9) -> 1420.3 (2159.4) MB, 578.6 / 0.0 ms last resort GC in old space requested [12192:00000000004C39A0] 237461 ms: Mark-sweep 1420.3 (2159.4) -> 1420.3 (2136.9) MB, 627.2 / 0.0 ms last resort GC in old space requested
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 000000B4C7AA5EC1
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
npm ERR! code ELIFECYCLE
npm ERR! errno 3
npm ERR! mobx-ui-test-app@0.0.0 build:prod: ng build --env=prod --prod --aot --stats-json --named-chunks=true --sourcemaps=false
npm ERR! Exit status 3
==== update ====== Issue for me is --stats-json. Build is fine after remove this flag.
Optimizations are welcome, but on the other hand memory is cheap. Until optimizations are here run the build using
node --max-old-space-size=8192 ./node_modules/@angular/cli/bin/ng build
and append whatever switches you'd like to the end. To make it easier to run, edit your package.json file and add this line to "scripts":
"serve": "node --max-old-space-size=8192 ./node_modules/@angular/cli/bin/ng serve --aot"
Then you can execute it using
npm run serve
I'm an old Java dev, so this seems familiar to me somehow :)
@swftvsn, memory is cheap if you have control over it, but we deploy to a Docker swarm, and containers have limited memory. This is a pretty serious issue for us. I'd prefer a slower build if that means caching stuff to disk and not running out of memory.
I am getting this issue after upgrading to cli 1.5 and angular 5.0.
I want to highlight the question above:
I am so confused why any compiler would need 4 gigs of memory to compile a web app..... To get it to compile aot post upgrade I had to jack the memory up to 4 gigs. Our app has 2 feature module libraries each with about 15 modules, ~60 modules in the main app, and ~15 services. We have a lot left to build as well.
I would imagine it has to do with the obscene amount of dependencies + all the hoops that are done to statistically analyze all the dependencies and your code in order to shake the trees. Take a look at node_modules if you dare. (And source / debug maps and things I don't even know about)
Excessive memory consumption is usually caused by a lot of data and/or abstraction over abstraction over abstraction over... :) Or a bug.
For now I'm happy and I just feed the beast. I do hope it looses some of it's appetite in the coming versions though..
I'm less concerned about "how could this possibly...?" than I am about the lack of communication.
The compilation itself is doing some pretty heavy lifting right now. It's really great actually. The entire CLI is. It bundles this thing up and serves it pretty compactly. In fact his may be a testament to just how easy Angular makes it to build large scale web apps... their size is outpacing the toolchain.
I'm just looking for the Angular team to set expectations here, that's all:
Any answer to those questions is okay... but it's important that those answers (and their progress) are communicated to the community in an iterative fashion. My team and many other teams need to make decisions based off those answers, and right now we feel frozen.
This is an open source project that we're all getting for free. It's added tremendous value already even with this issue; so some people are being awfully critical given this. At the same time, open communication is integral to the success of solid open source projects: we're looking to the Angular team for that leadership.
@filipesilva , @hansl?
That's an excellent summary @dpxxdp !
Recent upgrade our project to Angular 5 and Angular CLI 1.5.
We have 100+ components and 20+ modules. The build --prod
is taking forever and finally throw heap out of memory exception which is very frustrating!
As I mentioned here a few months ago, I have a very large project with several modules too, +120 pages, +500 components (pages are divided into at least 3 components like grid, form).
To get ng build -prod to work I had to test on a machine with 32 Gb of RAM, nodeJS consumed 28 Gb to compile the project. Impressive.
The solution was actually put 32 Gb as virtual memory on the machine (swap). In addition, of the already known "--max_old_space_size".
The label of this issue should be priority: 1 (urgent)
rather than priority: 2 (required)
@swftvsn I am still not getting it. Maybe it is because I come from .NET where the c# compiler would tear through a project with comparable amounts of classes without breaking a sweat.
@Tolitech This is exactly the main point. If we need machines with 32 GB of ram to build the project, some cloud agents won't be able to handle this/aren't configurable to upgrade the hardware. Thus, we would need to make architectural decisions to start building segmented SPAs to keep the size of a project down, catering to compiler limitations.
@dpxxdp While I do agree that it is great that it is free and open source (thanks as well team!), I don't feel that it is a criticism to report a major bug/functional limitation that requires a hardware upgrade as a work around. I don't think anyone is trying to criticize the work that was done, but rather increase the priority on this issue.
guys 2 workaround for heap problem
ng build --app app -aot=true -e=prod -sm=false -ec=true --named-chunks=false -oh=all -pr=false
this will generate bundles without minification and general size for vendor bundle will increased in my case for 8%. Build time decreased for twice, but minification step take long time 6-7 min in CI machine (2gb). I use gulp for post build actions in my case its uglify js and postcss.My app ~72 services (CRUD operation + some general logic) ~10 pipe ~15 directive ~170 components ~ 80 model class (data from API) ~ 15 module
as for me i want some flags to set optimization step count, tree shake deep (function, class, variable)
Hi all,
I've bumped the priority on this issue and will be working on it. We didn't consider it to be as urgent before because the solution at the time was to increase the available memory to node, which defaults to 1.7gb. So it was expected that at some point projects would need more memory than the default.
However with the release of 1.5 the memory requirements seem to have increased dramatically. Projects that didn't have any memory problems before now do. 32gb is definitely a ridiculous amount of RAM and shouldn't be needed.
At this point I'm not sure what caused the memory spike but have a few hypothesis. With CLI1.5 + Angular 5 we use a new pipeline that does better type checking by using a full TS program. Maybe there's a bad cache somewhere in there, or the TS program is taking a lot of memory. Another possibility is Uglify, which we had to upgrade as well. Or it might be something in the AOT compiler itself. We also default build optimizer to true now and it's not really optimized for neither speed nor memory.
If you're running into this problem and have time, I'd appreciate if you could answer a couple questions:
ng build --prod
?ng build --prod --build-optimizer=false
ng build --aot
ng build --aot --build-optimizer
In response to above comment: CLI 1.5.0, Angular 5.0.1
Project: Services: 9 Components: 43 Models: 28 Lines of ts: 8200 Lines of sass: 5000
Heap error happens with:
ng build --prod
: yes
ng build --build-optimizer=false
: no
ng build --aot
: no
ng build --aot --build-optimizer
: no
@filipesilva About 20 modules, 30 services, 80 components
Can't show the repo unfortunately
@filipesilva
What version of the CLI and Angular are you on?
1.5.0 angular 5.0.1
Does this only happen on ng build --prod?
yes
Do you still get the memory error with these build commands:
ng build --build-optimizer=false
no
ng build --aot
no
ng build --aot --build-optimizer
no
@filipesilva Windows 7 Pro 64-bit 12 Gigs of ram CLI 1.5.0, Angular 5.0.0
Project details: ~120 components 15 modules
Do you still get the memory error with these build commands: ng build --prod: yes ng build --build-optimizer=false: no ng build --aot: no ng build --aot --build-optimizer: yes
On Angular 4.3 with ~180 components with ~30 services with ~22 modules
With CLI 1.5 Does this only happen on ng build --prod? Yes
ng build --build-optimizer=false less than 2GB ng build --aot --build-optimizer=false ~2.8GB ng build --aot over 3 GB
With CLI 1.4.5 Does this only happen on ng build --prod? Yes
ng build --build-optimizer=false less than 2GB ng build --aot --build-optimizer=false ~2.8GB ng build --aot ~2.8 GB
Our repo is private unfortunately
CLI 1.5.0, Angular 5.0.0
Modules: ~50 Services: ~110 Components: ~290
ng build --prod
: fail
ng build --prod --build-optimizer=false
: fail
ng build --prod --build-optimizer=false --sourcemaps=false
: fail
ng build --prod --aot=false
: works
ng build
: works
ng build --aot=true
: works
ng build --aot=true --build-optimizer=true
: fail
What version of the CLI and Angular are you on?
@angular/cli@1.5.0
, @angular 5.0
Does this only happen on ng build --prod? yes
Do you still get the memory error with these build commands:
ng build --build-optimizer=false
: NO
ng build --aot
: NO
ng build --aot --build-optimizer
: NO
Under cli1.5 & angular5
Ng build —prod : YES Ng serve —aot : first time NO but after editing file YES it throw error out of memory... blockin at 0%
Ng serve : NO all’s okay and fast (but wait a lot to show result in browser because of JiT compiler)
Cc @filipesilva
The versions I am using CLI - 1.2.0 and Angular 4.2.5 Modules: ~ 130 Components: ~ 200 Services: ~ 70
getting the build issues with below options.
ng build --prod: fail ng build --aot=true: fail ng build --aot=true --sourcemaps=false : Works most of the times and very often it is failing. ng build --prod --aot=false : works
@cecotw sarcasm is sometimes misinterpreted. And I'm not here to fire up any flamewars, your ecosystem is obviously the better :)
I had experienced the issue FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
with ng build --prod
. I have solved the problem by using
node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod
You can add also in
package.json
as
"scripts": {
"prod": "node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod",
}
npm run prod
What version of the CLI and Angular are you on?
Angular CLI: 1.5.0
Node: 8.5.0
OS: darwin x64
Angular: 5.0.0
... animations, common, compiler, core, forms, http
... platform-browser, platform-browser-dynamic, router
@angular/cdk: 5.0.0-rc0
@angular/cli: 1.5.0
@angular/compiler-cli: 5.0.1
@angular/flex-layout: 2.0.0-beta.10
@angular/language-service: 5.0.1
@angular/material: 5.0.0-rc0
@angular-devkit/build-optimizer: 0.0.32
@angular-devkit/core: 0.0.20
@angular-devkit/schematics: 0.0.35
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.0
@schematics/angular: 0.1.2
typescript: 2.4.2
webpack: 3.8.1
Does this only happen on ng build --prod? NOT SURE Do you still get the memory error with these build commands:
also:
If you have a project that I can look at, can you link it please?
we have a gitter channel if you need help to build our project and have a look:
Same issue. Upgraded to A5. ng build --prod results in out of memory error below. The error does not occur without --prod. Increasing the --max_old_space_size is not really the answer, something is fundamentally wrong and has stopped our A5 upgrade going anywhere.
Please fix!
<--- Last few GCs --->
243344 ms: Mark-sweep 1000.9 (1434.4) -> 1003.2 (1434.4) MB, 452.4 / 0.0 ms [allocation failure] [scavenge might not succeed]. 243760 ms: Mark-sweep 1003.2 (1434.4) -> 1003.2 (1434.4) MB, 416.3 / 0.0 ms [allocation failure] [scavenge might not succeed]. 244187 ms: Mark-sweep 1003.2 (1434.4) -> 1012.9 (1418.4) MB, 427.0 / 0.0 ms [last resort gc]. 244591 ms: Mark-sweep 1012.9 (1418.4) -> 1022.8 (1418.4) MB, 403.8 / 0.0 ms [last resort gc].
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0x957966cfb39
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: node::Abort() [/usr/local/bin/node]
2: node::FatalException(v8::Isolate, v8::Local
What version of the CLI and Angular are you on?
@angular/cli: 1.4.9
node: 6.11.0
os: win32 x64
@angular/animations: 4.4.6
@angular/cdk: 2.0.0-beta.12
@angular/common: 4.4.6
@angular/compiler: 4.4.6
@angular/core: 4.4.6
@angular/flex-layout: 2.0.0-beta.9
@angular/forms: 4.4.6
@angular/http: 4.4.6
@angular/material: 2.0.0-beta.12
@angular/platform-browser: 4.4.6
@angular/platform-browser-dynamic: 4.4.6
@angular/router: 4.4.6
@angular/cli: 1.4.9
@angular/compiler-cli: 4.4.6
typescript: 2.6.1
ng build --prod
- Success
ng build --build-optimizer=false
- Success
ng build --aot
- Success
ng build --aot --build-optimizer
- OOME
A sanity-check local run of ng serve --prod --aot
gave me failure at a later time
Date: 2017-11-12T22:52:55.879Z
Hash: 456f57f84be9de32704e
Time: 185523ms
chunk {0} polyfills.5dbd24b37bdff70c0320.bundle.js (polyfills) 66.1 kB {4} [initial] [rendered]
chunk {1} main.a2ba9af755957e20aa31.bundle.js (main) 1.98 MB {3} [initial] [rendered]
chunk {2} styles.2dfc00976daefa57d973.bundle.css (styles) 80.3 kB {4} [initial][rendered]
chunk {3} vendor.c5146d2ca93aff011cac.bundle.js (vendor) 1.51 MB [initial] [rendered]
chunk {4} inline.7e6f8c72074764ba2a48.bundle.js (inline) 1.45 kB [entry] [rendered]
webpack: Compiled successfully.
<--- Last few GCs --->
277448 ms: Mark-sweep 1225.3 (1434.4) -> 1225.3 (1434.4) MB, 1086.6 / 0.1 ms [allocation failure] [scavenge might not succeed].
278456 ms: Mark-sweep 1225.3 (1434.4) -> 1225.3 (1434.4) MB, 1008.4 / 0.1 ms [allocation failure] [scavenge might not succeed].
279488 ms: Mark-sweep 1225.3 (1434.4) -> 1236.2 (1418.4) MB, 1030.8 / 0.1 ms [last resort gc].
280607 ms: Mark-sweep 1236.2 (1418.4) -> 1247.1 (1418.4) MB, 1117.0 / 0.1 ms [last resort gc].
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 00000126BFCCFB49 <JS Object>
1: DoJoin(aka DoJoin) [native array.js:~129] [pc=000003FAD779BBD7] (this=00000126BFC04381 <undefined>,w=0000033E0E885D01 <JS Array[334]>,x=334,N=00000126BFC043C1 <true>,J=00000126BFCAE4C9 <String[1]: >,I=00000126BFCB46D9 <JS Function ConvertToString (SharedFunctionInfo 00000126BFC52DC9)>)
2: Join(aka Join) [native array.js:180] [pc=000003FAD73F9FB2] (this=00000126BFC04381 <undefined>...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
In my project everything was working fine in --prod --aot
mode up until a day ago when I decided to migrate to HttpClient
to prepare for the Angular 5 / CLI 1.5 switch. No version changes, no CLI changes were involved.
I upgraded my services and moved some error/auth logic to a couple of interceptors. My vendor dev bundle went from 15MB to 6MB and I was all impressed. Then I decided to sanity check my prod aot build with ng serve --prod --aot
and I started getting the OOME.
Seeing the same issue after upgrading to cli 1.5, Angular 1.5 and HttpClient
$ ng build --aot --prod
95% emitting
<--- Last few GCs --->
224719 ms: Mark-sweep 1304.7 (1434.7) -> 1304.7 (1434.7) MB, 485.6 / 0.0 ms [allocation failure] [scavenge might not succeed]. 225206 ms: Mark-sweep 1304.7 (1434.7) -> 1304.7 (1434.7) MB, 487.0 / 0.0 ms [allocation failure] [scavenge might not succeed]. 225685 ms: Mark-sweep 1304.7 (1434.7) -> 1304.7 (1418.7) MB, 479.3 / 0.0 ms [last resort gc]. 226180 ms: Mark-sweep 1304.7 (1418.7) -> 1304.7 (1418.7) MB, 494.5 / 0.0 ms [last resort gc].
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0x3e4edad3fa99
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: node::Abort() [/usr/local/bin/node]
2: node::FatalException(v8::Isolate, v8::Local
<--- Last few GCs --->
224540 ms: Mark-sweep 1305.3 (1444.7) -> 1305.3 (1444.7) MB, 476.2 / 0.0 ms [allocation failure] [scavenge might not succeed]. 225007 ms: Mark-sweep 1305.3 (1444.7) -> 1305.3 (1444.7) MB, 466.7 / 0.0 ms [allocation failure] [scavenge might not succeed]. 225479 ms: Mark-sweep 1305.3 (1444.7) -> 1305.3 (1428.7) MB, 471.9 / 0.0 ms [last resort gc]. 225970 ms: Mark-sweep 1305.3 (1428.7) -> 1305.3 (1428.7) MB, 491.1 / 0.0 ms [last resort gc].
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0x67c5bb3fa99
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: node::Abort() [/usr/local/bin/node]
2: node::FatalException(v8::Isolate, v8::Local
PACKAGE.JSON "dependencies": { "@angular/animations": "^5.0.1", "@angular/cdk": "2.0.0-beta.12", "@angular/common": "^5.0.1", "@angular/compiler": "^5.0.1", "@angular/core": "^5.0.1", "@angular/forms": "^5.0.1", "@angular/http": "^5.0.1", "@angular/material": "2.0.0-beta.12", "@angular/platform-browser": "^5.0.1", "@angular/platform-browser-dynamic": "^5.0.1", "@angular/router": "^5.0.1", "@swimlane/ngx-charts": "6.1.0", "core-js": "^2.4.1", "d3": "^4.4.0", "jquery": "2.2.0", "ng2-cookies": "1.0.3", "ng2-dnd": "^2.1.1", "reflect-metadata": "0.1.8", "rxjs": "^5.5.2", "semantic-ui": "2.2.2", "socket.io-client": "^1.7.2", "sockjs-client": "^1.1.4", "stompjs": "^2.3.3", "zone.js": "^0.8.4" }, "devDependencies": { "@angular/cli": "1.5.0", "@angular/compiler-cli": "^5.0.1", "@types/jasmine": "2.5.38", "@types/node": "~6.0.60", "codelyzer": "~2.0.0", "jasmine-core": "~2.5.2", "jasmine-spec-reporter": "~3.2.0", "karma": "~1.4.1", "karma-chrome-launcher": "~2.0.0", "karma-cli": "~1.0.1", "karma-coverage-istanbul-reporter": "^0.2.0", "karma-jasmine": "~1.1.0", "karma-jasmine-html-reporter": "^0.2.2", "protractor": "~5.1.0", "ts-node": "~2.0.0", "tslint": "~4.5.0", "typescript": "~2.6.1" }
EDIT working with the --max_old_space_size=8192
fix above**
Also getting the exact same. Angular 4 build time, 2 minutes maybe? New angular 5 build time is 25 to fail with:
ng build --prod --output-path=dist/client
92% chunk asset optimization <--- Last few GCs --->
1327460 ms: Mark-sweep 1306.9 (1405.9) -> 1306.9 (1414.9) MB, 1826.0 / 0.0 ms [allocation failure] [GC in old space requested]. 1329363 ms: Mark-sweep 1306.9 (1414.9) -> 1306.9 (1414.9) MB, 1903.1 / 0.0 ms [allocation failure] [GC in old space requested]. 1331374 ms: Mark-sweep 1306.9 (1414.9) -> 1313.4 (1405.9) MB, 2010.3 / 0.0 ms [last resort gc]. 1333333 ms: Mark-sweep 1313.4 (1405.9) -> 1319.9 (1405.9) MB, 1958.0 / 0.0 ms [last resort gc].
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 000002E7514CF791
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
Any update on this? This issue was raised back in March and is now manifesting itself in Angular 5 (and 4) prod builds. Seems somehow to be related to HttpClient.
Please can you investigate as a priority as we can not go to production using Angular 5, which is currently not fit for purpose.
Bug Report or Feature Request (mark with an
x
)Versions.
Repro steps.
ng build --prod --aot
The log given by the failure.
Desired functionality.
I would like to be able the app using AOT.
Mention any other details that might be useful.
I have tried changing
ng.cmd
to this:and
ngc.cmd
to:I have 8GB swap file. The build fails after 20-25 minutes standing on 92% progress.