angular-cli: ng build --prod OOM
Versions
OS: Debian Stretch
_ _ ____ _ ___
/ \ _ __ __ _ _ _| | __ _ _ __ / ___| | |_ _|
/ △ \ | '_ \ / _` | | | | |/ _` | '__| | | | | | |
/ ___ \| | | | (_| | |_| | | (_| | | | |___| |___ | |
/_/ \_\_| |_|\__, |\__,_|_|\__,_|_| \____|_____|___|
|___/
Angular CLI: 6.0.0-rc.7
Node: 8.11.1
OS: linux x64
Angular: 6.0.0-rc.6
... animations, common, compiler, compiler-cli, core, forms
... http, platform-browser, platform-browser-dynamic
... platform-server, platform-webworker
... platform-webworker-dynamic, router, service-worker
Package Version
------------------------------------------------------------
@angular-devkit/architect 0.5.10
@angular-devkit/architect-cli 0.5.10
@angular-devkit/build-angular 0.5.10
@angular-devkit/build-ng-packagr 0.5.10
@angular-devkit/build-optimizer 0.5.10
@angular-devkit/build-webpack 0.0.8
@angular-devkit/core 0.5.10
@angular-devkit/schematics 0.5.10
@angular-devkit/schematics-cli 0.5.10
@angular/cdk 6.0.0-rc.13
@angular/cli 6.0.0-rc.7
@angular/flex-layout 6.0.0-beta.15
@angular/material 6.0.0-rc.13
@ngtools/json-schema 1.2.0
@ngtools/webpack 6.0.0-rc.8
@schematics/angular 0.5.10
@schematics/package-update 0.3.2
@schematics/schematics 0.5.10
@schematics/update 0.5.10
rxjs 6.0.0
typescript 2.7.2
webpack 4.6.0
Repro steps
git clone https://github.com/buu700/cyph-ng6-test.gitcd cyph-ng6-testnpm install .ng build --prod
Observed behavior
2 4 6 6 6 92% chunk asset optimization UglifyJSPlugin s
<--- Last few GCs --->
[1712:0x3d4b6e0] 428216 ms: Mark-sweep 1472.2 (1607.6) -> 1472.1 (1607.6) MB, 1500.0 / 0.0 ms allocation failure GC in old space requested
[1712:0x3d4b6e0] 430995 ms: Mark-sweep 1472.1 (1607.6) -> 1471.9 (1571.6) MB, 2777.9 / 0.0 ms last resort GC in old space requested
[1712:0x3d4b6e0] 433430 ms: Mark-sweep 1471.9 (1571.6) -> 1471.9 (1568.6) MB, 2433.7 / 0.0 ms last resort GC in old space requested
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0x2edfc9d257c1 <JSObject>
1: def_variable [0x4d324d822d1 <undefined>:~5199] [pc=0x1c494a884151](this=0xfcaa76a1f81 <AST_Function map = 0x3c3d27db53c9>,symbol=0x10aafa3b15f1 <AST_SymbolVar map = 0x2493e4398469>,init=0x4d324d82201 <null>)
2: visit [0x4d324d822d1 <undefined>:~4898] [pc=0x1c494a7874f8](this=0xeb7273e1649 <TreeWalker map = 0x3404dd422ac9>,node=0x10aafa3b15f1 <AST_SymbolVar map = 0x2493e4398469>,descen...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: node::Abort() [ng]
2: 0x11e7fec [ng]
3: v8::Utils::ReportOOMFailure(char const*, bool) [ng]
4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [ng]
5: v8::internal::Factory::NewFixedArray(int, v8::internal::PretenureFlag) [ng]
6: v8::internal::HashTable<v8::internal::StringTable, v8::internal::StringTableShape>::NewInternal(v8::internal::Isolate*, int, v8::internal::PretenureFlag) [ng]
7: v8::internal::HashTable<v8::internal::StringTable, v8::internal::StringTableShape>::New(v8::internal::Isolate*, int, v8::internal::PretenureFlag, v8::internal::MinimumCapacity) [ng]
8: v8::internal::HashTable<v8::internal::StringTable, v8::internal::StringTableShape>::EnsureCapacity(v8::internal::Handle<v8::internal::StringTable>, int, v8::internal::PretenureFlag) [ng]
9: v8::internal::StringTable::LookupString(v8::internal::Isolate*, v8::internal::Handle<v8::internal::String>) [ng]
10: 0x10a21ae [ng]
11: v8::internal::Runtime_KeyedGetProperty(int, v8::internal::Object**, v8::internal::Isolate*) [ng]
12: 0x1c4948d042fd
Aborted
Desired behavior
Successful build.
Mention any other details that might be useful (optional)
Failure occurs in a Docker container with 6.5 GB RAM allocated.
Building without --prod succeeds , and CLI version 1.7.4 works fine.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 3
- Comments: 18 (10 by maintainers)
I’m sorry, but I don’t see it as professionally acceptable for production builds to require 4GB+ of RAM to complete. Our build servers handle many different builds of different products, and the angular production builds by far use 2-10x more resources than any other builds.
Why is this considered acceptable for builds to consume 4GB+ of RAM? Furthermore, it seems like there is no upper bound on what is deemed acceptable. A project could potentially grow to a size that would require 8GB-16GB of RAM…or more…it could potentially scale endlessly until the machine is physically unable to support more RAM. In contrast, I can build a C++ project with 4 million lines of code, and 10 times as many external libraries with 2GB or less…
Are there plans to address this? I understand this probably isn’t the angular-cli directly that is the root issue. However, if it lies with a third party package like webpack, then should it be discussed internally to contribute to webpack to fix this issue - or even try and move away from webpack entirely?
I can’t be the only one who takes extreme issue with the nonchalant stance of “just increase the heap memory available” that seems to be circulating around the issue tracker here.
^ Seems like I’m using more than the default node memory limit of 1.76 GB.
Changed the
ng buildcommand to use 4GB of memory instead and it worked.Cool, all sounds good to me.
Oops, sorry, apparently the same command in our master branch (Angular 5 / rxjs 5.5 / CLI 1.7.4) actually does also use a bunch of RAM and crash. I guess I’d just never had a reason to use
ng build --proddirectly, since for prod builds pre-v6 we were using a custom build script that ejected and split up the output into smaller chunks (#10550).It was just a one-off thing for the repro, but I also didn’t have any specific plans to take it down. I’ll make one last commit there to fix the build failure (it needs a small patch to fix an issue in a third-party library), then afterwards feel free to fork and maintain it for future benchmarks.
Edit: The latest version of my test project now builds with no errors.