GeezerVison is showing github.com — webpack ng serve runs out of memory · Issue #1652 · angular/angular-cli
webpack ng serve runs out of memory #1652Description
Please provide us with the following information:
- OS? Windows 7, 8 or 10. Linux (which distribution). Mac OSX (Yosemite? El Capitan?)
Windows 10
- Versions. Please run
ng --version. If there's nothing outputted, please run
in a Terminal: node --version and paste the result here:
angular-cli: 1.0.0-beta.11-webpack.2
node: 6.3.1
os: win32 x64
- Repro steps. Was this an app that wasn't created using the CLI? What change did you
do on your code? etc.
Keep ng serve running and serving a cli built app while coding for some time (a few hours?)
- The log given by the failure. Normally this include a stack trace and some
more information.
...
94% asset optimization
<--- Last few GCs --->
12936118 ms: Mark-sweep 1360.3 (1435.0) -> 1356.1 (1435.0) MB, 959.3 / 0 ms [all
ocation failure] [GC in old space requested].
12936973 ms: Mark-sweep 1356.1 (1435.0) -> 1356.0 (1435.0) MB, 854.9 / 0 ms [all
ocation failure] [GC in old space requested].
12938085 ms: Mark-sweep 1356.0 (1435.0) -> 1356.0 (1435.0) MB, 1112.2 / 0 ms [la
st resort gc].
12939012 ms: Mark-sweep 1356.0 (1435.0) -> 1355.8 (1435.0) MB, 926.7 / 0 ms [las
t resort gc].
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 000001F1975C9E51 <JS Object>
1: replace [native string.js:~129] [pc=0000018EE86B74E5] (this=000000EF14282
331 <String[61]: D:/it/node_modules/@angular/common/src/pipes/common_pipes.js>,
N=000000EF140824C9 <JS RegExp>,O=00000135F03D7F21 <String[10]: !(webpack)>)
2: shorten [D:\it\node_modules\webpack\lib\RequestShortener.js:~41] [pc=000
0018EE4290DA2] (this=0000020E88D58019 <a RequestShortener with map 00000313C3C4.
..
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memo
ry
- Mention any other details that might be useful.
Only happened once so far but thought it worth mentioning
Thanks! We'll be in touch soon.
Reacted by Umed Khudoiberdiev, jagdish-176, Dessalines, Ruslan Arkhipau, Omer Alper, Ashok Mandal, rebelwolfson, Anthony Ciccarello, Moein Pakkhesal, Joel Hernández and 15 more Activitykylecordes commented on Aug 11, 2016 I am thinking about a good way to test this. I already have a little stress test program that generates a working program with a given number of components. But unfortunately it also generates the exact same program each time. So I'm thinking about making it slightly randomize the contents of the programs it generates so that it generates changed files each time. Then run it in a loop and see how much RAM leaks. kylecordes commented on Aug 11, 2016 OK, I made a way to test this. I enhanced the "angular 2 stress test" tool:
https://www.npmjs.com/package/angular2-stress-test
To stress test "ng serve":
- install angular2-stress-test
ng new test-projectcd test-projectng serve- leave "serve" running, and make a second command window to work in
cd src/appfor i in seq 1 1000; do angular2-stress-test 500 -r ; sleep 5 ; done- While that runs, keep an eye on RAM and CPU use the ng serve Node process
In my testing as above:
- Starting up the first time, ng serve uses 463MB of RAM
- After running for a little while, it was over 1000MB of RAM
This shows that ng serve keep using more RAM over time, as it keeps recompiling after each change. However, offhand I would guess that reducing this increase, is pretty far down the priority list of the CLI team! Reacted by Chen Reuven Reacted by Sakthivel kylecordes commented on Aug 11, 2016 I'm interested in whether anyone plays with this, with various settings, modes (-prod ?), platforms (windows linux mac) etc. TheLarkInn commented on Aug 13, 2016 @kylecordes I believe that this could be related to webpack-dev-server but I'm not 100% sure where to look specifically. One thing that comes to mind is that in situations where webpack is running in its dev server, everything compiled is cached because it is an in-memory file system. So any convention that is using a hash in its name is going to be stored in memory until the end of time. See this explanation here.
So I think the first thing I will need to do is find instances of us in our codebase using the webpack [hash], [chunkhash], or [id] properties inside of our filenames for the ng serve and default --target='production' target. TheLarkInn commented on Aug 13, 2016 I think that if this is happening on just plain default ng serve this is definitely a bug, however it is essentially unavoidable in --prod target.
We separated the idea of --prod and --dev targets but made them agnostic to and unmodifiedng serve task/command so people would have a more realistic local production experience.
I think in terms of --prod we need to simply document the long term use affects. TheLarkInn commented on Aug 17, 2016 @slubowsky @kylecordes I did a little hands on memory profiling and heapshot analysis. (I couldn't do it locally so @hansl helped me).
Long story short things were either pointing towards the Compilation or some TS Services retaining some objects after Garbage collection was occuring.
Luckily we just merged in a kind contribution in webpack that fixes a V8 bug causing memory leaks in the webpack compilation. I believe that this is what is causing the issue, however I think it warrents still following up after we cut a release (on the webpack team), and update it here.
https://github.com/webpack/webpack/pull/2497/files kylecordes commented on Aug 17, 2016 @TheLarkInn Thanks, sounds good. I will repeat the tests I described earlier in the thread, when the next new release comes out... or for that matter anyone else could try it also. MartinFreire commented on Nov 21, 2017 Hi, in my case, none of the solutions above worked for me.
I commented here about my execution crashing when it goes above 500 mb
I leave you here the link in case that thread is useful to someone nhustak commented on Nov 28, 2017 Thanks @rejayi-experion Modifying NG.cmd didn't work but just invoking it manually as you suggested did. JBGoldberg commented on Dec 11, 2017 Anyone have a more definitive solution for this? Anyone comment that @TheLarkInn is working in the issue. There is another thread open to this issue? isahyarima commented on Dec 29, 2017 node --max_old_space_size=2048 ./node_modules/.bin/ng Worked for me thanks thecheeto commented on Feb 8, 2018 For anyone that might be trying to debug why all of a sudden the build process started running out of memory, I was able to track the issue down to the following code in my project.
Before change (out of memory exception):
handleResponse(response: Response) {
if (response.status == 403) {
this.authenticationService.expireAuthToken();
return Observable.throw('Session Timeout');
}
let json = response.json();
return Observable.of({
success: false,
errors: json
});
}
After change (no memory issues):
handleResponse(response: Response): Observable<any> { // <--- ADDED return type
if (response.status == 403) {
this.authenticationService.expireAuthToken();
return Observable.throw('Session Timeout');
}
let json = response.json();
return Observable.of({
success: false,
errors: json
});
}
Using the code of the before change, every time that method was called, it caused more and more memory being used during ng serve or ng build.
Not sure why specifying the return type fixes the issue, but went from ng build using ~3gb of memory down to ~700mb. vitor-belim commented on Feb 23, 2018 @thecheeto Did you add this modification to every function within your project? And even if it returns void? thecheeto commented on Feb 23, 2018 @vitor-belim No, only on that function. I'm thinking it has something to do with differing return types in a function. In my case it was returning either an ErrorObservable or Observable<{success: boolean, errors: string[]}>. prudhvichitturi commented on Jan 28, 2019 This has been changed in angular 7 now. I couldn't able to find the path of ng.. Please any help for finding its path in node modules..
`> node --max_old_space_size=5048 ng build --prod --aot --source-map=false
module.js:540
throw err;
^
Error: Error: Cannot find module '/Users/work/ui/node_modules/@angular/cli/bin/ng'
at Function.Module._resolveFilename (module.js:538:15)
at Function.Module._load (module.js:468:25)
at Function.Module.runMain (module.js:684:10)
at startup (bootstrap_node.js:187:16)
at bootstrap_node.js:608:3
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build-script-a7: node --max_old_space_size=5048 ng build --prod --aot --source-map=false
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] build-script-a7 script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /Users/.npm/_logs/2019-01-28T08_13_45_344Z-debug.log
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build: npm run config -- --environment=prod && npm run build-script-a7 && npm run prod-server
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /Users/.npm/_logs/2019-01-28T08_13_45_364Z-debug.log` strizich commented on Jan 31, 2019 @prudhvichitturi node --max_old_space_size=5048 ./node_modules/.bin/<ng command> httpete commented on Feb 15, 2019 this worked for me:
"start": "node --max_old_space_size=5048 ./node_modules/@angular/cli/bin/ng serve",
Reacted by Ashan Fernando, Golovskoy Nickolay, Purushottam Jha, Oleh Kolinko and Manuel Giron uriel2095 commented on Apr 17, 2019
"scripts": {
"ng-custom-serve": "node --max_old_space_size=5048 ./node_modules/@angular/cli/bin/ng serve"
}
as suggested by @RicTheThird
this is what i have done to resolve,having ng serve as well,but will this hold good?,what if the application grows?Can we hope on this and go ahead?Any help would be great?
this is simple and fuction for me :3 pauldraper commented on Apr 18, 2019 It's weird that I have to tell Angular CLI/Node.js how much memory it can use.
Chrome/V8 seems happy to use all my memory. Reacted by Renan Rodrigues and adamdport angular-automatic-lock-bot commented on Sep 9, 2019 This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|