Production build peak memory +53% after upgrading @angular/build 21.2.13 → 22.0.0 (same code, same esbuild version)

Command

build

Is this a regression?

Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

@angular/build 21.2.13 / Angular 21.2.15 / TS 5.9.3

Description

After upgrading to Angular 22, our production build's peak memory rose from ~15.5GB to ~23.8GB (+53%), which started OOM-killing our 16GB CI runners. A/B measurement on the identical commit of a large Nx monorepo (~7,400 TS
files, ~2,250 components, single application target), cold build cache, default workers, sampling combined RSS of the full node + esbuild process tree every 3s:
Toolchain │ Peak RSS │
@angular/build 21.2.13, Angular 21.2.15, TS 5.9.3 │ 15.5GB │
@angular/build 22.0.0, Angular 22.0.0, TS 6.0.3 │ 23.8GB │
@angular/build 22.0.1, Angular 22.0.0, TS 6.0.3 │ 22.3GB │

esbuild is 0.28.0 in both setups (unchanged).
The application code is identical in both runs (the v21 build needed only ignoreDeprecations adjusted in tsconfig).
22.0.1's stylesheet-bundler leak fixes (fix(@angular/build): prevent concurrent stylesheet bundling esbuild context leaks #33318) recover ~1.5GB but the bulk of the increase remains.
NG_BUILD_MAX_WORKERS=2 makes peak memory worse (31.8GB), not better.
Caveat: TypeScript necessarily moved 5.9.3 → 6.0.3 with the Angular major, so we cannot separate the TS 6 share of the increase from @angular/build 22 itself.
Symptom on constrained machines: host OOM killer fires (or esbuild dies with fatal error: all goroutines are asleep - deadlock! when Node's --max-old-space-size exceeds physical RAM).

Minimal Reproduction

Private repo, so I can't share a reproduction, but happy to run instrumented builds / --stats-json / heap profiles on request.

Exception or Error

Your Environment

Node 24.16.0, npm 11.x, macOS 27 (arm64) + Linux CI, Nx 21.3.2

Anything else relevant?

No response

perf(@angular/build): release compilation resources before post-bundl…

Good morning.

Do you have an estimate of when this issue will be resolved? In which version might it be fixed?

I ask because currently, in QA and development environments, when Angular performs a pre-render build, my application cluster crashes due to the high resource consumption of Angular 22.

This prevents me from deploying to production and moving forward with the release of my application.

If there are no updates, we will have to revert to Angular 22 for the time being, which we would greatly regret.

Regards

@clydin

@clydin @alan-agius4 looks like someone mentioned this issue in commit above and that can be low-hanging fruit for fixing it.

Can you please verify if this is still an issue with 22.1.0-rc.0?

@pumano

Hello @pumano @alan-agius4

I've checked version 22.1.0-rc.0 and there seems to be a noticeable improvement in resource usage.

I'll have to run more thorough tests, but it feels like we have the same performance as Angular 21.

Attached is a screenshot of the reviewed metrics. We're talking about CPU usage reaching 4 GHz and memory usage reaching 8 GB before applying version 22.1.0-rc.0.

Regards

If increasing memory of your machines is not feasable right now, you can consider running a custom node.js build with ./configure --experimental-enable-pointer-compression and halve node.js memory usage. See also https://blog.platformatic.dev/we-cut-nodejs-memory-in-half

The catch: If any of your workloads need more than 8gb of RAM, this wont work for you, as that flag caps memory at 4gb per node.js worker (a 8gb heap becomes a 4gb heap with pointer-compression, hence the 4gb limit can be seen as a 8gb limit if you are measuring a "normal node.js" thread).

It's not fully official yet. If you want to know why you can read nodejs/build#4352 and follow the breadcrumbs all the way back to 2020. But maybe if more people use it, it may gain traction.

Of course if angular cli could use less memory that would be very welcome too. But using pointer-compression and fixing memory issues aren't mutually exclusive.

@pumano

Good morning @pumano @alan-agius4

Can you confirm that version https://github.com/angular/angular-cli/releases/tag/v22.1.0 contains the commit pennydesigns@057b61a

I ask because I don't see the commit specified in the changelog.

Regards

If increasing memory of your machines is not feasable right now, you can consider running a custom node.js build with ./configure --experimental-enable-pointer-compression and halve node.js memory usage. See also blog.platformatic.dev/we-cut-nodejs-memory-in-half

The catch: If any of your workloads need more than 8gb of RAM, this wont work for you, as that flag caps memory at 4gb per node.js worker (a 8gb heap becomes a 4gb heap with pointer-compression, hence the 4gb limit can be seen as a 8gb limit if you are measuring a "normal node.js" thread).

It's not fully official yet. If you want to know why you can read nodejs/build#4352 and follow the breadcrumbs all the way back to 2020. But maybe if more people use it, it may gain traction.

Of course if angular cli could use less memory that would be very welcome too. But using pointer-compression and fixing memory issues aren't mutually exclusive.

I haven't tried, but pointer compression restricts the processes to use a maximum of 4GB. Builds that are affected by this issue will generally exceed this memory usage naturally.

@Davidgimenez1997

Hey @Davidgimenez1997, that commit isn't part of the 22.1.0 release. I also couldn't track down a PR for it.

Version 22.1.0 does come with a bunch of performance fixes, though could you give it a try and see if it resolves your issue?

@alan-agius4

Good morning @alan-agius4 !

After conducting several performance tests, it has been observed that Angular version 22.1.0 shows improvements, but it still doesn't reach the performance of the latest version, 21.

Attached are graphs of a service that waits for pre-rendered build triggers (where an increase in resource consumption was detected after the update).

The CPU and memory spikes occur because the service starts (performs a pre-rendered build) and immediately receives a build trigger, which is normal.

Is it possible to control Node.js resource consumption during the Angular build process so that a pre-rendered build doesn't consume so many resources?

Thank you very much for your answers!

I appreciate your feedback.

I just attempted an upgrade to Angular 22.1 and CI still crashes, while it didn't in Angular 21:

Killed
fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan receive]:
github.com/evanw/esbuild/internal/helpers.(*ThreadSafeWaitGroup).Wait(...)
	github.com/evanw/esbuild/internal/helpers/waitgroup.go:36
main.runService.func2()
	github.com/evanw/esbuild/cmd/esbuild/service.go:114 +0x53
main.runService(0x1)
	github.com/evanw/esbuild/cmd/esbuild/service.go:160 +0x637
main.main()
	github.com/evanw/esbuild/cmd/esbuild/main.go:252 +0xb16

goroutine 22 [chan receive]:
main.runService.func1()
	github.com/evanw/esbuild/cmd/esbuild/service.go:98 +0x45
created by main.runService in goroutine 1
	github.com/evanw/esbuild/cmd/esbuild/service.go:97 +0x1ce

goroutine 23 [chan receive]:
main.(*serviceType).sendRequest(0xea5dc710ff0, {0xa10be0, 0xea60baa6ae0})
	github.com/evanw/esbuild/cmd/esbuild/service.go:192 +0x12b
main.runService.func3()
	github.com/evanw/esbuild/cmd/esbuild/service.go:125 +0x3e
created by main.runService in goroutine 1
	github.com/evanw/esbuild/cmd/esbuild/service.go:122 +0x2c7
Deleting duplicate background files.  []
Failed to build Angular for brand falco-test with return code 137.

And to further address the pointer compression suggestion, I doubt it would have any impact at all, given it's the Go process that seems to be OOMing.

perf(@angular/build): release build resources early in non-watch mode

perf(@angular/build): release build resources early in non-watch mode (…

@alan-agius4

@alan-agius4 Thanks for the new Angular CLI version, it did indeed resolve the issue! Thanks a lot!

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.}

Navigation Menu

Repository navigation

Production build peak memory +53% after upgrading @angular/build 21.2.13 → 22.0.0 (same code, same esbuild version) #33368

Command

Is this a regression?

The previous version in which this bug was not present was

Description

Minimal Reproduction

Exception or Error

Your Environment

Anything else relevant?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Production build peak memory +53% after upgrading @angular/build 21.2.13 → 22.0.0 (same code, same esbuild version) #33368

Description

Command

Is this a regression?

The previous version in which this bug was not present was

Description

Minimal Reproduction

Exception or Error

Your Environment

Anything else relevant?

Activity

Davidgimenez1997 commented on Jul 28, 2026

pumano commented on Jul 28, 2026

alan-agius4 commented on Jul 28, 2026

Davidgimenez1997 commented on Jul 28, 2026

sod commented on Jul 28, 2026

Davidgimenez1997 commented on Jul 30, 2026

wartab commented on Jul 30, 2026

alan-agius4 commented on Jul 30, 2026

Davidgimenez1997 commented on Jul 31, 2026

wartab commented on Jul 31, 2026

wartab commented on Aug 6, 2026

angular-automatic-lock-bot commented on Oct 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions