Version 9: performance issues & out of memory errors #16860
Comments
filipesilva
changed the title
filipesilva
changed the title
|
ng build -c mhsb |
|
We solve this problem (when compile with ng build -c mhsb) we use following command. .\ngs.cmd build -c mhsb ngs.cmd: @node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng %1 %2 %3 %4 %5 When we use this command, when the compile process reaches 92% after 10 minutes, it encounters the error below. |
|
@alialtun14 are you seeing this with version 9 now, and did it not happen with version 8? I'd like to take a look at the project if possible. Giving me access to a new private github repository is a good way of doing this for private projects. |
|
We have taken same error when we used "ng build -c mhsb". We have solved this problen i V8 by using max_old_space_size=8192. Today after upgrading to V9 and compile with max_old_space_size=8192 we started the error again. |
Our project is in gitlab reposiyory. If you share your email adrese with alialtun14@gmail.com. I can share zip file of our project. |
|
Hi - error in private company repo:
ps. dont suggest by dir nam - it is ng9 ;) |
|
@4zriel I edited your comment to remove a large chunk of terser warnings in the log that I reviewed and know is not relevant to the problem at hand. I removed it because it was very long and made it hard to read the rest of this issue thread. |
|
@alialtun14 I just tried building with the increased memory and it seemed to build fine: What version of node are you on? There were a couple of node versions that had memory problems. I am on Node v12.4.0. @4zriel what version of node are you on as well? Can you try the one I mentioned above, or perhaps considering sharing the project privately with me? |
|
@filipesilva |
|
@4zriel since you have a monorepo, I think you might be suffering from case 2 in https://angular.io/guide/ivy-compatibility#payload-size-debugging. Can you try the approach described in #16799 (comment) and see if it works please? To be clear, the approach is to add |
filipesilva
added
severity4: memory/performance
type: RFC / discussion / question
and removed
severity4: memory/performance
labels
|
@filipesilva That's it! :D You are awasome! I spend like 2h at least on this, read through the docs and other issuess but all I need was just 'sideEffects: false'! :D |
|
Glad to hear it helped! |
|
We transferred the project to Angular 9. Thank you for your interest and help. We can now build with enableIvy: false. When we make Enable Ivy: true and compile, we get errors. We are now in the process of eliminating those errors. |
|
after fixing errors related to compiling with Ivy enableIvy = false enableIvy = true |
We started using node v12.15.0 with Angular 9. After node v12.15.0, we can compile "node node_modules/@angular/cli/bin/ng build -c mhsb" without any memory problems. Thank you for your interest and help. |
|
@alialtun14 oh wow that's a great improvement, glad to hear! |
|
Btw @alialtun14 I noticed you have a |
PS D:\QLASS> ng build -c mhsb --vendorChunk=false |
|
@filipesilva According to the blog post by @StephenFluin, bundle size in large app can reduce maximum %40 with ivy compile. In our project we reached to %68 in size and % 72 in time reduction. Is this an expected result or are we making a mistake somewhere :) This result was a great and pleasing surprise for us.
|
|
If your app is working properly, I don't think you've done anything wrong. Your project might be a new record for size savings with Ivy :D |
We started using in production after compiled. There were a few problems we encountered during the compilation. We fixed the problems with your support. |
|
@filipesilva I am not sure if it is related to this issue but: I am getting this error in CircleCI. But it builds perfectly in local or Heroku. CLI version: 9.0.2 Disabling optimization works but it is not desirable. Things I tried and did not work:
I see that https://github.com/webpack-contrib/terser-webpack-plugin#parallel |
|
@KurtGokhan we use the parallel option but let |
Same problem here! my build minutes from angular 8 to angular 9 uses are 2X (2 charge $$ |
|
Any solution on the horizon? Memory consumption of Version 9 is truly terrible. Using Angular 9 for large projects is now practically impossible. |
|
@AlexRixhardson where's your problem exactly? I'm building a pretty large project without any major troubles Edit: NGCC results are cached ofcourse and regenerated every time the package.json or package lock changes |
|
I've been dealing with this issue for two nights now. Started with Bitbucket pipeline crashing yesterday with OOM exception. I've bumped up the memory to size 2x which is the max on Bitbucket cloud (8mb). I've tested locally using a local Docker instance and have been able to reproduce the same error 137. I've tried the following changes:
All the above would either crash with 137 error either during 40% of webpack or during es2015 to esm2015 conversion. Typically at the same spots. Here is the original Angular configuration that crashes: I then decided to downgrade the CLI to 9.0.7 which then allowed for things to work sometimes. I then bumped up the memory allocation locally to 16GB and the build worked properly. So it teams the memory consumption has jumped at some point recently to over 8GB based on the number of dependencies, components, etc. For me it keeps stopping at 69% progress on the build instances before exceeding 8GB. When I run it locally with 16GB of memory in a Docker container I can get it to build. Here is some more data that may help: Numer of modules when it completes successfullyNumber of modules approximately where it stops at 69%.By turning off sourceMaps I was able to go from 40% of the way to 69%. By disabling "optimization" and "buildOptimization" in angular.json I was able to get to 92% in my latest build before it died at 8GB. I have yet to figure out why it jumped so bad in the last week. Maybe it was near the limit and just went over but I was using the same version of CLI and Angular before the error started. Any additional thoughts on what to tweak? |
|
We've identified a memory regression in |
|
Same here moving from 9 to 10.0.1, node 14.4 ' Ineffective mark...' |
|
This issue is affecting hundreds of people with real-world apps. If there is no workaround, then this needs to be fixed as soon as possible. |
|
Upgrading ng9 to ng10 has caused our builds in Bitbucket to fail even with max memory using 2x option. Build also spits out: Two people have spent a whole day trying to fix this, to no avail. Looks like we'll have to abandon the update. "dependencies": { / △ \ | '_ \ / Angular CLI: 10.0.6 Angular: 10.0.10 Package Version@angular-devkit/architect 0.1000.6 |
|
@kleky - are you running ngcc separately or is it being run as part of a CLI build? Also, are you running multiple builds in parallel? One thing you could try is running ngcc as a postinstall step on your CI to avoid it having to be run during builds, where there would be additional memory pressure from the build tooling. |
It appears that the out of memory was maybe caused by ngcc running async. I had a postinstall script running ngcc, but after making it We also thought bitbucket was running at 2x memory, but it wasn't. After adding |
|
Facing the same issue after upgrading from |
|
Had this issue, after updating a project from angular 9 to 10. After running the command ng s I get the memory error
Angular CLI: 10.0.8 Angular: 10.0.14 Package Version@angular-devkit/architect 0.1000.8 |
|
Was facing the same issue running our bitbucket pipeline after upgrading from Angular8 to Angular 10. Was fixed by upgrading node version from 10.x to 12.x and adding "NODE_OPTIONS=--max_old_space_size=4096" command to the pipeline steps before the ng test step. |
|
I think it has more to do with the fact that at some point a angular-cli application now uses dart-sass, but where I'd see maybe 5 seconds tops to recompile my scss files after styling update or initial build (so basically negligible), now take a good 2+ minutes. 2 minutes each and every time scss changes made. |
|
Was there another regression in v10? Our build with max-old-space=3072 was building OK but got flaky after upgrade to 10. Setting max space to 4096 did not help either, but maybe 8192 will be enough - at least build got green once! The only error I could see was this: So maybe it's not memory related? We are using node 12.13.1 Anyway for context, here is the output of successful build: |
|
|
|
Little update, bumping I ended prioritizing and migrating to node 14, which so far looks promising. Did not see the same error yet. Sad part is that underlying cause is still unclear. So my/our issue does not seem to be related to memory. Any tips how would one debug something like this? EDIT: Still flaky build. At least now error has a bit more information: |
|
Now with Angular 11...
|
|
I was facing the same issue after updating angular 9 to 10. it took 4 days to figure out the issue. Solution: just install a node-sass library or if already installed then update the supported version. (i reinstalled node v14 and node-sass@4.14) |
|
Ugly hack workaround. This patch prevents a bunch of jest workers sucking up 1.5GiB extra RAM. RAM usage spike went from 3.5GiB to 2GiB for all processes during ng build --prod:
const MAX_CPUS = 1;
const os = require('os');
if (process.env.JENKINS_URL) {
// Only warn on the parent process
if (process.env.JENKINS_URL !== 'patch_warned') {
console.warn(`JENKINS_URL=${process.env.JENKINS_URL} detected, forcing reduced workers`);
process.env.JENKINS_URL = 'patch_warned';
}
const cpus = os.cpus;
os.cpus = () => cpus().slice(0, MAX_CPUS);
const utils = require('@angular-devkit/build-angular/src/utils/workers');
if (utils.maxWorkers > 1) {
throw new Error('Failed to patch maxWorkers in @angular-devkit/build-angular');
}
os.cpus = cpus;
} |
|
@jamie-pate, thanks. It is really helpful! Was searching for this last 3 days.
@filipesilva Please, we really need a configuration parameter to manually control the Terser workers count. |
|
Downgrading |
|
We have the same problem after migrating from angular 9 to angular 11. Fixed it by setting |
|
I upgraded my node version from 10 to 14, solved the issue for me. |
|
A lot has changed since version 9. Please update to the most recent version of Angular CLI. v12 build time performance issues are being tracked here: #20792 |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
and others
If you are experiencing performance problems or out of memory errors with Angular CLI version 9, please let us known on this issue.
The text was updated successfully, but these errors were encountered: