Hallo, im Fehler-Stack-Trace scheint es, dass Sie eine andere Konfiguration als "Produktion" verwenden. Können Sie diese Konfiguration freundlicherweise freigeben?

Entschuldigung für die Nichtübereinstimmung hier sind die Konfigurationsparameter, die Sie benötigen

"config": {
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "extractCss": true,
              "namedChunks": false,
              "aot": true,
              "extractLicenses": true,
              "vendorChunk": false,
              "buildOptimizer": true,
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.config.ts"
                }
              ]
            }

Ich habe den gleichen Fehler:

Mein env:

Leute hier haben die "Problemumgehung" für dieses Problem beschrieben: https://github.com/angular/angular-cli/issues/5618

• [ ] Neu
• [ ] bauen
• [X] dienen prod
• [ ] Prüfung
• [] e2e

Ich stehe vor dem gleichen Problem, während ng serve --prod

Referenzbild

Ich habe den gleichen Fehler bekommen. Der NodeJs-Prozess verwendet etwa 1,5 GB RAM und schlägt nach einigen Minuten des Versuchs, den Speicher zu bereinigen / zuzuweisen, mit einem Fehler fehl.

UPDATE: -

Ich habe dieses Problem nur auf WINDOWS-Computern gesehen . Hat das noch jemand bemerkt? Oder haben Sie das gleiche Problem bei anderen Maschinen?

Hinweis: Ich habe 2 Windows-Computer ausprobiert, alle Tests ergaben das gleiche Ergebnis. Beide Maschinen haben fast die gleiche Konfiguration.
dh 8 GB RAM / Administratorzugriff für Bash / CMD / PowerShell / i3- und i5-Prozessor (Quad-Core, beide).

Und ich gebe zu, dass das Projekt, an dem ich arbeite, eine MESS in Bezug auf die Codequalität ist.
Ich habe einen sauberen Code ausprobiert, eine vollwertige Anwendung, ON WINDOWS , die im Erstellungsprozess langsamer war , aber gut funktioniert hat.

Ich habe den Code des MESSY-Projekts ausprobiert, der bei der Standardzuweisung des Knotenheaps nie kompiliert wurde (ca. 1,2 GB, nicht sicher). Es funktioniert, wenn ich dem Knotenprozess mehr Heapspeicher zuweise, z. B. 5 GB. Aber auch in diesem Fall dauerte der Bau mehr als 30 Minuten. Ich habe die Node Heap-Option 5 GB mit und ohne --aot AND / OR --prod ausprobiert.

Der gleiche Code, der auf CentOS ausprobiert wird, könnte eine Instanz von 1 GB RAM / Virtual Xenon-Prozessor (1 Kern) sein und innerhalb von 90 Sekunden einen Build generieren. mit und ohne --aot UND / ODER --prod

Ich bin mir nicht sicher, aber es sieht so aus, als ob das Problem beim Node Service und nicht bei der Angular CLI selbst liegt, da ich in neuen NodeJS-Versionen nach dem letzten Update einige Leistungsverzögerungen festgestellt habe (nur lokal auf dem WINDOWS-Computer).

Einige Beobachtungen unten.:-

Obwohl 5 GB Heap zugewiesen wurden, wurden nie mehr als 1,9 GB (max.) Verwendet, und der Zuweisungsprozess war sehr langsam. Der RAM-Verbrauch stieg um 1-2 MB pro 3-5 Sekunden. Und verwendete Disk Resource nicht mehr wie früher in einer älteren Version. (Der Festplattenzugriff war zuvor auf dem WINDOWS-Computer sehr hoch, aber der Erstellungsprozess war ohne zusätzliche RAM-Zuweisung schneller. Diesmal war derselbe Computer fast derselbe Code mit einigen Fehlerkorrekturen, aber der Knoten wurde aktualisiert, der Festplattenverbrauch wurde gesenkt, aber die Generierung wurde langsam verlangsamt.)

Hoffe, jemand kann dies bestätigen.

Ja, ich stehe auch vor dem gleichen Problem

Das gleiche Problem läuft hier auf einem Mac Book Pro. macOs Mojoave. Jede Umgebung mit Produktion: wahr

das gleiche Problem auf Ubuntu Server 18.04, aber dies löste mein Problem:
node --max_old_space_size = 8192 node_modules / @ angle / cli / bin / ng build --prod

Ich habe versucht, Angular CLI 7 zu deinstallieren und 6.0.8 installiert. Die herabgestufte Version wurde um ng version überprüft. Sie bricht jedoch mit demselben Fehler ab.

Vielleicht könnte dies auch an NodeJs liegen. Coz, ich baue den gleichen Code in CentOS 7, 1,75 GB RAM (mit 512 MB Swap-Speicher), Single-Core-Prozessor und mit eckiger CLI 7 funktioniert er dort. Es bricht in meinen 2 Windows-Maschinen.

Für diejenigen, die es sich nicht leisten können, mehr RAM zuzuweisen (da weniger Speicher verfügbar ist), kann ein SWAP-Speicher aus dem auf der Festplatte des Systems verfügbaren Speicherplatz erstellt werden. Es wird etwas langsamer sein, sollte aber ohne System-Upgrade funktionieren. Ich habe das gleiche getan. 👍

In meinem Fall tritt das Problem nur beim Erstellen von --prod --source-map . Der normale --prod Build läuft einwandfrei.

Bei Verwendung von --max_old_space_size=8192 wie von @nokhodian vorgeschlagen , funktioniert der Speicherverbrauch während der Generierung der Quellkarte bei ~ 3,8 GB.

Build-Umgebung:

Angular CLI: 7.3.8
Node: 10.15.2
OS: linux x64
Angular: 7.2.12
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router, service-worker

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.10.4
@angular-devkit/build-angular     0.10.4
@angular-devkit/build-optimizer   0.10.4
@angular-devkit/build-webpack     0.10.4
@angular-devkit/core              7.0.4
@angular-devkit/schematics        7.1.0
@angular/cdk                      7.3.7
@angular/cli                      7.3.8
@angular/flex-layout              7.0.0-beta.19
@angular/material                 7.3.7
@angular/pwa                      0.11.0
@ngtools/webpack                  7.0.4
@schematics/angular               7.1.0
@schematics/update                0.13.8
rxjs                              6.4.0
typescript                        3.2.4
webpack                           4.19.1

In meiner angular.json-Datei habe ich "sourceMap" festgelegt: false, aber es hat mir nicht geholfen. Gleiches Problem für den Prod Build

Ich mische mich hier nur mit derselben Fehlermeldung ein, wenn ng build wenn der Build an einer bestimmten scss-Datei arbeitet

Ich habe auch dieses Problem, kann es aber mit "NODE_OPTIONS = - max-old-space-size = 8192" beheben. Die RAM-Nutzung während des Builds beträgt ca. 14 GB.

Hier gilt das gleiche. Das habe ich nach weiterer Suche gefunden. Ich habe Anweisungen an unser Team gesendet, um diese Umgebungsvariable festzulegen und auf unseren Build-Servern festzulegen. Scheint zu funktionieren und zu bauen scheint schneller zu sein als zuvor.

Bei Azure Pipelines trat das gleiche Problem auf: # https://github.com/Microsoft/azure-pipelines-image-generation/issues/854 Ich nahm an, dass es sich um ein Hosting-Problem handelt, da das Problem nicht vor Ort vorliegt .

Wir sehen auch dieses Problem. Mit ng serve ist das schlechtere, aber auch normale ng build haben jetzt Probleme. Könnte dies mit Sass zusammenhängen? Etwas scheint nicht zu stimmen.

      "old_space": {
        "memorySize": 1280512000,
        "committedMemory": 1278567272,
        "capacity": 1155253856,
        "used": 1152333192,
        "available": 2920664
      },

Oben sind meine old_space-Kopfinformationen aus dem generierten Bericht. Was könnte dazu führen, dass diese Zahlen so groß werden?

Hat jemand dies in einem Projekt erlebt, in dem kein Sass verwendet wird?

Wir haben dieses Problem, wenn wir verwenden
ng build --prod
Wird manchmal benötigt, weil wir unterschiedliche Umgebungseinstellungen verwenden.
node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng serve --prod löst das Problem, aber die Erstellungszeit wird auf 3 Minuten überschritten.
Ich denke nicht, dass dieses Problem gelöst ist

Dieses Problem ist, soweit ich das beurteilen kann, dasselbe wie https://github.com/angular/angular-cli/issues/5618#issuecomment -450151214.

Ich sehe jedoch nicht viele Dinge, die ich verfolgen und untersuchen kann. @themanojshukla erwähnte, dass Windows viel länger dauerte . @ j3gb3rt fragt nach Sass, und ich habe in der Vergangenheit Berichte darüber gesehen, dass Sass die Dinge langsamer macht.

Hat jemand eine Reproduktion, die wir uns ansehen und versuchen können, zu debuggen?

Ich bin auf dieses Problem bei einem Projekt gestoßen, das kein Sass verwendet. Ich habe einige Umgebungstests durchgeführt, weil ich ursprünglich dachte, dass es sich um ein Problem im Zusammenhang mit Azure Dev Ops handelt.

Verwenden von Azure Dev Ops-Pipelines:

• Gehosteter Linux-Agent mit Knoten 10: Build erfolgreich
• Gehosteter Windows vs2017-Agent mit Knoten 10: Build schlägt fehl
• Gehosteter Windows vs2017-Agent mit Knoten 6: Build schlägt fehl
• Gehosteter Windows vs2019-Agent mit Knoten 10: Build schlägt fehl
• Gehosteter Windows vs2019-Agent mit Knoten 6: Build schlägt fehl
• Gehosteter Windows Container Agent mit Knoten 10: Build fehlgeschlagen 5/10 Versuche
• Installieren Sie Build Agent auf meinem Entwicklungscomputer (win10) mit Knoten 10: Build Succeeds
• Installieren Sie Build Agent auf meinem Entwicklungscomputer (win10) mit Knoten 6: Build Succeeds
• Entwicklungsmaschine (win10) mit cmd mit Knoten 10: Build Succeeds
• Entwicklungsmaschine (win10) mit cmd mit Knoten 6: Build Succeeds

Ja @filipesilva und @Calidus, meine Projekte verwenden auch kein Sass.

Lassen Sie mich noch einige Beobachtungen machen ...

• Das Haustierprojekt (das so viele Best Practices wie möglich befolgt), das ich vor ungefähr einem Jahr erstellt habe, hat damals sehr gut funktioniert (ich erinnere mich nicht an die CLI-Version, die ich verwendet habe). Wenn ich es jetzt mit --aot --prod baue, dauert es etwas länger als zuvor, bricht aber nie ab. Kein Sass verwendet.
• Neues Projekt (natürlich Produktionscodebasis & ich gebe zu, wirklich sehr, sehr unordentliche Codes), es bricht auf --aot --prod . Kein Sass benutzt. Bricht immer an Fenstern. Funktioniert manchmal auf Ubuntu, ohne zusätzlichen Knoten auf dem Knotenprozess zuzuweisen, aber die Erfolgsrate auf Ubuntu beträgt beispielsweise 10%.
• Ein weiteres Projekt auf mittlerer Ebene (unordentliche Codes) funktioniert ohne zusätzliche Heap-Zuordnung, benötigt jedoch sowohl unter Windows als auch unter Ubuntu etwas mehr Zeit.
• Ein anderes Haustierprojekt (das so weit wie möglich den Best Practices folgt) funktioniert bisher einwandfrei. Es müssen jedoch nur sehr wenige Dateien kompiliert werden, sodass die Verarbeitung von Lasten nicht sicher ist.

Wenn ng build --aot --prod zum ersten Mal nach dem Start / Neustart der Maschine ausgeführt wird. es dauert 57 Sekunden. danach nur noch 22-25 Sekunden.

Erster Screenshot ausführen ..

Zweiter Screenshot ausführen ..

Beide sind für das gleiche Projekt .. und sind beim Schreiben dieses Kommentars.

Ich hoffe es hilft.

Ich stehe vor dem gleichen Problem. Jedes Mal, wenn ich baue, bekomme ich "JavaScript-Heap aus dem Speicher". Ich möchte den Knoten --max_old_space_size = 8192 nicht verwenden, da dies keine bewährte Methode ist. Gibt es eine andere Möglichkeit, dies zu beheben?

@ noopur-dabhi Ich denke nicht, dass es fair ist zu sagen, dass die Verwendung von node --max_old_space_size=8192 keine bewährte Methode ist.

Es ist nichts anderes, als dem NODE-Prozess _ (der jetzt Ihre App erstellen wird) _ zu erlauben, mehr als den STANDARD-Heapspeicher (aus Ihrem RAM- oder SWAP-Bereich) zu verwenden.

Und diese Art der Zuweisung ist in den meisten Bereichen der App-Entwicklung (insbesondere der Bereitstellung) sehr verbreitet. Wenn wir beispielsweise in Java die Verwendung von Java-App-Heaps einschränken möchten, fügen wir ein zusätzliches Flag wie --Xmx64m Dies bedeutet, dass maximal 64 MB Heap-Speicher zulässig sind.

Wenn also 'Best Practice' das einzige Problem ist, ist es meines Erachtens kein Problem, node --max_old_space=8192 . Dies bedeutet, dass Sie dem NODE-Prozess erlauben, maximal 8192 MB aus dem Speicher zu verwenden. nichts mit Best Practice Concern zu tun.

Das stürzt für mich immer noch ab> irgendwelche Vorschläge?
Ich habe versucht "ng build --aot --prod"
und "node --max_old_space_size = 8192 node_modules / @ angle / cli / bin / ng build --prod"

• Angular Live Development Server hört localhost: 4200 ab . Öffnen Sie Ihren Browser unter http: // localhost : 4200 / **
  92% Chunk Asset Optimierung TerserPlugin
  <--- Letzte GCs --->

[9568: 000002A08DC547B0] 183499 ms: Mark-Sweep 1350,2 (1423,6) -> 1350,2 (1424,1) MB, 952,0 / 0,0 ms (durchschnittlicher mu = 0,111, aktueller mu = 0,000) Zuordnungsfehler GC im alten Raum angefordert
[9568: 000002A08DC547B0] 184477 ms: Mark-Sweep 1350,2 (1424,1) -> 1350,2 (1424,1) MB, 977,5 / 0,0 ms (durchschnittliches mu = 0,058, aktuelles mu = 0,000) letzter Ausweg GC im alten Raum angefordert

<--- JS Stacktrace --->

==== JS-Stack-Trace ========================================

0: ExitFrame [pc: 000001D7B1850481]

Sicherheitskontext: 0x008d8961d9b1
1: / * anonym * / [0000006BEE99B319] [C: CODEV2UXnode_moduleswebpack-sourcesnode_modulessource-maplibsource-node.js: ~ 342] pc = 000001D7B3E70B48
2: SourceNode_walk [000001779ECCDF31] [C: CODEV2UXnode_moduleswebpack-so ...

FATAL ERROR: Ineffektive Mark-Compacts nahe der Heap-Grenze Zuordnung fehlgeschlagen - JavaScript-Heap nicht genügend Speicher

Schreiben des Node.js-Berichts in die Datei: report.20190506.161503.9568.001.json
Node.js Bericht abgeschlossen
1: 00007FF775E1896A public: __cdecl v8 :: internal :: GCIdleTimeHandler :: GCIdleTimeHandler (void) __ptr64 + 4554
2: 00007FF775DC8956 uv_loop_fork + 85542
3: 00007FF775DC941D uv_loop_fork + 88301
4: 00007FF7761EE72E void __cdecl v8 :: internal :: FatalProcessOutOfMemory (Klasse v8 :: internal :: Isolate * __ptr64, char const * __ptr64) +798
5: 00007FF7761EE667 void __cdecl v8 :: internal :: FatalProcessOutOfMemory (Klasse v8 :: internal :: Isolate * __ptr64, char const * __ptr64) +599
6: 00007FF7762A2144 public: static bool __cdecl v8 :: internal :: Heap :: RootIsImmortalImmovable (int) +14068
7: 00007FF776297F52 public: bool __cdecl v8 :: intern :: Heap :: CollectGarbage (enum v8 :: intern :: AllocationSpace, enum v8 :: intern :: GarbageCollectionReason, enum v8 :: GCCallbackFlags) __ptr64 + 7234
8: 00007FF776296768 public: bool __cdecl v8 :: internal :: Heap :: CollectGarbage (enum v8 :: internal :: AllocationSpace, enum v8 :: internal :: GarbageCollectionReason, enum v8 :: GCCallbackFlags) __ptr64 + 1112
9: 00007FF776295C25 public: void __cdecl v8 :: internal :: Heap :: CollectAllGarbage (int, enum v8 :: internal :: GarbageCollectionReason, enum v8 :: GCCallbackFlags) __ptr64 + 949
10: 00007FF7762A0174 public: static bool __cdecl v8 :: internal :: Heap :: RootIsImmortalImmovable (int) +5924
11: 00007FF7763D7E4D privat: Klasse v8 :: intern :: HeapObject * __ptr64 __cdecl v8 :: intern :: Factory :: AllocateRawArray (int, enum v8 :: intern :: PretenureFlag) __ptr64 + 61
12: 00007FF7763D87E2 privat: Klasse v8 :: intern :: Handle__cdecl v8 :: internal :: Factory :: NewFixedArrayWithFiller (enum v8 :: internal :: Heap :: RootListIndex, int, Klasse v8 :: internal :: Object * __ptr64, enum v8 :: internal :: PretenureFlag) __ptr64 + 66
13: 00007FF77641B0BA public: statische Klasse v8 :: internal :: wasm :: AsmType * __ptr64 __cdecl v8 :: internal :: wasm :: AsmType :: Void (void) +69050
14: 00007FF776407A06 Klasse v8 :: internal :: MaybeHandle__cdecl v8 :: internal :: BigIntLiteral (Klasse v8 :: internal :: Isolate * __ptr64, char const * __ptr64) +127094
15: 00007FF77649AFA0 public: static int __cdecl v8 :: internal :: StoreBuffer :: StoreBufferOverflow (Klasse v8 :: internal :: Isolate * __ptr64) +64256
16: 000001D7B1850481
npm ERR! Code ELIFECYCLE
npm ERR! errno 134
npm ERR! Beendigungsstatus 134
npm ERR!
npm ERR! Dies ist wahrscheinlich kein Problem mit npm. Es gibt wahrscheinlich zusätzliche Protokollierungsausgabe oben.

Leider stehe ich vor dem gleichen Problem. Vor dem Upgrade auf 7+ konnte ich Angular App auf DevOps Azure Envinorment erstellen. Jetzt ist es nicht möglich. Ich erhalte folgenden Fehler:

FATAL ERROR: Ineffektive Mark-Compacts nahe der Heap-Grenze Zuordnung fehlgeschlagen - JavaScript-Heap nicht genügend Speicher
1: 00007FF7B388F04A v8 :: internal :: GCIdleTimeHandler :: GCIdleTimeHandler + 5114
2: 00007FF7B386A0C6 node :: MakeCallback + 4518
3: 00007FF7B386AA30 node_module_register + 2032
4: 00007FF7B3AF20EE v8 :: internal :: FatalProcessOutOfMemory + 846
5: 00007FF7B3AF201F v8 :: internal :: FatalProcessOutOfMemory + 639
6: 00007FF7B4012BC4 v8 :: internal :: Heap :: MaxHeapGrowingFactor + 9556
7: 00007FF7B4009C46 v8 :: internal :: ScavengeJob :: operator = + 24310
8: 00007FF7B400829C v8 :: internal :: ScavengeJob :: operator = + 17740
9: 00007FF7B4010F87 v8 :: internal :: Heap :: MaxHeapGrowingFactor + 2327
10: 00007FF7B4011006 v8 :: internal :: Heap :: MaxHeapGrowingFactor + 2454
11: 00007FF7B3BCCDB7 v8 :: internal :: Factory :: NewFillerObject + 55
12: 00007FF7B3C62CC6 v8 :: internal :: WasmJs :: Install + 29414
13: 0000035C75D5C5C1
npm ERR! Code ELIFECYCLE
npm ERR! errno 134

@ vindemi Sie müssen Ihre Build-Pipeline bearbeiten. Entfernen Sie die Build-Aufgabe npm und ersetzen Sie sie durch eine Befehlszeilenaufgabe mit dem folgenden Skript. node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod Stellen Sie sicher, dass Sie Ihr Arbeitsverzeichnis auf den Ordner mit Ihrer package.json setzen.

@ vindemi Sie müssen Ihre Build-Pipeline bearbeiten. Entfernen Sie die Build-Aufgabe npm und ersetzen Sie sie durch eine Befehlszeilenaufgabe mit dem folgenden Skript. node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod Stellen Sie sicher, dass Sie Ihr Arbeitsverzeichnis auf den Ordner mit Ihrer package.json setzen.

es funktioniert dank

Bemerkenswert ist auch, dass Node.js 12 seine Speicheroptionen automatisch basierend auf dem verfügbaren Systemspeicher konfiguriert.

Hat diese Lösung für irgendjemanden funktioniert? Beim gehosteten VS2017-Prozess in Azure wird immer noch der gleiche Fehler angezeigt. Hier ist meine YAML für den Schritt. Was ist die Hauptursache dafür? Wenn ich dies sogar lokal auf einem bulligen I7 laufen lasse, bekomme ich 100% CPU-Treffer und fast 5 GB RAM-Auslastung. Muss ich etwas umgestalten? Ich habe eine Reihe von Standardkomponenten mit WENIGER Dateien.

`Schritte:

• Skript: |
  Knoten --max_old_space_size = 8192
  $ (Build.SourcesDirectory) node_modules.binng.cmd build --prod
  displayName: 'Befehlszeilenskript'
  `

Error:

`## [Abschnitt] Starten: Befehlszeilenskript

Aufgabe: Befehlszeile
Beschreibung: Führen Sie ein Befehlszeilenskript mit cmd.exe unter Windows aus und schlagen Sie unter macOS und Linux.
Version: 2.148.0
Autor: Microsoft Corporation

Hilfe: Weitere Informationen

Skript generieren.
========================= Starten der Befehlsausgabe ====================== ======

[Befehl] "C: windowssystem32cmd.exe" / D / E: EIN / V: AUS / S / C "CALL" d: a_temp3e7b4265-9fa3-47c6-b6b7-b690af8bcac6.cmd "

Browserliste: caniuse-lite ist veraltet. Bitte führen Sie den nächsten Befehl yarn upgrade caniuse-lite browserslist
FATAL ERROR: Ineffektive Mark-Compacts nahe der Heap-Grenze Zuordnung fehlgeschlagen - JavaScript-Heap nicht genügend Speicher
1: 00007FF747A7F04A v8 :: internal :: GCIdleTimeHandler :: GCIdleTimeHandler + 5114
2: 00007FF747A5A0C6 node :: MakeCallback + 4518
3: 00007FF747A5AA30 node_module_register + 2032
4: 00007FF747CE20EE v8 :: internal :: FatalProcessOutOfMemory + 846
5: 00007FF747CE201F v8 :: internal :: FatalProcessOutOfMemory + 639
6: 00007FF748202BC4 v8 :: internal :: Heap :: MaxHeapGrowingFactor + 9556
7: 00007FF7481F9C46 v8 :: internal :: ScavengeJob :: operator = + 24310
8: 00007FF7481F829C v8 :: internal :: ScavengeJob :: operator = + 17740
9: 00007FF748200F87 v8 :: internal :: Heap :: MaxHeapGrowingFactor + 2327
10: 00007FF748201006 v8 :: internal :: Heap :: MaxHeapGrowingFactor + 2454
11: 00007FF747DBCBE8 v8 :: internal :: Factory :: AllocateRawArray + 56
12: 00007FF747DC2CFA v8 :: internal :: Factory :: NewTransitionArray + 58
13: 00007FF7482A6684 v8 :: internal :: CodeStubAssembler :: InitializeFunctionContext + 26932
14: 00007FF747FDCBFE v8 :: internal :: JSReceiver :: GetOwnPropertyDescriptor + 17550
15: 00007FF747FDCD69 v8 :: internal :: JSReceiver :: GetOwnPropertyDescriptor + 17913
16: 00007FF747FDEB9B v8 :: internal :: JSReceiver :: GetOwnPropertyDescriptor + 25643
17: 00007FF747FCDD94 v8 :: internal :: JSReceiver :: class_name + 4132
18: 00007FF747FDE2D9 v8 :: internal :: JSReceiver :: GetOwnPropertyDescriptor + 23401
19: 00007FF747EAACFE v8 :: internal :: LookupIterator :: PrepareTransitionToDataProperty + 478
20: 00007FF747FD1E11 v8 :: internal :: JSReceiver :: class_name + 20641
21: 00007FF747DACFE9 v8 :: internal :: wasm :: WasmCodeManager :: LookupCode + 17993
22: 00007FF747DB00A4 v8 :: internal :: wasm :: WasmCodeManager :: LookupCode + 30468
23: 0000023D7E05C5C1

[Fehler] Cmd.exe wurde mit dem Code '134' beendet.

[Abschnitt] Fertigstellung: Befehlszeilenskript`

Nein, es hat auch bei mir nicht funktioniert. Am Ende machte ich eine ganz andere Arbeit.

Möglicherweise verwenden Sie eine gleichnamige Klasse in sich.

Kommt auch mit Winkel 8 (rc4) vor. Wenn ich Sourcemaps für die Produktion ausschalte, funktioniert es wieder.

Mit Angular 8 kann ich nicht auf Azure aufbauen. Ich bin auf der höchsten Ebene der Azure Web App mit 7 GB RAM (S3). Ich habe den Trick --max_old_space_size=8192 ausprobiert, erhalte jedoch den folgenden Fehler.

Ich habe AOT für die Produktion ausgeschaltet. Ich mache meine main.js-Datei auf 3 MB anstatt auf 2,5 MB, aber sie baut auf Azure auf.
In Azure ist Knoten 10.15.2 der derzeit höchste auf dem Computer installierte Knoten.

#

# Fatal process OOM in insufficient memory to create an Isolate
#

<--- Last few GCs --->


<--- JS stacktrace --->

Failed exitCode=-1073741819, command="D:\Program Files (x86)\nodejs\10.15.2\node.exe" --max_old_space_size=8192 node_modules\@angular\cli\bin\ng build myApp --prod --configuration staging --delete-output-path=false --progress=false --outputPath D:\local\Temp\8d6e507f4dfaa02\wwwroot

@johannesjo @jsgoupil Ich denke, das Problem mit 8 hat mit einem Speicherverlust bei Produkt-Builds mit differenzieller Belastung zu tun. Können Sie versuchen, es zu deaktivieren? Siehe https://angular.io/guide/deployment#opting -out-of-differential-loading

cc @ alan-agius4

@filipesilva Nein. Behebt nichts:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

Ich habe heute Morgen ein Upgrade auf Angular 8 durchgeführt und dieses Problem festgestellt. Ich habe versucht, @filipesilva Vorschlag und es kompiliert jetzt.

https://angular.io/guide/deployment#opting -out-of-Differential-Loading

Browserlist-Datei

not dead
not IE 9-11

Gewechselt zu

dead
IE 9-11

tsconfig.json-Datei

  "compilerOptions": {
    "target": "es2015"
    ...

Gewechselt zu

  "compilerOptions": {
    "target": "es5"
    ...

@johannesjo @jsgoupil benutzt du sass / scss?

@filipesilva ja.
@ gak10100 hast du sourceMap auf true in der angle.json gesetzt?

@johannesjo mein sourceMap ist auf false . Ich habe es mit sourceMap versucht, das auf true und es wird immer noch erstellt

@ gak10100 und benutzt du scss / sass?

Ich denke, der erhöhte Speicherbedarf könnte dann mit der Sass-Verarbeitung zusammenhängen. Wir sind in 8 von node-sass auf sass umgezogen.

Können Sie den Anweisungen in @angular-devkit/build-angular: use sass instead of node-sass (ce15899) folgen, um stattdessen die Verwendung von node-sass zu erzwingen?

@johannesjo Ja

Sie können auch versuchen, Knoten 12 zu verwenden, da dies den Speicher automatisch vergrößern sollte. Wenn genügend Speicher vorhanden ist, sollten Builds erfolgreich sein.

Nur zu Ihrer Information, ich bin auf Knoten v12.3.1

@ gak10100 danke.

Ich habe alle Kombinationen der folgenden ausprobiert:
Knoten: 10.15.3 / 12.3.1
Winkel: 7,4, 8,0
os: win10 / ubuntu18.04

Alle führen zum gleichen Fehler.

Ich habe einen ziemlich leistungsstarken Gaming-Laptop, daher sollten Speicher und CPU-Leistung normalerweise kein Problem darstellen.
Der Code des Projekts ist Open Source und kann hier eingesehen werden: https://github.com/johannesjo/super-productivity

Durch das Upgrade von Knoten 10 auf Knoten 12 wurde mein Problem beim Kompilieren des Speichers bei Verwendung von Angular 8 behoben.

Wenn ich jedoch versuche, den kompilierten Code von ng build --prod auszuführen, wird nur ein leerer Bildschirm angezeigt: / Funktioniert jedoch gut mit ng serve

@johannesjo Ich bin sehr, sehr dankbar für den Repro! Es ist so schwer, Repros für diese Probleme zu finden.

@filipesilva Ich habe hier viele Dinge ausprobiert (ich habe eine ganze Weile

Mit --max_old_space_size:
ES2015 AOT ON => Fehler mit OOM für schwerwiegende Prozesse in nicht genügend Speicher, um ein Isolat zu erstellen
ES2015 AOT OFF => Erfolg
ES5 AOT ON => Fehler mit OOM für schwerwiegende Prozesse in nicht genügend Speicher, um ein Isolat zu erstellen

Ohne --max_old_space_size
ES2015 AOT ON => fehlgeschlagen mit ineffektiven Mark-Compacts nahe der Heap-Grenze. Zuordnung fehlgeschlagen
ES2015 AOT OFF => Erfolg
ES5 AOT ON => fehlgeschlagen mit ineffektiven Mark-Compacts nahe der Heap-Grenze. Zuordnung fehlgeschlagen
ES5 AOT OFF => Erfolg

Bei dieser Browserliste bin ich mir nicht sicher, woher sie stammt. Ich habe eine große Anwendung aktualisiert, sodass ein Update oder etwas über den Schaltplan nicht ordnungsgemäß funktioniert hat. Daher habe ich alles manuell aktualisiert.
Ich habe versucht, es in den Stammordner zu legen. Es ändert nichts.

Wie bereits erwähnt, verfügt Azure nicht über Knoten 12. Aber nur über Knoten 10. Ich möchte erneut wiederholen, dies ist auf Azure, einem S3-Computer.

Ich habe die Flagge --aot noch nie benutzt. Ich benutze das Flag --prod. Ich habe angular.json verwendet, wobei "aot" und "buildOptimizer" auf "true" gesetzt waren. Ich habe meine App von Angular 6.0.4 auf 8.0.0 verschoben.

@johannesjo Ich habe dein Repo ausprobiert, hier sind meine Ergebnisse.

Zuerst habe ich manuell auf CLI und Build-Angular aktualisiert. Das Update finden Sie unter https://github.com/filipesilva/super-productivity/tree/benchmark-8.

Das sehe ich für ng version :

kamik@RED-X1C6 MINGW64 /d/sandbox/oom/v8 (benchmark-8)
$ ng version

     _                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/


Angular CLI: 8.0.1
Node: 10.10.0
OS: win32 x64
Angular: 8.0.0-rc.4
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... platform-server, router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.800.1
@angular-devkit/build-angular     0.800.1
@angular-devkit/build-optimizer   0.800.1
@angular-devkit/build-webpack     0.800.1
@angular-devkit/core              8.0.1
@angular-devkit/schematics        8.0.1
@angular/cdk                      8.0.0-rc.0
@angular/cli                      8.0.1
@angular/http                     7.2.14
@angular/material                 8.0.0-rc.1
@angular/pwa                      0.10.7
@angular/service-worker           7.2.14
@ngtools/webpack                  8.0.1
@schematics/angular               7.0.7
@schematics/update                0.800.1
rxjs                              6.5.1
typescript                        3.4.5
webpack                           4.30.0

Dann habe ich ein benutzerdefiniertes Benchmark-Tool ausgeführt, das wir in diesem Repository haben, um die Ressourcennutzung für Befehle zu messen.

kamik@RED-X1C6 MINGW64 /d/sandbox/oom/v8 (benchmark-8)
$ ../../../work/cli/bin/benchmark -- ng build --prod
[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   ng build --prod (at D:\sandbox\oom\v8)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 155162.80 ms (157246.00, 143200.00, 165534.00, 155899.00, 153935.00)
[benchmark]   Average Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 17.40 % (16.74, 17.06, 18.40, 17.31, 17.52)
[benchmark]   Peak CPU usage: 190.04 % (165.60, 236.10, 189.10, 187.50, 171.90)
[benchmark]   Average Memory usage: 930.58 MB (928.38, 935.07, 917.83, 950.89, 920.71)
[benchmark]   Peak Memory usage: 1640.18 MB (1583.62, 1619.55, 1624.59, 1669.88, 1703.28)

Ich sehe also, dass die maximale Speichernutzung nur unter dem Standardlimit von 1,7 g liegt. Ich verstehe nicht ganz, wie Sie das Speicherlimit Ihrer Maschine erreichen. Gibt es noch etwas in Ihrer Umgebung, an das Sie denken können? Vielleicht irgendwo Symlinks.

@jsgoupil Ich bin nicht in Azure, aber ich habe meine Tests auf einem Windows-Computer durchgeführt. Es wird erwartet, dass AOT mehr Speicher benötigt, hauptsächlich weil es ein komplexerer Build ist. Dort passiert mehr.

Aber ich finde Ihre Ergebnisse interessant. Sie sagen, dass without --max_old_space_size + AOT off die Builds erfolgreich sind. Sie sind also mit weniger als 1,7 g Speicher erfolgreich (die Standardeinstellung für den Moment). Aber Sie sagen, dass with --max_old_space_size=8192 + AOT on immer fehlschlägt.

Der AOT-Build benötigt also mindestens 5x mehr Speicher. Was ich nicht für sehr vernünftig halte. Ich meine bis zu 2x, was ich mir für ein wahnsinnig komplexes TS-Setup vorstellen könnte, aber 5x ist einfach zu viel. Ich denke, es ist wahrscheinlicher, dass im Compiler ein Speicherverlust vorliegt oder etwas Dummes vor sich geht.

Hast du ein Repo, das wir uns ansehen könnten? Auch wenn nur privat geteilt.

Hallo @filipesilva , danke, dass bist , dies zu untersuchen. Ich kann mein Repo teilen, es ist in der Tat privat und auf Bitbucket. Ich kann AOT auf meinem Windows-Computer mit Knoten 12 erstellen. Es dauert eine Weile, aber es funktioniert. Ich bin es nicht gewohnt, Benchmarks zu erstellen und all das zu überprüfen.
Können Sie auf mein Profil gehen und mir eine kurze E-Mail senden, ich kann Sie einrichten.

@filipesilva danke, dass hast .

Ich bin mir nicht sicher, ob ich dich richtig verstehe.

Erstens: Nehme ich richtig an, dass der Build auf Ihrem Computer einwandfrei läuft? Oder ist es nur so, dass es technisch nicht nach dem Benchmark scheitern sollte?

Zweitens: Meinen Sie ein Repository einer anderen eckigen App? Vielleicht sind auch die Travis Build-Protokolle hilfreich? Wenn ich mich nicht irre, sollten sie trotzdem öffentlich sein:
https://travis-ci.org/johannesjo/super-productivity/builds/539736050
Die Ergebnisse scheinen die gleichen zu sein, obwohl der Mac-Build wieder seine süße Zeit in Anspruch nimmt :)

Bitte lassen Sie mich wissen, ob ich Ihnen noch weiterhelfen kann.

Ich denke, der erhöhte Speicherbedarf könnte dann mit der Sass-Verarbeitung zusammenhängen. Wir sind in 8 von node-sass auf sass umgezogen.

Können Sie den Anweisungen in @angular-devkit/build-angular: use sass instead of node-sass (ce15899) folgen, um stattdessen die Verwendung von node-sass zu erzwingen?

Ich habe Node-Sass als Entwicklungsabhängigkeit installiert, aber immer noch einen wahnsinnig hohen Speicherverbrauch festgestellt. Unsere Builds verwenden mehr als 12 GB.

Ich bin mir nicht sicher, ob dies helfen wird, aber hier ist ein Diagramm unseres Speicherverbrauchs.

Die erste Spitze ist ein Standard-Build mit differenzieller Belastung. Die zweite Spitze ist die differentielle Belastung mit Node-Sass.

Die letzte Spitze ist ein Build mit ausgeschalteter Differenzlast.

Beide Builds mit differenziellem Laden sind fehlgeschlagen, nachdem sie das Speicherlimit des Servers erreicht haben. Der letzte Build war erfolgreich.

Wir haben ungefähr 20 verschiedene Projekte in unserer angle.json definiert. Normalerweise schlägt dies beim Erstellen des zweiten oder dritten Projekts fehl.

Im Folgenden finden Sie zwei weitere Probleme im Zusammenhang mit der Verlangsamung in Version 8. Im Folgenden finden Sie Protokolle und eine Reproduktion.

https://github.com/angular/angular-cli/issues/14666#issue -452183942
https://github.com/angular/angular-cli/issues/14604#issuecomment -498425823

@ Troyd-Destin hier wie du, hast du dein Problem gelöst?

Hallo zusammen,

Ich möchte Ihnen nur ein Update zu diesem Thema geben. Ich habe nachgesehen, ob ich etwas finden kann. Nachfolgend sind meine bisherigen Ergebnisse aufgeführt.

Debuggen der Speichersituation in CLI 8

Umgebung:

kamik@RED-X1C6 MINGW64 /d/sandbox/memory-debug
$ ng version

Angular CLI: 8.0.1
Node: 12.3.1
OS: win32 x64
Angular:
...

Package                      Version
------------------------------------------------------
@angular-devkit/architect    0.800.1
@angular-devkit/core         8.0.1
@angular-devkit/schematics   8.0.1
@schematics/angular          8.0.1
@schematics/update           0.800.1
rxjs                         6.4.0

kamik@RED-X1C6 MINGW64 /d/sandbox/memory-debug
$ npm -v
6.9.0

kamik@RED-X1C6 MINGW64 /d/sandbox/memory-debug
$ yarn -v
1.12.3

Messung der Speichernutzung

Wir haben ein privates Benchmarking-Paket für die CLI https://github.com/angular/angular-cli/tree/master/packages/angular_devkit/benchmark.

Um es zu installieren, klonen Sie das CLI-Repo und führen Sie die folgenden Befehle aus:

yarn
yarn build
npm pack dist/@angular-devkit/benchmark
npm install -g angular-devkit-benchmark-0.800.0-beta.18.tgz

Der Dateiname des letzten Befehls kann sich abhängig von der Version der CLI ändern, die Sie klonen.

Führen Sie dazu benchmark -- command . Der Befehl hängt von dem verwendeten Projekt ab. Führen Sie benchmark -- ng build --prod , um einen Produktaufbau zu bewerten.

Sie können auch benchmark --iterations 20 -- ng build --prod , um eine größere Stichprobe zu erhalten (20 statt 5).

Methodik

Ich habe eine Reihe von Projekten in verschiedenen Größen zusammengestellt und jeweils einen Ordner für Version 7 und Version 8 eingerichtet.

Um die verschiedenen Versionen zu erhalten, aktualisiere ich zuerst ein Projekt auf Version 8 unter https://update.angular.io/. Das ist die v8-Variante.

Dann mache ich die v7-Variante durch Ersetzen:

• @angular-devkit/build-angular Version von ~0.800.0 bis 0.13.8
• @angular/cli Version von ~8.0.1 bis 7.3.9
• target in ./tsconfig.json von es2015 bis es5 .

Um zwischen Knotenversionen zu wechseln, habe ich NVM verwendet. Um das Differential Loading (DL) zu deaktivieren, habe ich target in ./tsconfig.json von es2015 in es5 geändert.

Bei jedem mache ich benchmark -- ng build --prod und vergleiche dann die Ergebnisse.

Benchmark-Matrix:

• v8, DL, Knoten 10.10.0
• v8, DL, Knoten 12.3.1
• v8, kein DL, Knoten 10.10.0
• v8, kein DL, Knoten 12.3.1
• v7, Knoten 10.10.0
• v7, Knoten 12.3.1

Ergebnisse

neues Projekt

Von ng new new-project

Generiert mit Angular CLI 8.0.1

• v8, DL, Knoten 10.10.0

[benchmark] Benchmarking process over 20 iterations, with up to 5 retries.
[benchmark]   ng build --prod (at D:\sandbox\memory-debug\new-project\v8)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 46922.00 ms (39800.00, 45773.00, 45097.00, 45295.00, 46447.00, 47061.00, 49343.00, 48787.00, 58921.00, 50950.00, 45493.00, 45809.00, 47836.00, 45142.00, 45632.00, 45060.00, 45956.00, 45688.00, 45292.00, 49058.00)
[benchmark]   Average Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 14.31 % (10.82, 12.30, 14.18, 13.79, 13.90, 13.75, 16.09, 15.20, 17.63, 16.20, 14.68, 14.51, 15.48, 14.43, 13.26, 14.56, 13.38, 13.03, 12.87, 16.10)
[benchmark]   Peak CPU usage: 109.84 % (92.30, 89.10, 137.60, 126.60, 103.10, 92.20, 128.20, 103.00, 142.20, 114.00, 90.60, 104.60, 107.80, 96.90, 93.70, 128.20, 123.40, 95.30, 92.20, 135.90)        
[benchmark]   Average Memory usage: 412.94 MB (410.61, 414.42, 412.02, 414.26, 414.95, 413.02, 411.16, 408.59, 408.12, 411.88, 417.27, 416.50, 410.62, 413.21, 416.36, 411.94, 411.58, 414.87, 412.33, 
415.01)
[benchmark]   Peak Memory usage: 972.38 MB (940.09, 1007.36, 939.21, 1014.48, 1012.67, 953.59, 934.79, 944.62, 860.78, 1008.56, 1019.51, 1005.97, 902.56, 1008.87, 999.36, 1005.65, 973.90, 1012.61, 974.84, 928.23)

• v8, DL, Knoten 12.3.1

[benchmark] Benchmarking process over 20 iterations, with up to 5 retries.
[benchmark]   ng build --prod (at D:\sandbox\memory-debug\new-project\v8)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 43714.45 ms (42475.00, 42905.00, 42806.00, 45229.00, 44435.00, 42946.00, 43730.00, 44409.00, 43320.00, 43331.00, 45213.00, 46699.00, 44467.00, 42552.00, 42833.00, 42773.00, 42621.00, 45640.00, 43103.00, 42802.00)
[benchmark]   Average Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 15.08 % (13.71, 15.04, 14.23, 15.94, 15.58, 14.19, 14.84, 15.49, 15.26, 14.15, 15.76, 15.63, 16.43, 14.73, 15.51, 15.28, 15.06, 16.25, 14.92, 13.62)
[benchmark]   Peak CPU usage: 114.45 % (103.10, 153.10, 114.10, 98.50, 122.00, 98.40, 121.90, 109.40, 126.60, 109.40, 87.40, 109.30, 112.50, 114.00, 142.10, 120.30, 104.60, 150.00, 109.40, 82.80)    
[benchmark]   Average Memory usage: 443.99 MB (399.76, 469.47, 461.83, 416.02, 425.19, 433.08, 395.28, 459.70, 462.49, 419.98, 462.35, 476.16, 459.91, 463.51, 461.39, 423.32, 461.10, 424.20, 465.06, 
439.96)
[benchmark]   Peak Memory usage: 1041.65 MB (1056.51, 1166.15, 1030.32, 975.46, 1107.44, 920.04, 1028.92, 1062.10, 1067.24, 1075.11, 1040.00, 1087.46, 1005.02, 1073.69, 1040.01, 1034.72, 1059.59, 1003.81, 1081.23, 918.20)

• v8, kein DL, Knoten 10.10.0

[benchmark] Benchmarking process over 20 iterations, with up to 5 retries.
[benchmark]   ng build --prod (at D:\sandbox\memory-debug\new-project\v8)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 39715.85 ms (41254.00, 38917.00, 38954.00, 39452.00, 39908.00, 39124.00, 41544.00, 39056.00, 39008.00, 38737.00, 39794.00, 41248.00, 41226.00, 42391.00, 38638.00, 41751.00, 36910.00, 41124.00, 39960.00, 35321.00)
[benchmark]   Average Process usage: 1.02 process(es) (1.37, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.15 process(es) (4.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 19.27 % (20.15, 18.37, 17.48, 19.86, 20.59, 19.83, 20.60, 19.03, 18.46, 18.66, 19.95, 18.84, 20.64, 21.30, 18.69, 20.99, 17.54, 19.45, 18.83, 16.05)
[benchmark]   Peak CPU usage: 118.53 % (170.40, 120.30, 89.00, 109.40, 140.70, 120.30, 132.90, 98.40, 107.80, 86.00, 93.70, 101.50, 132.80, 128.20, 112.60, 154.70, 90.60, 145.40, 134.40, 101.60)     
[benchmark]   Average Memory usage: 313.02 MB (360.81, 308.63, 312.78, 311.23, 310.24, 310.67, 312.26, 309.85, 310.46, 313.62, 310.08, 313.48, 308.39, 306.88, 309.72, 311.82, 311.05, 309.78, 310.82, 
307.85)
[benchmark]   Peak Memory usage: 800.08 MB (774.48, 774.38, 763.67, 807.96, 786.14, 815.06, 835.76, 762.01, 767.66, 861.41, 825.32, 855.64, 794.63, 767.91, 798.90, 805.75, 824.83, 823.76, 791.04, 765.35)

• v8, kein DL, Knoten 12.3.1

[benchmark] Benchmarking process over 20 iterations, with up to 5 retries.
[benchmark]   ng build --prod (at D:\sandbox\memory-debug\new-project\v8)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 29947.20 ms (28681.00, 30854.00, 28829.00, 28346.00, 28471.00, 29073.00, 28534.00, 28585.00, 27104.00, 27578.00, 27421.00, 28399.00, 29042.00, 27301.00, 27480.00, 33175.00, 37174.00, 34747.00, 34038.00, 34112.00)
[benchmark]   Average Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 15.59 % (14.65, 17.22, 15.86, 14.82, 15.21, 15.75, 15.03, 15.15, 12.67, 14.51, 13.17, 14.72, 14.46, 12.78, 13.69, 17.00, 19.96, 18.69, 17.80, 18.63)
[benchmark]   Peak CPU usage: 97.90 % (90.70, 106.20, 90.70, 90.70, 117.30, 89.00, 96.80, 103.10, 92.20, 75.00, 92.20, 93.80, 96.90, 92.20, 81.20, 134.40, 98.40, 106.20, 95.30, 115.60)
[benchmark]   Average Memory usage: 303.56 MB (294.81, 314.64, 298.23, 310.19, 303.41, 295.35, 293.39, 294.60, 310.87, 311.56, 316.21, 296.54, 305.72, 315.03, 315.93, 313.65, 311.67, 291.89, 283.43, 
294.12)
[benchmark]   Peak Memory usage: 847.21 MB (822.65, 948.96, 819.03, 852.73, 859.57, 764.29, 749.08, 811.35, 887.66, 905.15, 938.75, 799.78, 878.00, 912.18, 929.51, 819.72, 897.77, 769.11, 734.79, 844.19)

• v7, Knoten 10.10.0

[benchmark] Benchmarking process over 20 iterations, with up to 5 retries.
[benchmark]   ng build --prod (at D:\sandbox\memory-debug\new-project\v7)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 34065.15 ms (48589.00, 30736.00, 29772.00, 32748.00, 35670.00, 37796.00, 35251.00, 32773.00, 33065.00, 32493.00, 32957.00, 32942.00, 33630.00, 34067.00, 33241.00, 32454.00, 32997.00, 33366.00, 32509.00, 34247.00)
[benchmark]   Average Process usage: 1.06 process(es) (2.20, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.20 process(es) (5.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 15.93 % (17.74, 15.14, 14.45, 15.67, 16.94, 18.67, 17.13, 14.81, 15.50, 15.68, 15.22, 15.17, 17.00, 15.39, 15.49, 15.34, 15.15, 15.99, 15.94, 16.11)
[benchmark]   Peak CPU usage: 99.83 % (170.30, 98.50, 79.60, 117.20, 117.20, 96.90, 90.70, 82.70, 118.80, 106.20, 79.70, 82.90, 107.80, 93.70, 87.50, 84.30, 84.30, 89.00, 117.20, 92.10)
[benchmark]   Average Memory usage: 307.49 MB (455.09, 299.47, 299.79, 305.62, 300.43, 298.91, 298.40, 301.08, 300.22, 299.42, 298.72, 299.10, 299.30, 301.11, 299.16, 298.94, 300.26, 297.80, 298.66, 
298.40)
[benchmark]   Peak Memory usage: 805.72 MB (847.09, 820.75, 771.20, 851.10, 817.67, 831.61, 782.52, 815.22, 832.90, 798.27, 786.08, 753.38, 779.23, 821.07, 804.25, 824.09, 852.30, 765.94, 754.26, 805.57)

• v7, Knoten 12.3.1

[benchmark] Benchmarking process over 20 iterations, with up to 5 retries.
[benchmark]   ng build --prod (at D:\sandbox\memory-debug\new-project\v7)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 33382.50 ms (33115.00, 33274.00, 31484.00, 30663.00, 30814.00, 30642.00, 31120.00, 31219.00, 33208.00, 39141.00, 36040.00, 36106.00, 35269.00, 34795.00, 33526.00, 33014.00, 34918.00, 33872.00, 32882.00, 32548.00)
[benchmark]   Average Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 17.92 % (17.56, 17.77, 16.47, 16.61, 15.86, 16.67, 16.90, 15.90, 18.98, 23.05, 18.36, 19.39, 20.03, 18.58, 17.52, 16.43, 19.60, 17.50, 17.58, 17.72)
[benchmark]   Peak CPU usage: 98.91 % (106.30, 99.90, 90.60, 98.40, 86.00, 87.50, 104.70, 93.70, 115.60, 128.10, 117.20, 103.10, 95.40, 85.90, 96.90, 81.30, 100.00, 85.90, 89.10, 112.60)
[benchmark]   Average Memory usage: 292.19 MB (293.59, 295.74, 293.63, 290.62, 293.48, 291.67, 292.69, 293.37, 293.36, 293.54, 293.94, 292.08, 291.17, 291.83, 292.20, 291.82, 283.89, 292.66, 291.06, 
291.52)
[benchmark]   Peak Memory usage: 846.53 MB (828.64, 886.21, 835.02, 820.26, 837.29, 883.92, 873.06, 882.54, 825.58, 889.52, 880.10, 831.73, 827.94, 868.43, 820.85, 871.18, 763.72, 800.90, 900.42, 803.35)

Superproduktivität

Von https://github.com/aviabird/angularspree

Bereitgestellt von @johannesjo unter https://github.com/angular/angular-cli/issues/13734#issuecomment-497393904

• v8, DL, Knoten 10.10.0

[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   ng build --prod (at D:\sandbox\memory-debug\super-productivity\v8)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 269523.80 ms (257464.00, 255811.00, 285836.00, 279557.00, 268951.00)
[benchmark]   Average Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 13.37 % (12.17, 12.49, 13.95, 15.03, 13.22)
[benchmark]   Peak CPU usage: 193.76 % (175.00, 179.80, 207.80, 223.40, 182.80)
[benchmark]   Average Memory usage: 1139.50 MB (1125.28, 1128.75, 1165.98, 1146.50, 1131.01)
[benchmark]   Peak Memory usage: 1753.78 MB (1712.68, 1726.49, 1809.78, 1796.38, 1723.58)

• v8, DL, Knoten 12.3.1

[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   ng build --prod (at D:\sandbox\memory-debug\super-productivity\v8)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 302133.40 ms (379732.00, 271669.00, 295372.00, 289442.00, 274452.00)
[benchmark]   Average Process usage: 1.19 process(es) (1.97, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.80 process(es) (5.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 12.91 % (13.05, 12.47, 13.46, 13.09, 12.45)
[benchmark]   Peak CPU usage: 199.36 % (217.20, 198.50, 203.00, 178.10, 200.00)
[benchmark]   Average Memory usage: 1506.77 MB (1742.04, 1453.37, 1455.98, 1438.85, 1443.59)
[benchmark]   Peak Memory usage: 2335.48 MB (3000.09, 2137.67, 2118.84, 2190.41, 2230.37)

• v8, kein DL, Knoten 10.10.0

$ benchmark -- ng build --prod
[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   ng build --prod (at D:\sandbox\memory-debug\super-productivity\v8)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 137125.80 ms (134088.00, 140877.00, 137668.00, 139447.00, 133549.00)
[benchmark]   Average Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 10.91 % (10.27, 11.17, 11.13, 11.15, 10.82)
[benchmark]   Peak CPU usage: 155.30 % (143.80, 154.70, 164.00, 153.10, 160.90)
[benchmark]   Average Memory usage: 944.34 MB (948.63, 948.80, 960.01, 950.97, 913.27)
[benchmark]   Peak Memory usage: 1664.48 MB (1723.53, 1670.94, 1670.71, 1684.96, 1572.24)

• v8, kein DL, Knoten 12.3.1

[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   ng build --prod (at D:\sandbox\memory-debug\super-productivity\v8)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 138378.80 ms (136618.00, 140146.00, 136281.00, 139331.00, 139518.00)
[benchmark]   Average Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 10.63 % (10.72, 10.78, 10.38, 10.12, 11.17)
[benchmark]   Peak CPU usage: 154.38 % (162.50, 148.40, 167.20, 145.30, 148.50)
[benchmark]   Average Memory usage: 1173.09 MB (1182.91, 1179.12, 1162.80, 1162.17, 1178.46)
[benchmark]   Peak Memory usage: 2064.48 MB (2104.92, 2113.08, 2071.26, 2007.69, 2025.45)

• v7, Knoten 10.10.0

$ benchmark -- ng build --prod
[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   ng build --prod (at D:\sandbox\memory-debug\super-productivity\v7)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 126331.00 ms (115769.00, 114542.00, 127353.00, 144113.00, 129878.00)
[benchmark]   Average Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 12.75 % (11.16, 10.43, 12.28, 15.91, 13.96)
[benchmark]   Peak CPU usage: 160.92 % (175.00, 139.10, 140.60, 185.90, 164.00)
[benchmark]   Average Memory usage: 850.62 MB (851.26, 851.57, 859.25, 837.64, 853.40)
[benchmark]   Peak Memory usage: 1456.63 MB (1458.19, 1463.49, 1470.42, 1447.42, 1443.61)

• v7, Knoten 12.3.1

[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   ng build --prod (at D:\sandbox\memory-debug\super-productivity\v7)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 128415.80 ms (121753.00, 121720.00, 124237.00, 143535.00, 130834.00)
[benchmark]   Average Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 12.02 % (11.37, 11.24, 12.02, 13.66, 11.79)
[benchmark]   Peak CPU usage: 155.96 % (160.90, 175.10, 176.60, 186.00, 81.20)
[benchmark]   Average Memory usage: 1126.36 MB (1138.10, 1105.06, 1135.59, 1126.35, 1126.68)
[benchmark]   Peak Memory usage: 1892.42 MB (1864.26, 1773.99, 2055.74, 1777.96, 1990.18)

Meine Schlussfolgerungen zu diesem Punkt sind:

• Ich sehe eine erhöhte Speichernutzung nur durch die Verwendung von Knoten 12:
  
  
  
  • Die Superproduktivität zeigte einen Spitzenwert von 1753 MB bei v8, DL, Node 10.10.0 gegenüber 2335 MB v8, DL, Node 12.3.1
  
  
• Ich sehe ungefähr 15% zusätzliche Speichernutzung zwischen v7 und v8 für den gleichen Fall (nicht DL):
  
  
  
  • Die Superproduktivität zeigte einen Spitzenwert von 1664 MB bei v8, no DL, Node 10.10.0 gegenüber 1456 MB v7, Node 10.10.0
  
  
  • Die Superproduktivität zeigte einen Spitzenwert von 2064 MB bei v8, no DL, Node 12.3.1 gegenüber 1892 MB v7, Node 12.3.1
  
  
• Unter Windows beträgt die maximale Prozessauslastung immer 1. Unser Minifier-Plugin (Terser) ist das einzige, das zusätzliche Prozesse verwendet. Ich denke, es wird nicht unter Windows verwendet, ich weiß nicht warum. Vielleicht werde ich es später untersuchen. Aber es ist nicht besonders relevant für die Speichernutzung, da durch das Parallelisieren von etwas immer mehr Speicher benötigt wird, auch wenn es nicht viel ist. Könnte aber verwandt sein.

Ich habe einige weitere Beispiel-Repositorys zusammengestellt, aber nachdem ich all diese Benchmarks manuell durchgeführt habe, denke ich, dass ich dies automatisieren muss. Ich hätte es wirklich von Anfang an automatisieren sollen. Also werde ich ein Repository einrichten, das dies mit CI erledigt.

Nun, tatsächlich haben wir ein Projekt, in dem das Setzen von max_old_space_size=8192 funktioniert hat, aber mit max_old_space_size=4096 fehlgeschlagen ist, aber mit 8192 die Speichernutzung einen Höchstwert von etwa 4-6 g. Wir haben max_old_space_size=2048 mit eckigem v7.x verwendet.

Ich bin mir ziemlich sicher, dass es ein Leck gibt. Vielleicht passiert es nur mit build-optimizer ?

Keine Neuigkeiten? Problemumgehungen? Braucht ihr mehr Benchmarks?

Dies ist auch ein Problem, mit dem wir derzeit mit https://github.com/vmware/clarity in der Hauptniederlassung konfrontiert sind. Wir können unsere Website nicht erstellen und bereitstellen, da uns der Arbeitsspeicher und andere SSR-Probleme ausgehen. Um Speicherprobleme anzuzeigen, führen Sie npm run website:prerender , um den Website-Build auszulösen.

Heya, ich habe Ergebnisse und Methoden in https://github.com/filipesilva/angular-cli-perf-benchmark veröffentlicht. Wird dort nächste Woche weitere Projekte hinzufügen.

Das einzige zusätzliche Detail, das ich habe, ist, dass sich die Build-Zeiten im awesome-angular-workshop -Projekt von CLI 7 auf 8 fast verdoppelt haben. Bei den anderen von mir getesteten Projekten war dies jedoch nicht der Fall.

Wenn jemand die dortige Methodik mithilfe der Skripte befolgen möchte, sollte dies einfach genug sein. Wenn Sie etwas Interessantes finden, lassen Sie es mich wissen. Wenn Sie ein großes Projekt haben, von dem Sie glauben, dass es interessante Benchmarks liefern könnte, lassen Sie es mich wissen (oder fügen Sie eine PR hinzu), und ich werde es dort hinzufügen.

das gleiche Problem hier auf
Darwin Miguels-MacBook-Pro.local 17.7.0 Darwin Kernel Version 17.7.0: Do 20. Dezember 21:47:19 PST 2018; root: xnu-4570.71.22 ~ 1 / RELEASE_X86_64 x86_64

eckige cli 5.2.11

Build Problem gelöst. Vorschlag ist, die Build-Logik zu ändern. Verwenden Sie anstelle von eckigen ng build node build

@ arayik-yervandyan Ich möchte dies offen halten, da dieses Problem mehr beinhaltet als nur die Erhöhung des Speicherlimits. Einige Projekte weisen einen überproportionalen Anstieg der Speichernutzung auf, und wir scheinen auch Speicher zu haben, der bei Builds mit unterschiedlichem Laden nicht freigegeben wird.

@filipesilva sicher kein Problem. Nur zur Information kann ich sagen, dass wir in unserer Version das Speicherlimit auf 4096 oder 8192 erhöht haben. Ich erinnere mich nicht richtig, aber das Problem besteht immer noch. Wenn der Build von ng build in node build geändert wurde, wurde der Build-Prozess erfolgreich bestanden.

Was genau meinst du, wenn du node build sagst?

Ich denke, er meinte etwas in der Zeile von node --max_old_space_size=4096 ./node_modules/@angular/cli/bin/ng build --prod , also würde das Argument an die Knotenumgebung übergeben. Aber es gibt noch andere Probleme, die damit verbunden sind, wie die enorme Zeit und der Speicher, die beim Kompilieren aufgewendet werden.

Ich stimme @ hugo-marello zu, mein Anwendungsfall ist in der Tat dieser. Während eines einfachen ng serve + Args gingen jedes Mal, wenn versucht wurde, neu zu kompilieren, Speicherfehler aus. Die CPU war zu 100% verrückt nach mir. Ich habe die Problemumgehung versucht, indem ich node --max_old_space_size=4096 ./node_modules/@angular/cli/bin/ng + Argumente gesetzt habe, und es hat gut für mich funktioniert.

Ich sehe zwar größere Zeiten, um neu zu kompilieren, aber es stürzt nicht mehr ab. Ich habe das Gefühl, dass noch etwas nicht stimmt, wenn ich zum Winkel 8 (+ cli) gehe. Ich benutze übrigens schon Knoten 12.

Ich habe das Benchmarking der Projekte abgeschlossen, die ich unter https://github.com/filipesilva/angular-cli-perf-benchmark hatte.

Beachten Sie beim Betrachten dieser Ergebnisse Folgendes:

Es ist wichtig zu beachten, dass der erste Build der Varianten CLI version 8 with differential loading und CLI version 7 immer mehr Kerne verwendet und mehr Speicher benötigt.
Dies liegt daran, dass terser-webpack-plugin sowohl parallele Prozesse als auch einen Cache verwendet, der bei der Neuinstallation der Knotenmodule gelöscht wird. Cache-Treffer erzeugen keine zusätzlichen Prozesse und führen keine Arbeit aus.

Dies ist etwas unglücklich und erschwert das Lesen der Ergebnisse. Wenn ich dies in Zukunft wiederhole, werde ich versuchen, einen Weg zu finden, den Terser-Cache immer zu sprengen / zu ignorieren. In den folgenden Ergebnissen betrachte ich hauptsächlich die Zahlen mit Cache, füge aber auch einen einzelnen Vergleich ohne Cache hinzu.

Unten sind die Ergebnisse. Ausreißer sind fett gedruckt. N10 und N12 bedeuten Knoten 10.16.0 bzw. Knoten 12.4.0. CLI7, CLI8 und CLI8DL bedeuten Angular CLI Version 7, Version 8 und Version 8 mit differenzieller Belastung.

Ergebnisse

Cli-Acht-Projekt

In N12 erhöht der Wechsel von CLI7 zu CLI8 die Speichernutzung um ~ 20 MB (5%) und den Spitzenspeicher um ~ 60 MB (7%).

CLI8DL erweitert den Speicher und den Spitzenspeicher um ~ 190 MB und erhöht die Erstellungszeit um 60%.

N10 zeigt ähnliche Zahlen.

N12 scheint etwa 6% zusätzlichen Speicher gegenüber N10 zu verbrauchen.

Builds ohne Cache in N12 reichen von 1063 MB Spitzen-Speicherauslastung in CLI 7 bis 1191 MB in CLI8DL.

Superproduktivität

In N12 erhöht der Wechsel von CLI7 zu CLI8 die Speichernutzung um ~ 60 MB (5%), der maximale Speicher bleibt jedoch gleich.

CLI8DL erweitert den Speicher und den Spitzenspeicher um ca. 200 MB und erhöht die Erstellungszeit um 90%.

N10 zeigt ähnliche Zahlen.

N12 scheint etwa 30% zusätzlichen Speicher gegenüber N10 zu verbrauchen.

Builds ohne Cache in N12 reichen von 2886 MB Spitzen-Speicherauslastung in CLI 7 bis 3131 MB in CLI8DL.

Awesome-Angular-Workshop

In N12 erhöht der Wechsel von CLI7 zu CLI8 die Speichernutzung um ~ 410

CLI8DL erweitert den Speicher und den Spitzenspeicher um ca. 200 MB und erhöht die Erstellungszeit um 150% .

N10 zeigt ähnliche Zahlen.

N12 scheint etwa 25% zusätzlichen Speicher gegenüber N10 zu verbrauchen.

Builds ohne Cache in N12 reichen von 2515 MB Spitzen-Speicherauslastung in CLI 7 bis 2554 MB in CLI8DL.

angle.io

In N12 erhöht der Wechsel von CLI7 zu CLI8 die Speichernutzung um ~ 50 MB (6%) und den Spitzenspeicher um ~ 350 MB (25%).

CLI8DL fügt dem Speicher ~ 270 MB, dem Spitzenspeicher 100 MB und eine zusätzliche Erstellungszeit von 90% hinzu.

N10 zeigt ähnliche Zahlen.

N12 scheint etwa 17% zusätzlichen Speicher gegenüber N10 zu verbrauchen.

Builds ohne Cache in N12 reichen von 2898 MB Spitzen-Speicherauslastung in CLI 7 bis 2243 MB in CLI8DL.

Spartacus

In N12 erhöht der Wechsel von CLI7 zu CLI8 die Speichernutzung um ~ 290 MB (32%) und den Spitzenspeicher um ~ 420 MB (25%).

N10 zeigt 40% zusätzliche Speichernutzung und Spitzenspeicher .

N12 scheint etwa 27% zusätzlichen Speicher gegenüber N10 zu verbrauchen.

Builds ohne Cache in N12 reichen von 2011 MB Spitzen-Speicherauslastung in CLI 7 bis 2326 MB in CLI8.

Klarheit

In N12 erhöht der Wechsel von CLI7 zu CLI8 die Speichernutzung um ~ 50 MB (2%), der maximale Speicher bleibt jedoch gleich.

N10 zeigt ähnliche Zahlen.

N12 scheint etwa 70% zusätzlichen Speicher gegenüber N10 zu verbrauchen.

Builds ohne Cache in N12 reichen von einer maximalen Speichernutzung von 6000 MB in CLI 7 bis zu 5000 MB in CLI8.

Schlussfolgerungen

Der erste Build dauert immer länger und benötigt mehr Speicher, da einige Build-Ergebnisse zwischengespeichert werden. In realistischen Szenarien machen die meisten Builds einen Teil des Caches ungültig und dauern auch länger.

Die Verwendung des differenziellen Ladens scheint die Speichernutzung um ~ 200 MB zu erhöhen. Dieser Wert ändert sich nicht wesentlich, was darauf hindeutet, dass etwas, das nicht stark von der Projektgröße abhängt, zwischen den Builds im Speicher verbleibt.

Knoten 12 verwendet zwischen 6% und 70% zusätzlichen Speicher als Knoten 10. Die meisten getesteten Projekte zeigten einen Anstieg von ~ 30%.

awesome-angular-workshop leidet unter einem überproportionalen Anstieg der Speichernutzung (45%) und der Erstellungszeit (150%) von CLI7 auf CLI8DL. Dies weist auf eine lokalisierte Regression hin.

spartacus zeigt einen höheren Unterschied in der Speichernutzung zwischen CLI7 und CLI8 in Knoten 10 im Vergleich zu Knoten 12. Dies zeigt an, dass Knoten 12 in einigen Fällen den Speicher besser verwaltet.

clarity verwendet 70% zusätzlichen Speicher in Knoten 12 im Vergleich zu Knoten 10. Dies zeigt an, dass Knoten 12 in einigen Fällen viel mehr Speicher verwenden kann.

Wenn Sie sich auf Knoten 12 befinden und das Speicherlimit erreichen, sollten Sie zunächst Knoten 10 ausprobieren.

Wir werden den beibehaltenen Speicher während der Erstellung von Differential Loading und die Ausreißer wie awesome-angular-workshop .

Eigentlich bin ich mir ziemlich sicher, dass selbst mit "target": "es5" die Speichernutzung durch das Dach gegangen ist. Ich würde nicht nur die unterschiedliche Belastung dafür verantwortlich machen. Ich würde tatsächlich TerserPlugin beschuldigen, was sehr ineffizient sein kann und tatsächlich seit Winkel 8 ist.

@schmitch soweit ich das

In Bezug auf TerserPlugin können Sie es mit --optimization=false deaktivieren. Sie können diese Option in der Produktkonfiguration auch in angular.json festlegen. Aber Fälle, in denen Sie es ausschalten, sind Fälle, in denen Sie stattdessen wirklich nur den Nicht-Produkt-Modus verwenden würden.

Während Knoten 12 versucht, die Option --max_old_space_size automatisch zu konfigurieren, begrenzt die dafür verwendete V8-Methode den Wert auf 2048 MB .

Das neue Standardmaximum von 2048 MB wurde unter https://github.com/nodejs/node/issues/28202 gemeldet

Gemeldeter Knoten 12 mit mehr Speicher in https://github.com/nodejs/node/issues/28205.

Ich bin heute darauf gestoßen, als ich versucht habe, Quellkarten für meinen Produktionsbuild zu aktivieren.

FATAL ERROR: Ineffektive Mark-Compacts nahe der Heap-Grenze Zuordnung fehlgeschlagen - JavaScript-Heap nicht genügend Speicher
1: 0x8dc510 node :: Abort () [ng build --prod]

Ich hatte diesen Fehler; Es stellte sich heraus, dass ich einen Sicherungsordner node_modules in meinem Projektverzeichnis belassen hatte. Durch Löschen wurde das Problem behoben.

Meine Angular-Builds dauern heute viel länger und einige scheitern sogar mit einem FATAL ERROR.

von dienen --prod

** Angular Live Development Server is listening on localhost:4200, open your browser on http://localhost:4200/ **
 92% chunk asset optimization TerserPlugin                                       
<--- Last few GCs --->

[1730:0x103800000]   217578 ms: Scavenge 1350.0 (1422.7) -> 1349.4 (1423.2) MB, 7.1 / 0.0 ms  (average mu = 0.212, current mu = 0.135) allocation failure 
[1730:0x103800000]   217589 ms: Scavenge 1350.2 (1423.2) -> 1349.6 (1423.7) MB, 7.4 / 0.0 ms  (average mu = 0.212, current mu = 0.135) allocation failure 
[1730:0x103800000]   217606 ms: Scavenge 1350.4 (1423.7) -> 1350.1 (1424.7) MB, 12.6 / 0.0 ms  (average mu = 0.212, current mu = 0.135) allocation failure 


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x2d9cf905be3d]
    1: StubFrame [pc: 0x2d9cf90134b0]
Security context: 0x3a5b0e11e6e1 <JSObject>
    2: new SourceNode [0x3a5b0f4ff279] [/Users/rac/Desktop/git/requisite-variety/node_modules/webpack-sources/node_modules/source-map/lib/source-node.js:~35] [pc=0x2d9cfb660621](this=0x3a5b97cf6d31 <SourceNode map = 0x3a5be9ed4219>,aLine=289,aColumn=31,aSource=0x3a5b7b5a01f1 <String[122]: /Users/rac/Desktop/git/requisite...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003ae75 node::Abort() [/usr/local/bin/node]
 2: 0x10003b07f node::OnFatalError(char const*, char const*) [/usr/local/bin/node]
 3: 0x1001a7ae5 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
 4: 0x100572ef2 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/usr/local/bin/node]
 5: 0x1005759c5 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/usr/local/bin/node]
 6: 0x10057186f v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/local/bin/node]
 7: 0x10056fa44 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node]
 8: 0x10057c2dc v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/usr/local/bin/node]
 9: 0x10057c35f v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/usr/local/bin/node]
10: 0x10054bca4 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/usr/local/bin/node]
11: 0x1007d3b54 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/bin/node]
12: 0x2d9cf905be3d 
Abort trap: 6

npm v 6.4.1
Knoten v10.13.0
"@ angle / core": "~ 7.2.0"
"@ angle / cli": "~ 7.3.7",

@filipesilva , ich habe es mit dem Benchmark-Tool

Auf meinem Computer geht es vorbei, es ist wirklich auf Azure, dass es nicht ist. Auf meinem Computer bekomme ich mit AOT ungefähr 2 GB für den Build.
Ich habe einen Versuch mit AOT ein / aus gemacht, weil DL für mich kein Problem darstellt.
Ich habe Angular auf 8.0.2 aktualisiert.

Unter Azure ohne AOT funktioniert es, aber nach 15 Minuten Inaktivität in Chrome wird ein Aw-Snap aus dem Speicher entfernt. Ich kann den Finger noch nicht auf AOT richten, da ich von Angular 6 zu Angular 8 gewechselt bin. Außerdem bekomme ich auf meinem Computer diesen Aw-Snap nicht (der Code wird auch nicht minimiert und ich verwende ng Serve).

Dieser ganze Angular 8 bereitet mir Kopfschmerzen, wenn ich in der Produktion arbeite. Wir wollten jedoch die Vorteile einer höheren Version von TypeScript nutzen ...

AOT = ein

[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   ng build 3cconnect --prod --configuration staging (at D:\git\clients\hbti\Portal\hbti-web-master\HBTI.ServiceTech.Web2.Client)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 189010.00 ms (345029.00, 148765.00, 153791.00, 152923.00, 144542.00)
[benchmark]   Average Process usage: 1.33 process(es) (2.64, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 2.40 process(es) (8.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 13.13 % (10.44, 13.75, 14.26, 13.56, 13.65)
[benchmark]   Peak CPU usage: 184.38 % (171.90, 175.00, 196.90, 187.50, 190.60)
[benchmark]   Average Memory usage: 1024.72 MB (1143.24, 1001.46, 1041.20, 953.13, 984.56)
[benchmark]   Peak Memory usage: 1860.07 MB (3000.74, 1577.36, 1616.97, 1516.06, 1589.24)

AOT = aus

[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   ng build 3cconnect --prod --configuration staging (at D:\git\clients\hbti\Portal\hbti-web-master\HBTI.ServiceTech.Web2.Client)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 233620.00 ms (233375.00, 231213.00, 226946.00, 249170.00, 227396.00)
[benchmark]   Average Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 15.51 % (16.71, 15.90, 15.03, 14.74, 15.16)
[benchmark]   Peak CPU usage: 232.84 % (240.70, 306.30, 206.20, 236.00, 175.00)
[benchmark]   Average Memory usage: 1474.39 MB (1467.56, 1476.16, 1427.16, 1526.26, 1474.80)
[benchmark]   Peak Memory usage: 2213.60 MB (2217.81, 2224.59, 2184.01, 2224.69, 2216.90)

das gleiche Problem auf Ubuntu Server 18.04, aber dies löste mein Problem:
node --max_old_space_size = 8192 node_modules / @ angle / cli / bin / ng build --prod

Lassen Sie dies hier einfach fallen, aber wenn jemand AWS Codebuild verwendet, stellen Sie sicher, dass Ihre Build-Umgebung so aktualisiert wird, dass sie mit mehr als mindestens 3 GB Arbeitsspeicher konfiguriert wird. Ich habe die obigen Schritte ausgeführt, musste jedoch meine Umgebung mit mehr Arbeitsspeicher neu konfigurieren.

Heya alle,

Zunächst einmal entschuldigen Sie die Verzögerung. Ich AFK für einen guten Teil der letzten Woche.

Ich versuche so genau wie möglich zu beschreiben, was ich getan habe, um diese Art von Problem zu untersuchen, weil ich in der Vergangenheit danach gefragt wurde (ich sehe dich an @johnpapa und @DanWahlin : Welle :). Ich finde es auch nützlich für mich, in Zukunft auf diese Aufzeichnungen zurückzukommen, weil ich die Details vergesse, wie diese Dinge zu tun sind, oder sie mit Kollegen teilen möchte, damit sie das Gleiche tun können. Eine Menge der hier beschriebenen Arbeit wird erledigt, indem man direkt in node_modules herumfummelt und dort die Logik ändert, um Dateien zu schreiben, die ich später debugge, Informationen protokolliere oder andere Pakete verwende. Ich finde, dass das Fummeln mit den JS-Quellen wirklich die beste Art ist, Dinge zu untersuchen, da ich die meiste Zeit nicht weiß, wonach ich suche, und es daher hilfreich ist, sie zu erkunden.

Zu diesem Zeitpunkt haben wir bereits festgestellt, dass Knoten 12 ein Standardspeicherlimit von 2048 MB hat (https://github.com/nodejs/node/issues/28202) und mehr Speicher als Knoten 10 (https://github.com) verwendet / nodejs / node / issue / 28205). Dies ist bedauerlich, aber im Moment Realität. Daher sollten wir uns vorerst auf Knoten 10 konzentrieren, während die Knotenleute Speicherprobleme ansprechen. Ich verwende Node 10.16.0 selbst zum Testen.

Ich habe an der Profilerstellung gearbeitet, bei der Speicher in den problematischen Builds verwendet wird. Der erste Schritt dazu ist die Entscheidung, aus welchem ​​Projekt Profildaten abgerufen werden sollen. Ich habe mich für Angular -Workshop entschieden, weil ich in https://github.com/angular/angular-cli/issues/13734#issuecomment-500849058 zu dem Schluss gekommen bin, dass es das Projekt war, bei dem wir die größten Auswirkungen sehen konnten ::

Awesome-Angular-Workshop leidet unter einem überproportionalen Anstieg der Speichernutzung (45%) und der Build-Zeit (150%) von CLI7 auf CLI8DL. Dies weist auf eine lokalisierte Regression hin.

Ich habe eine Gabelung davon unter https://github.com/filipesilva/awesome-angular-workshop gemacht, SHA 9076a3d mit lokalen Modifikationen festgeschrieben, um leicht reproduzierbare Benchmarks zu erhalten. Das ist der Code, den ich in https://github.com/filipesilva/angular-cli-perf-benchmark verwendet habe. Der Build-Befehl, den ich verwende, ist ng build 5-ngrx-end --prod , da dieser Arbeitsbereich mehrere Projekte enthält und ich nur dieses spezielle verwenden möchte.

Meine ursprüngliche Idee war es, die Chrome Node DevTools zu verwenden, eine Reihe von Profildaten zu sammeln und dann zu versuchen, sie zu untersuchen, um umsetzbare Informationen zu finden.

Öffnen Sie zum Öffnen der Chrome Node DevToolsKlicken Sie in Chrome auf "Öffnen Sie dedizierte DevTools für Node". Wenn Sie einen Knotenprozess mit dem Flag --inspect-brk gestartet haben, sollte DevTools automatisch eine Verbindung herstellen. Eine einfache Möglichkeit, Angular CLI wie folgt auszuführen, besteht darin, ein npm-Skript zu erstellen: "ng-inspect": "node --inspect-brk node_modules/@angular/cli/bin/ng", . Wenn Sie dann npm run ng-inspect -- build --prod ausführen und DevTools geöffnet haben, wird automatisch eine Verbindung hergestellt. An dieser Stelle können Sie Haltepunkte setzen und Profile erstellen.

Auf der Registerkarte "Speicher" befinden sich verschiedene Profiling-Tools und Beschreibungen ihrer Funktionen. Wenn Sie diese verwenden, müssen Sie zu den Quellen gehen und auf die Ausführung des Wiederaufnahmeskripts (oben rechts) klicken, bevor etwas passiert. Ich habe einige Zeit damit verbracht, die verschiedenen Profiltypen in einfacheren Knotenprozessen zu testen, um herauszufinden, welches besser wäre. Ich war bereits daran gewöhnt, die CPU-Profile zu lesen, als ich die Build-Zeit debuggte, daher klang das Allocation-Sampling (auch bekannt als Heap-Profil) interessant, da es zeigen sollte, wie viel Speicher jede Funktion zu einem bestimmten Zeitpunkt verwendet. Heap-Schnappschüsse zeigen, was sich zu einem bestimmten Zeitpunkt im Speicher befindet und was diese Objekte aufbewahrt. Es würde auch funktionieren, ist aber nicht so einfach zu lesen und vermittelt einen Überblick über das Geschehen.

Um ehrlich zu sein, war das Erfassen von Profilen mit DevTools viel schwieriger als erwartet. Es scheint tatsächlich nicht gut mit der Erfassung von Profilen aus großen laufenden Knotenprozessen umzugehen. Ich habe gesehen, wie es beim Aufnehmen von Profilen oder am Ende bei der Verarbeitung der meisten Profile, die ich zu erstellen versuchte, abgestürzt ist.

Ich habe versucht, Alternativen zu finden. Eine davon bestand darin, kleinere Teile gleichzeitig zu profilieren, damit DevTools nicht abstürzte, aber es sah so aus, als würde es bei einigen Profiltypen ohnehin immer abstürzen, selbst bei neuen CLI-Projekten, sodass dies nicht viel zu bedeuten schien. Ich habe ndb ausprobiert, aber es schien unter den gleichen Problemen zu leiden. Das automatisierte Chrome-Profiling schien vielversprechend, da es seit einiger Zeit nicht mehr aktualisiert wurde und nur CPU-Profile verwendete. @manekinekko schlug vor, aber soweit ich das node-oom-heapdump sah für Heap-Snapshots gut aus, erforderte jedoch native Bindungen, was mir nicht besonders gefiel, da es schwieriger wäre, sie später für die Benutzerprofilerstellung direkt in die CLI zu integrieren. Sampling-Heap-Profiler sah für Heap-Profile gut aus, benötigte aber auch native Bindungen. @ofrobots schlug https://github.com/google/pprof-nodejs vor, das ich versuchte und mir wirklich schöne Visualisierungen zu geben schien, aber es brauchte auch native Bindungen und ein Go-Tool zum Lesen, was die Integration erschweren würde .

Letztendlich habe ich mich dafür entschieden, einen benutzerdefinierten Profilierungscode zu erstellen, der auf der hier beschriebenen Unterstützung für experimentelle Node-Profiler basiert. Ich habe mich vom Code im Sampling-Heap-Profiler und der Profiler-API inspirieren lassen, um herauszufinden, was zu verwenden ist. Daraus habe ich einen automatisierten Profiling-Code erstellt, der wie folgt aussieht: https://github.com/angular/angular-cli/pull/14936. Zum Zeitpunkt des Schreibens steuere ich die Flags in der Datei manuell, aber vielleicht können wir sie in Zukunft irgendwie verfügbar machen. Es können CPU-Profile des gesamten Prozesses oder Heap-Snapshots / -Profile in festgelegten Intervallen erstellt werden. Dies schien eine gute Möglichkeit zu sein, da ich möglicherweise Personen mit Build-Geschwindigkeits- oder Speicherproblemen in Zukunft bitten möchte, diese Profile zu übernehmen und an uns zu senden.

Mit diesem Setup konnte ich reproduzierbare Profile mit minimalem Herumspielen erstellen. Das Reduzieren des Fummelns ist wirklich wichtig, wenn das Sammeln Ihrer Informationen lange dauert. Je mehr Fummeln Sie tun müssen, desto höher ist die Wahrscheinlichkeit, dass Sie eine bestimmte Probe verpfuschen. Wenn Sie eine Probe verpfuschen und sie erst Stunden später finden, müssen Sie möglicherweise die meisten Ihrer Schlussfolgerungen für diesen Zeitraum wegwerfen, da Ihre Ausgangspunkte schlecht waren und Schlussfolgerungen und Vergleiche daher nicht korrekt waren.

Mit diesem Bedarfstool konnte ich einige Heap-Profile von CLI7- und CLI8-Builds (ohne unterschiedliche Belastung) erfassen, um sie zu vergleichen. Ich habe sie in DevTools geöffnet und versucht herauszufinden, welche Teile der Build-Pipeline in den einzelnen Abschnitten des Profils enthalten sind.

Die CLI7 sah folgendermaßen aus:

Die CLI8 sah folgendermaßen aus:

CLI8 verwendet etwa 180 MB mehr Speicher für insgesamt 760 MB im Vergleich zu 580 MB, die von CLI7 verwendet werden. Was mir am meisten auffiel, war der Unterschied in der CSS-Verarbeitung. Es sieht so aus, als würde es in CLI8 viel länger dauern. In CLI8 haben wir standardmäßig dart-sass (in npm als nur sass ) anstelle von node-sass verwendet (siehe https://github.com/angular/angular-cli/pull/11791, https: //github.com/angular/angular-cli/pull/13950) ist also ein großartiger Kandidat für eine Untersuchung.

Wir haben erwartet, dass dart-sass nicht so performant ist wie node-sass daher können Sie zu node-sass indem Sie es in Ihrem Projekt installieren ( npm install node-sass --save-dev ). Solange es installiert ist, werden wir es automatisch abholen. Sie können auch mit dart-sass mit den Fasern als in der gleichen Art und Weise durch die Installation Paket für eine bessere Leistung node-sass . Sowohl node-sass als auch fibers verwenden native Bindungen und funktionieren möglicherweise nicht auf allen Computern, weshalb wir sie nicht standardmäßig installieren.

Dann habe ich Profile für CLI8, CLI8 mit node-sass , CLI8 mit fibers und CLI 7 nebeneinander verglichen, um zu sehen, wie sie sich geändert haben.

Die Verwendung von node-sass scheint also zumindest bei diesem Projekt die CLI7-Ebenen für die Speichernutzung zurückzugeben. Die Verwendung von nur fibers reduziert den Speicher nur um etwa 20 MB.

Wie @clydin hervorhob , ist dies möglicherweise nicht das vollständige Bild, da die Heap-Profile nur für den von V8 verwalteten Speicher bestimmt sind. node-sass möglicherweise mehr Speicher, der nicht im Profil angezeigt wird. Also habe ich die Prozesse selbst verglichen:

• CLI 8

[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   ng build 5-ngrx-end --prod (at D:\sandbox\memory-debug\awesome-angular-workshop)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 157486.80 ms (157292.00, 159517.00, 156464.00, 159606.00, 154555.00)
[benchmark]   Average Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 18.31 % (18.68, 18.63, 18.04, 18.76, 17.46)
[benchmark]   Peak CPU usage: 205.60 % (237.50, 204.60, 198.40, 196.90, 190.60)
[benchmark]   Average Memory usage: 1008.24 MB (1048.68, 975.86, 1017.15, 1020.31, 979.21)
[benchmark]   Peak Memory usage: 1560.48 MB (1588.38, 1489.02, 1583.70, 1574.51, 1566.81)

• CLI 8 mit node-sass

[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   ng build 5-ngrx-end --prod (at D:\sandbox\memory-debug\awesome-angular-workshop)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 103204.00 ms (98623.00, 103302.00, 105260.00, 104674.00, 104161.00)
[benchmark]   Average Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 16.70 % (15.46, 15.94, 17.36, 17.48, 17.26)
[benchmark]   Peak CPU usage: 152.50 % (160.90, 89.10, 190.60, 128.10, 193.80)
[benchmark]   Average Memory usage: 676.14 MB (681.11, 674.49, 676.65, 675.08, 673.38)
[benchmark]   Peak Memory usage: 1443.15 MB (1444.21, 1439.97, 1435.09, 1449.96, 1446.53)

• CLI 8 mit fibers

[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   ng build 5-ngrx-end --prod (at D:\sandbox\memory-debug\awesome-angular-workshop)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 126098.00 ms (136145.00, 125063.00, 123654.00, 123849.00, 121779.00)
[benchmark]   Average Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.00 process(es) (1.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 14.55 % (16.18, 14.48, 14.25, 14.05, 13.79)
[benchmark]   Peak CPU usage: 190.30 % (215.50, 173.40, 184.40, 170.30, 207.90)
[benchmark]   Average Memory usage: 746.22 MB (752.84, 741.56, 745.46, 747.52, 743.72)
[benchmark]   Peak Memory usage: 1560.88 MB (1603.68, 1555.96, 1575.40, 1569.62, 1499.73)

Es sieht also so aus, als ob node-sass wirklich weniger Speicher benötigt und weniger Zeit zum Erstellen benötigt. fibers ist das zweitbeste. Der durchschnittliche Speicher, der im Fall fibers wird, scheint jedoch mit den Ergebnissen der Heap-Profile in Konflikt zu stehen. Hier sehen wir CLI8 mit fibers Verwendung von ~ 750 MB im Vergleich zum ursprünglichen CLI8 ~ 1000 MB, aber in Das Heap-Profil mit fibers reduzierte den Speicher nur um ~ 20 MB. Ich weiß nicht warum das so ist. Vielleicht liegt es an der Art der Mittelung des verwendeten Speichers, oder vielleicht liegt es daran, dass mehr Speicherbereinigungszyklen Heap-Profile verwenden. Aber am Ende des Tages scheint node-sass der Gewinner zu sein, was die Leistung betrifft.

Ich fand es auch seltsam, dass ein großer Teil des zusätzlichen Speichers im CLI8-Heap-Profil aus der PostCSS-Verarbeitung zu stammen scheint. Ich hatte nicht erwartet, dass PostCSS etwas anderes tun muss. Ich dachte, dass ich vielleicht nur falsch interpretiert habe, wofür dieser Abschnitt verwendet wurde. Aber vielleicht könnte sich die Ausgabe von dart-sass von node-sass und dies könnte mehr Arbeit für PostCSS verursachen. Es hat sich gelohnt, einen Blick darauf zu werfen, also habe ich Code direkt in sass-loader hinzugefügt, um die Ergebnisse der Sass-Kompilierung auf die Festplatte zu schreiben. Die Ausgabe für dart-sass und node-sass schien bis auf einige Leerzeichen wirklich dieselbe zu sein, daher habe ich den der Sass-Verarbeitung zugewiesenen Speicher nur als PostCSS zugewiesen interpretiert.

@johnpapa , abgesehen davon habe ich bemerkt, dass die meisten CSS-Komponentendateien in diesem Projekt mixin.scss importieren. Diese Datei ~ hat keine Mixins und enthält nur ~ das gesamte Materialthema mit 70 KB (Voroptimierungen) von CSS-Definitionen der obersten Ebene. Komponenten-CSS ist eigenständig und von anderen CSS isoliert, sodass keine Deduplizierung oder ähnliches erfolgt. Wenn es in Komponenten-CSS importiert wird, fügen Sie dieser Komponente CSS im Wert von 70 KB hinzu, was wahrscheinlich ein Vielfaches der Größe der Komponente selbst entspricht. @jelbourn hat den Import von Nicht-Mixin-Sass als Anti-Pattern beschrieben, aber es ist nicht die Art von Information, die rundum offensichtlich ist. Wir könnten die Leute besser darüber informieren und sie warnen, wenn das CSS der Komponente sehr groß ist (cc @vikerman).

Eine andere Seite ist, dass ich auch bemerkt habe, dass das Kompilieren nur eines einzelnen Projekts über ng build 5-ngrx-end --prod tatsächlich alle .ts und .scss Dateien in src/ kompiliert. Dies liegt daran, dass alle Projekte in diesem Arbeitsbereich dasselbe ./src/tsconfig.app.json und diese tsconfig alle ts-Dateien enthält (außer Unit-Tests). Das heißt, wenn Sie hier ein einzelnes Projekt kompilieren, werden tatsächlich alle Projekte kompiliert. Die einzige Möglichkeit, dies wirklich zu beheben, besteht darin, für jede App eine tsconfig zu haben. Ich frage mich, wie häufig dieser Fehler ist. Ich wäre nicht überrascht, wenn größere Projekte versehentlich zusätzliche TS-Dateien enthalten würden. Vielleicht könnten wir Benutzer warnen, wenn wir sehen, dass die TS-Kompilierung viel mehr Dateien enthält als die, die das Webpack lädt (cc @vikerman , @clydin).

Wenn Sie also ein großes Projekt haben, sollten Sie node-sass für Ihre devDependencies installieren. Dies beschleunigt das Erstellen und benötigt weniger Speicher.

Obwohl es sich zwischen CLI7 und CLI8 nicht zu ändern schien, ist die Angular-Kompilierung selbst mit rund 230 MB bei weitem der größte Beitrag zum Speicherbedarf. Vielleicht können wir alle Verweise darauf vollständig löschen, wenn wir nicht im Überwachungsmodus erstellen, sodass Node diesen Speicher freigeben kann. Ich werde das als nächstes untersuchen.

@filipesilva nur ein kurzes Update: Ich habe versucht, Node-Sass mit Winkel 8 für Superproduktivität zu verwenden. Das Ergebnis ist das gleiche:

• Alle Builds funktionieren ohne Sourcemaps
• ng build --aot & ng serve beide mit Quellenkarten
• ng build --prod löst den Fehler JavaScript heap out of memory

Ich habe sowohl Knoten 10 als auch Knoten 12 ausprobiert. Die Ergebnisse sind gleich.

@johannesjo ng build --aot und ng serve sich stark von ng build --prod . Ich glaube nicht, dass man durch einen Vergleich etwas gewinnen kann. Produktions-Builds verbrauchen immer mehr Speicher als Nicht-Produktions-Builds.

Beim Benchmarking von super-productivity ich diese Ergebnisse für Node 10.16.0 erhalten:

• CLI Version 8 mit differenzieller Belastung

[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   ng build --prod (at /home/circleci/project/project)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 203022.00 ms (320720.00, 185220.00, 170860.00, 155420.00, 182890.00)
[benchmark]   Average Process usage: 1.35 process(es) (2.75, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.80 process(es) (5.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 164.51 % (154.16, 163.92, 168.56, 171.13, 164.77)
[benchmark]   Peak CPU usage: 557.11 % (650.00, 555.56, 520.00, 520.00, 540.00)
[benchmark]   Average Memory usage: 1333.09 MB (1709.25, 1234.43, 1236.67, 1225.88, 1259.21)
[benchmark]   Peak Memory usage: 2019.59 MB (2671.33, 1807.51, 1857.44, 1883.19, 1878.46)

• CLI Version 8 ohne Differenzbelastung

[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   ng build --prod (at /home/circleci/project/project)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 87418.00 ms (91750.00, 94150.00, 92950.00, 77520.00, 80720.00)
[benchmark]   Average Process usage: 1.03 process(es) (1.13, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.60 process(es) (4.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 160.13 % (162.86, 155.83, 158.79, 161.31, 161.87)
[benchmark]   Peak CPU usage: 546.89 % (650.00, 544.44, 520.00, 510.00, 510.00)
[benchmark]   Average Memory usage: 1032.07 MB (1048.05, 1040.10, 1004.07, 999.71, 1068.42)
[benchmark]   Peak Memory usage: 1659.71 MB (1813.00, 1615.65, 1684.55, 1571.28, 1614.09)

• CLI Version 7

[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   ng build --prod (at /home/circleci/project/project)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 89746.00 ms (145060.00, 78430.00, 77020.00, 77210.00, 71010.00)
[benchmark]   Average Process usage: 1.36 process(es) (2.81, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 1.80 process(es) (5.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 156.10 % (152.71, 155.33, 157.43, 156.50, 158.52)
[benchmark]   Peak CPU usage: 548.44 % (680.00, 522.22, 520.00, 520.00, 500.00)
[benchmark]   Average Memory usage: 1086.97 MB (1592.65, 963.42, 960.56, 971.31, 946.89)
[benchmark]   Peak Memory usage: 1702.50 MB (2539.70, 1438.24, 1606.59, 1474.61, 1453.35)

Bei Produktions-Builds habe ich keinen wirklichen Unterschied zwischen "CLI Version 7" und "CLI Version 8 ohne differenzielle Belastung" festgestellt. Bei Verwendung der Differenzlast gibt es jedoch einen Unterschied von ~ 200 MB. Derzeit scheinen Sie jedoch kein differenzielles Laden zu verwenden (Ihre Root-tsconfig hat ein es5-Ziel).

Wir könnten jedoch verschiedene Dinge vergleichen. Ich vergleiche die Verwendung von Angular 8 mit CLI 7 und 8. Wenn Sie sowohl mit Angular 7 als auch mit Angular 8 testen, können unterschiedliche Ergebnisse auftreten. Welchen Vergleich machen Sie? Haben Sie zwei Commits, bei denen ich sehen kann, wo sich nur die Version der Angular-Pakete geändert hat, aber ng build --prod vom erfolgreichen Abschluss zum Fehlschlagen mit Fehlern aufgrund von Speichermangel übergegangen ist?

@filipesilva Die entscheidende Einstellung scheint das Flag buildOptimizer (oder es ist zumindest das Flag mit dem größten Einfluss auf die Speichernutzung). Wenn ich es deaktiviere. Der Build läuft unabhängig von den anderen Konfigurationsparametern einwandfrei, auch wenn sourceMap auf true gesetzt ist.

Ich habe keine Ahnung, wie alle Interna funktionieren, daher ist dies wahrscheinlich nicht allzu hilfreich, aber meine wilden Vermutungen über die Ursache wären folgende:

• Die Build-Optimierungen werden irgendwie durch das Vorhandensein der Sourcemaps oder des zugehörigen Codes im CSS beeinflusst
• Die Sourcemap-Extraktion wird parallel zu den Build-Optimierungen ausgeführt
• Die Sourcemap-Extraktion wird vor der Build-Optimierung ausgeführt, der Speicher wird jedoch erst bereinigt, wenn die gesamte Build-Aufgabe ausgeführt wurde oder umgekehrt
• Beide Prozesse sind irgendwie miteinander verflochten

Vielleicht gibt es eine Inspiration für die wahre Ursache darin;)

@johannesjo Sowohl Build Optimizer als auch

Bearbeiten: markiert @JohannesHoppe anstelle von @johannesjo. Das tut mir leid!

Ich arbeite immer noch an diesem Problem. Notizen aus den letzten Tagen unten.

Während er mit @clydin darüber

Zuerst muss ich herausfinden, was Speicher auf dem Höhepunkt verwendet. Ich denke, es ist hässlich und Build-Optimierer, aber ich weiß es nicht. Es ist seltsam, dass die Profile, die ich nehme, niemals Spitzenauslastung zeigen. Ich frage mich, ob ich dort etwas falsch mache. Ich habe gerade einen Prozess ohne Profilerstellung gestartet und sehe Speicher bei ~ 1200 während der scheinbar ng-Kompilierung, dann beim Laden von Dateien auf ~ 900 MB, dann bei 90% + auf ~ 1300 und ~ 1500 MB. Aber meine Profile zeigen eine max. Zuweisung von ~ 800 MB.

Vielleicht muss ich den Zeitpunkt kontrollieren, zu dem ich diese Profile aufnehme. Wenn es das ist, muss ich den genauen Zeitpunkt finden, zu dem die Nutzung hoch ist, und dort ein Profil erstellen. Wenn Sie process.memoryUsage() wie unter https://www.valentinog.com/blog/memory-usage-node-js/ beschrieben, kann ich möglicherweise Zeiträume mit hoher Speichernutzung identifizieren. Ich kann einen Speicherschwellenwert festlegen und nur Profile zu diesem Zeitpunkt erstellen.

Es kann sein, dass das Aufnehmen eines Heap-Profils GC auslöst oder dass die erhöhte Laufzeit GCs häufiger auffordert. Ich kann versuchen, gc direkt vor jedem Heap-Profil auszulösen und zu sehen, ob das Ergebnis das gleiche ist. https://stackoverflow.com/questions/27321997/how-to-request-the-garbage-collector-in-node-js-to-run zeigt, wie. Habe das getan und keinen wirklichen Unterschied in den Profilen gesehen. Was auch immer die Profile zeigen, scheint tatsächlich beibehalten zu werden.

Ich habe setInterval mit einem Protokoll für process.memoryUsage () verwendet, die gemeldete Speichernutzung des Task-Managers im Auge behalten und einige Dinge bemerkt. Wenn ich sage, dass ich 1234/5678 gesehen habe, war 1234 im Task-Manager und 5678 in der process.memory-Protokollierung.

Die höchsten 1300 / ???? geschah während der Angular Compiler Phase, aber nur mit Dart-Sass. Mit Node-Sass ist es bei 900/700 niedriger und es wurde eine Intervallprotokollierung durchgeführt. Ich habe fast keine Protokollierung für diese Phase mit Dart-Sass erhalten. Ich denke, weil das setInterval nie richtig in die Ereignisschleife gelangt ist. Ich denke, weil viele Dinge synchron sind. Mit Node-Sass habe ich damals viel Protokollierung gesehen. Vielleicht ist es eine native Bindungssache, es könnte die Ereignisschleife freigeben. Wie auch immer, Dart-Sass scheint das Laden von Ressourcen im Winkel-Compiler besonders schlecht zu machen, indem Speicher für eine bereits teure Reihe von Operationen aufgestapelt wird.

Ich sah einige Spitzen von 1200/900, während der Fortschritt das Laden einzelner Dateien zeigte. Ich denke, das ist Build Optimizer, da es ein JS-Loader ist.

Ich habe während Terser kaum eine Speichernutzung gesehen, aber ich wette, das liegt am Cache. Ich habe den Terser-Webpack-Plugin-Cache deaktiviert und 1100/940 gesehen, aber auch eine Reihe von hervorgebrachten Prozessen zwischen 40 und 400 MB.

Soweit ich das beurteilen konnte, war das Sass-Ding tatsächlich ein großer Teil des Erreichens des Gipfels, da es während der ng-Kompilierung ausgeführt wird und sich auf etwas stapelt, das bereits speicherintensiv ist.

Ich wette, es hilft auch nicht, dass wir dafür Webpack-Subkompilierungen durchführen. Dies bedeutet auch, dass selbst wenn wir alle Verweise auf Speicher, die während der ng-Kompilierung verwendet wurden, freigegeben würden, dies nicht so wichtig wäre, da diese Kompilierung immer noch Teil des Peaks ist.

Wir haben bereits Pläne, Build Optimizer zu entfernen, damit mich das nicht sonderlich stört

In Bezug auf Terser ... Nun, wenn wir einen kleineren Speicherbedarf für den Hauptprozess hätten, würde sich die Gesamtsumme offensichtlich verringern. Aber vielleicht können wir das Plugin auch intelligenter machen. Es scheint auf Brocken zu laufen
https://github.com/webpack-contrib/terser-webpack-plugin/blob/a0d83170168e786004fa12b94525b2934a17a4f5/src/index.js#L416 -L419
Wir wissen jedoch, dass Terser nicht aus dem Webpack-Modul-Loader ausbrechen kann, sodass es keinen Sinn macht, ganze Chunks zu verarbeiten. Könnte auch die einzelnen Webpack-Module verarbeiten, die viel kleiner sein sollten.

So wichtige Dinge zu verfolgen:

• Verbesserung der Leistung des Terser-Webpack-Plugins (https://github.com/webpack-contrib/terser-webpack-plugin/issues/104)
• Verbesserung der Leistung von Sass-Loadern (https://github.com/webpack-contrib/sass-loader/issues/701)
• Reduzieren Sie die maximale Auslastung des ngc-Speichers
• freier ngc speicher nach dem emittieren
• Build-Optimierer entfernen

Wie der andere vorgeschlagen hatte, behebt das Ausführen von node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod das Problem, und node.exe konnte bis zu 5,5 GB Speicher zum Kompilieren meiner großen, fetten NG-App verwenden. Anscheinend verbraucht Angular 8 Build viel mehr Speicher als Angular 7 Build.

Jetzt für den Debug-Build verwende ich:
node --max_old_space_size=8192 "node_modules/@angular/cli/bin/ng" build --base-href /ng/ --aot

Für den Produktionsaufbau verwende ich:
node --max_old_space_size=8192 "node_modules/@angular/cli/bin/ng" build --configuration=production

Ich würde jedoch lieber ng build ... als ` node --max_old_space_size=8192 "node_modules/@angular/cli/bin/ng" build .

Es wird schön sein, dass das NG CLI-Team irgendwo in der Konfiguration ng build max_old_space_size lesen lässt.

Übrigens, mit nahezu identischer Codebasis vor dem Wechsel zu NG8 beträgt die Knotenspeichernutzung mit NG7-Build 1,3 GB. Ich hatte gesehen, dass die anderen in NG 8 Build so viel Speicherplatz gemeldet hatten.

@zijianhuang von 1.3 auf 5.5 zu gehen ist viel mehr als in anderen Projekten, die ich getestet habe. Ist Ihr Projekt irgendwo, wo ich einige Benchmarks sehen könnte? Welche Node-Version verwenden Sie?

@filipesilva , Wenn Sie einen gesicherten Upload-Speicherort oder Ihre E-Mail-Adresse angeben könnten, könnte ich sowohl den ng7-Code als auch den ng8-Code komprimieren, damit Sie beide erstellen und vergleichen können. Knoten und npm sind im Grunde die neuesten.

Ich würde gerne einen Blick darauf werfen. WDYT, dass Sie ein privates Github-Projekt haben, auf das Sie mir Zugriff gewähren? Die privaten sind jetzt für bis zu drei Mitarbeiter kostenlos, sodass Sie nichts bezahlen würden. Sie können den Zugriff auch jederzeit entfernen.

In meinem Fall besteht ein großer Unterschied darin, dass es2015 als Ziel in tsconfig.json ist. Ich konnte Ihr Benchmark-Tool nicht verwenden (habe nirgendwo eine Verwendung gefunden), aber mit time Der maximale RSS-Wert von es5 beträgt 1,3 GB mit es2015 5,9 GB. Nach dem Wechsel von Knoten 10 + Winkel 7 zu Knoten 12 + Winkel 8 sind alle Builds aufgrund der Speichernutzung fehlgeschlagen

@filipesilva , Einladung gesendet. Bitte überprüfen Sie auch mein Benchmark-Ergebnis in readme.txt.

@ alex88 finden Sie das von mir verwendete Benchmark-Tool unter https://github.com/filipesilva/angular-cli-perf-benchmark#benchmark -package. Wenn Sie mir einen Repro über ein privates Github-Repository zur Verfügung stellen möchten, würde ich gerne auch einen Blick darauf werfen.

@zijianhuang ein großes Dankeschön, dass du mir einen Repro zum Anschauen gegeben hast. Ich habe es mir heute mit dem Benchmark-Paket angesehen, das unter https://github.com/filipesilva/angular-cli-perf-benchmark beschrieben ist.

Beachten Sie, dass die von diesem Tool erfassten Speichernummern auch erzeugte Prozesse enthalten. In der CLI verwenden wir ein Minifier-Paket ( terser-webpack-plugin ), das mehrere Prozesse erzeugt. Daher ist es nützlich, den Speicher zu erfassen, den auch die untergeordneten Prozesse verwenden.

Dieses Paket speichert jedoch auch die Minifizierungsergebnisse zwischen. Der erste Lauf macht also mehr Arbeit als die nachfolgenden. Als ich Ihre Pakete verglichen habe, habe ich ./node_modules/@angular-devkit/build-angular/src/angular-cli-files/models/webpack-configs/common.js manuell bearbeitet und cache: true in cache: false geändert, um diesen Cache zu deaktivieren und konsistente Zahlen zu erhalten.

Ich habe auch diese beiden npm-Skripte hinzugefügt, um das Benchmarking zu erleichtern:

        "benchmark": "benchmark -- node --max_old_space_size=8000 node_modules/@angular/cli/bin/ng build --prod",
        "ng-high-memory": "node --max_old_space_size=8000 node_modules/@angular/cli/bin/ng build --prod",

Ich habe für alle Projekte das gleiche Speicherlimit festgelegt, da ich weiß, dass sich Node in der Nähe des Limits anders verhält. Auf diese Weise sollten wir genauere Zahlen erhalten.

Ich musste den Bounds -Import von avatar.component.ts entfernen, da dies zu einem Buildfehler in NG7 führte. Es wurde nur als Typ verwendet, so dass es leicht zu entfernen war. Ich habe "target": "es2015" durch "target": "es5" in ./tsconfig.json . Dadurch wird die Differenzlast wie hier beschrieben deaktiviert. Ich weiß, dass dies ein wichtiger Bestandteil von CLI8-Anwendungen ist, aber wir prüfen bereits eine andere Implementierung, die nicht so viele Ressourcen erfordern sollte. Daher wollte ich sie nicht auch vergleichen. Auf diese Weise konnte ich meist gleiche Anwendungen vergleichen.

Ich habe festgestellt, dass Ihre package.json zwischen den beiden Versionen viele Pakete ändert, die nicht nur die Angular-Pakete sind. Dies könnte sich auf die Benchmarks auswirken. Nachdem ich versucht habe, Ihre ursprünglichen Zahlen zu reproduzieren, werde ich auch versuchen, nur Angular-Pakete zu ändern, um festzustellen, ob ich unterschiedliche Ergebnisse erhalte.

Entwicklungsumgebung

In Ihrer Reproduktion sagten Sie:

Dev Environment:
* Intel Nuc i7, 16 GB memory, SSD
* Windows 10

Benchmarking tool: Process Explorer

Ich verwende meine Arbeitsmaschine (Win10, i7, 16 GB RAM, SSD), die Ihrer Umgebung ähnlich zu sein scheint. Zum Benchmarking habe ich das unter https://github.com/filipesilva/angular-cli-perf-benchmark#benchmark -package erwähnte Tool verwendet. Ich benutze auch Node 10.16.0 und npm 6.9.0.

Ihre Testfälle

In Ihrer Reproduktion sagten Sie:

Test case 1:
* Node 10.15.3
* npm 6.4.0
* NG 7 and NG CLI 7

Node memory usage peak: 1.3 GB.

I read from the other post that the default limit of memory usage of Node is 1.5 GB. The "NG CLI" command apparently is using such default.


Test case 2:
* Node 10.15.3 / 10.16.0
* npm 6.4.0 / 6.10.0
* NG 8.1 and NG CLI 8.1

Memory usage peak in the DEBUG build: 3.6 GB / 3.5 GB
Memory usage peak in the Production build: 3.3 GB / 3.4 GB


Test case 3:
* Locally installed Node 12.6 through "npm i"
* npm 6.9.0
* NG 8.1 and NG CLI 8.1

Memory usage peak: 5.5 GB

Ich werde Test case 3 nicht wirklich ausprobieren, da wir bereits wissen, dass Knoten 12 im Allgemeinen mehr Speicher verwendet (https://github.com/nodejs/node/issues/28205). Ich glaube nicht, dass wir viel dagegen tun können.

Ihr Test case 1 ist das CLI7/NG7/NG7deps -Szenario. Ich sage auch NG7deps, weil sich diese Abhängigkeiten von Ihrem NG8-Projekt unterscheiden, von dem ich sagen werde, dass es NG8deps hat. Später könnte das einen Unterschied machen. Im Idealfall würden wir nur CLIx / NGx ändern, um Zahlen zu erhalten.

Also für CLI7/NG7/NG7deps (dein Test case 1 ) habe ich:

$ ng version

Angular CLI: 7.3.9
Node: 10.16.0
OS: win32 x64
Angular: 7.2.15
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, platform-server
... router, service-worker

Package                            Version
------------------------------------------------------------
@angular-devkit/architect          0.13.9
@angular-devkit/build-angular      0.13.9
@angular-devkit/build-optimizer    0.13.9
@angular-devkit/build-webpack      0.13.9
@angular-devkit/core               7.3.3
@angular-devkit/schematics         7.3.3
@angular/cdk                       7.3.3
@angular/cli                       7.3.9
@angular/flex-layout               7.0.0-beta.24
@angular/material                  7.3.3
@angular/material-moment-adapter   7.3.3
@angular/pwa                       0.13.3
@ngtools/webpack                   7.3.9
@schematics/angular                7.3.3
@schematics/update                 0.13.9
rxjs                               6.5.2
typescript                         3.2.2
webpack                            4.29.0

[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   node --max_old_space_size=8000 node_modules/@angular/cli/bin/ng build --prod (at D:\sandbox\memory-debug\testngcli8\NG7Source)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 288429.80 ms (297613.00, 292811.00, 282489.00, 284134.00, 285102.00)
[benchmark]   Average Process usage: 2.65 process(es) (2.60, 2.69, 2.66, 2.64, 2.64)
[benchmark]   Peak Process usage: 8.00 process(es) (8.00, 8.00, 8.00, 8.00, 8.00)
[benchmark]   Average CPU usage: 15.64 % (14.82, 16.84, 15.28, 15.27, 16.00)
[benchmark]   Peak CPU usage: 252.80 % (251.60, 300.00, 224.90, 261.00, 226.50)
[benchmark]   Average Memory usage: 1932.92 MB (1885.25, 1947.53, 1937.02, 1953.46, 1941.31)
[benchmark]   Peak Memory usage: 4024.00 MB (4115.83, 4092.19, 3943.85, 4018.98, 3949.16)



md5-d28c1dffbd11703a041dffc7b6a73087



$ ng version

Angular CLI: 8.1.0
Node: 10.16.0
OS: win32 x64
Angular: 8.1.0
... animations, cli, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, platform-server
... router, service-worker

Package                            Version
------------------------------------------------------------
@angular-devkit/architect          0.801.0
@angular-devkit/build-angular      0.801.0
@angular-devkit/build-optimizer    0.801.0
@angular-devkit/build-webpack      0.801.0
@angular-devkit/core               8.1.0
@angular-devkit/schematics         8.1.0
@angular/cdk                       8.0.2
@angular/flex-layout               8.0.0-beta.26
@angular/material                  8.0.2
@angular/material-moment-adapter   8.0.2
@angular/pwa                       0.801.0
@ngtools/webpack                   8.1.0
@schematics/angular                8.1.0
@schematics/update                 0.801.0
rxjs                               6.5.2
typescript                         3.4.5
webpack                            4.35.2



md5-1c09c7c9efd6bc8f010d05171d767994



[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   node --max_old_space_size=8000 node_modules/@angular/cli/bin/ng build --prod (at D:\sandbox\memory-debug\testngcli8\NG8Source)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 253091.40 ms (281761.00, 251054.00, 242851.00, 244676.00, 245115.00)
[benchmark]   Average Process usage: 2.72 process(es) (3.34, 2.52, 2.61, 2.58, 2.54)
[benchmark]   Peak Process usage: 8.80 process(es) (12.00, 8.00, 8.00, 8.00, 8.00)
[benchmark]   Average CPU usage: 12.94 % (15.28, 12.50, 12.20, 12.55, 12.18)
[benchmark]   Peak CPU usage: 210.62 % (223.50, 287.50, 173.50, 189.00, 179.60)
[benchmark]   Average Memory usage: 1997.28 MB (1980.34, 1920.54, 2051.03, 2025.27, 2009.23)
[benchmark]   Peak Memory usage: 4313.95 MB (4445.09, 4162.86, 4258.15, 4380.61, 4323.05)



md5-3ac01d1544d6859e233401c87995acf5



[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   node --max_old_space_size=8000 node_modules/@angular/cli/bin/ng build --prod (at D:\sandbox\memory-debug\testngcli8\NG8Source)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 184542.00 ms (240928.00, 167820.00, 169525.00, 176387.00, 168050.00)
[benchmark]   Average Process usage: 1.31 process(es) (2.57, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Peak Process usage: 2.40 process(es) (8.00, 1.00, 1.00, 1.00, 1.00)
[benchmark]   Average CPU usage: 11.67 % (11.08, 11.67, 11.74, 12.13, 11.73)
[benchmark]   Peak CPU usage: 173.76 % (268.80, 187.50, 167.20, 121.90, 123.40)
[benchmark]   Average Memory usage: 1569.17 MB (1997.59, 1421.48, 1607.34, 1424.31, 1395.14)
[benchmark]   Peak Memory usage: 2788.43 MB (4277.19, 2291.22, 2705.78, 2327.46, 2340.52)



md5-6a4dedbb221c789a67d1ba9659725dc1



[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   node --max_old_space_size=8000 node_modules/@angular/cli/bin/ng build --prod (at D:\sandbox\memory-debug\testngcli8\NG8Source)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 448765.60 ms (450442.00, 441786.00, 453261.00, 442406.00, 455933.00)
[benchmark]   Average Process usage: 2.62 process(es) (2.63, 2.62, 2.65, 2.61, 2.61)
[benchmark]   Peak Process usage: 8.00 process(es) (8.00, 8.00, 8.00, 8.00, 8.00)
[benchmark]   Average CPU usage: 11.07 % (11.65, 11.65, 11.10, 10.18, 10.78)
[benchmark]   Peak CPU usage: 280.28 % (307.70, 356.30, 237.40, 256.20, 243.80)
[benchmark]   Average Memory usage: 2484.00 MB (2467.08, 2548.74, 2480.70, 2471.22, 2452.25)
[benchmark]   Peak Memory usage: 5050.35 MB (5043.85, 5075.19, 5051.67, 5053.34, 5027.68)



md5-b0ecc6954a8df79193416e981408ff5e



[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   node --max_old_space_size=8000 node_modules/@angular/cli/bin/ng build --prod (at D:\sandbox\memory-debug\testngcli8\NG8Source)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 246739.80 ms (222235.00, 246069.00, 244327.00, 252636.00, 268432.00)
[benchmark]   Average Process usage: 2.55 process(es) (2.55, 2.59, 2.58, 2.56, 2.46)
[benchmark]   Peak Process usage: 8.00 process(es) (8.00, 8.00, 8.00, 8.00, 8.00)
[benchmark]   Average CPU usage: 12.83 % (11.53, 12.41, 12.92, 13.34, 13.97)
[benchmark]   Peak CPU usage: 229.42 % (287.40, 268.90, 197.00, 212.50, 181.30)
[benchmark]   Average Memory usage: 1947.94 MB (1941.51, 2076.98, 1938.72, 1926.15, 1856.36)
[benchmark]   Peak Memory usage: 4129.88 MB (4141.96, 4347.47, 4064.12, 4071.99, 4023.87)

Dies scheint sich nicht sehr vom ES5-Benchmark zu unterscheiden. @ alex88 Vielleicht haben Sie bei Verwendung von es2015 tatsächlich die DL-Builds erhalten? Sie sollten Node 12 wegen https://github.com/nodejs/node/issues/28205 vorerst auch nicht verwenden

@zijianhuang Zum Abschluss denke ich, dass Ihr Projekt mit NG8 / CLI8 mehr Ressourcen verbraucht als mit NG7 / CLI7, weil DL aktiviert war und einige Builds ohne Cache waren. Ich kann mir des zweiten Punktes wirklich nicht sicher sein, weil ich nicht weiß, wie Sie Dinge lokal und in CI zwischenspeichern, aber die Zahlen, die ich hier habe, scheinen darauf hinzuweisen.

Für uns bedeutet die Untersuchung des Übergangs Ihres Projekts von Angular Version 7 zu 8, dass wir wirklich herausfinden müssen, welcher Speicher zwischen DL-Builds erhalten bleibt, da dies auf ein Leck hinweist, und dass wir ein leistungsfähigeres DL-Setup benötigen ( @clydin hat einige Ideen dazu).

Hallo @filipesilva , ich habe vor

@jsgoupil in https://github.com/angular/angular-cli/issues/13734#issuecomment -506760767 Ich habe gesehen, dass in der AOT-Kompilierung mindestens 240 MB und maximal etwa 1 GB Speicher verwendet werden. Ich habe ein paar Tage lang versucht, genau herauszufinden, wo, aber nicht viel Erfolg hatte. Es gibt noch ein paar Dinge, die ich ausprobieren möchte. Und ich denke auch, dass das Minimum mit dem "Übertrag" -Speicher zusammenhängt, den ich bei DL-Builds sehe.

Davon abgesehen führt kein Weg daran vorbei, dass AOT viel mehr Arbeit leistet und mehr Ressourcen benötigt. Das ist kein Fehler. Es ist nur ein viel komplizierterer Build-Schritt. Es erfordert möglicherweise unverhältnismäßig mehr Ressourcen als Nicht-AOT, aber es wird niemals weniger erfordern.

Haben Sie die Endkommentare in https://github.com/angular/angular-cli/issues/13734#issuecomment -506760767 zu den Kompilierungseinheiten gesehen? Es kann sein, dass Ihre tsconfig viele Dateien enthält, die Sie nicht so gut verwenden, oder dass die Komponente sass größer ist als erwartet (wenn Sie sass verwenden).

Wenn Sie mir irgendwie Zugriff auf Ihren Code geben, kann ich nachsehen, ob ich etwas Seltsames finde.

@filipesilva , vielen Dank für diese detaillierte und inspirierende Analyse. Ich hatte einige geringfügige Änderungen an der Build-Konfiguration vorgenommen, von denen einige denen ähneln, die das CLI-Team während der Analyse vorgenommen hat. Ich hatte die Browserliste geändert:

    "browserslist": [
        "last 2 Chrome versions",
        "last 2 Safari versions",
        "last 2 Firefox versions",
        "not dead",
        "not IE 9-11"
    ],

um sicherzustellen, dass nur es2015 build produziert wird.

Für den DEBUG-Build beträgt die maximale Speichernutzung 1,9 GB.
Für den Production Build beträgt die maximale Speichernutzung 2,0 GB.

Dies ist tatsächlich ein kleiner Sprung von 1,3 GB im Vergleich zum Build mit NG7 / NG CLI 7, die ebenfalls nur den Build es2015 produzieren. Das Standard-Speicherlimit von 1,5 GB für Node ist die Gefahr, insgesamt ist der kleine Sprung jedoch angemessen. Ähnlich wie Sie analysiert hatten.

@jsgoupil meldete sich und ließ mich einen Blick auf sein Projekt werfen. Ich habe den Terser-Cache deaktiviert (beschrieben in https://github.com/angular/angular-cli/issues/13734#issuecomment-508815407) und den Befehl "ng build 3cconnect --prod" bewertet:

[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   ng build 3cconnect --prod (at D:\sandbox\memory-debug\jsgoupil)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 258795.40 ms (280888.00, 250100.00, 241312.00, 256762.00, 264915.00)
[benchmark]   Average Process usage: 3.40 process(es) (3.41, 3.39, 3.42, 3.41, 3.39)
[benchmark]   Peak Process usage: 8.00 process(es) (8.00, 8.00, 8.00, 8.00, 8.00)
[benchmark]   Average CPU usage: 11.59 % (13.45, 10.73, 10.52, 11.53, 11.75)
[benchmark]   Peak CPU usage: 236.56 % (237.60, 325.10, 168.60, 207.80, 243.70)
[benchmark]   Average Memory usage: 1523.76 MB (1547.40, 1471.40, 1544.40, 1562.83, 1492.76)
[benchmark]   Peak Memory usage: 2898.84 MB (2940.99, 2707.18, 2969.51, 3049.01, 2827.53)

Bei diesem Build sind AOT und Build Optimizer deaktiviert und es wird Differential Loading verwendet. Die durchschnittliche Speichernutzung ist ebenfalls maximal, was bedeutet, dass der Garbage Collector im Verlauf des Builds viel Arbeit leistet, um Speicher freizugeben.

Versuchte, AOT und Build Optimizer einzuschalten und bekam OOM beim zweiten DL-Build während TerserPlugin. Verwendete den Befehl node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng build 3cconnect --prod --aot --build-optimizer zum Erstellen und es war erfolgreich.

Der Benchmark für diesen Build zeigt die folgenden Zahlen:

$ benchmark -- node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng build 3cconnect --prod --aot --build-optimizer
[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng build 3cconnect --prod --aot --build-optimizer (at D:\sandbox\memory-debug\jsgoupil)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 571885.00 ms (567385.00, 558561.00, 574671.00, 572119.00, 586689.00)
[benchmark]   Average Process usage: 2.93 process(es) (2.84, 2.90, 3.02, 2.89, 3.02)
[benchmark]   Peak Process usage: 8.40 process(es) (8.00, 8.00, 9.00, 8.00, 9.00)
[benchmark]   Average CPU usage: 11.00 % (10.82, 11.15, 11.26, 10.87, 10.89)
[benchmark]   Peak CPU usage: 333.82 % (381.40, 243.80, 272.00, 342.10, 429.80)
[benchmark]   Average Memory usage: 2997.71 MB (3094.71, 2923.23, 2899.82, 2987.55, 3083.24)
[benchmark]   Peak Memory usage: 5613.08 MB (5643.63, 5567.17, 5615.44, 5592.79, 5646.38)

Ich habe es auch ohne aktivierten Build Optimizer versucht:

[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng build 3cconnect --prod --aot (at D:\sandbox\memory-debug\jsgoupil)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 395413.60 ms (396473.00, 384629.00, 401091.00, 396822.00, 398053.00)
[benchmark]   Average Process usage: 2.56 process(es) (2.61, 2.53, 2.53, 2.52, 2.62)
[benchmark]   Peak Process usage: 8.00 process(es) (8.00, 8.00, 8.00, 8.00, 8.00)
[benchmark]   Average CPU usage: 10.42 % (10.50, 9.93, 10.76, 10.58, 10.32)
[benchmark]   Peak CPU usage: 297.14 % (307.80, 251.40, 293.70, 376.60, 256.20)
[benchmark]   Average Memory usage: 2483.32 MB (2481.63, 2471.55, 2518.96, 2451.15, 2493.35)
[benchmark]   Peak Memory usage: 5238.84 MB (5221.19, 5212.36, 5368.60, 5184.88, 5207.16)

Ich hatte nicht erwartet, dass Build Optimizer die durchschnittliche oder maximale Speichernutzung so stark beeinflusst. 500mb ist ein gutes Stück. Wir haben bereits nach einer Möglichkeit gesucht, die Anzahl der verarbeiteten Dateien in https://github.com/angular/angular-cli/pull/14998 zu reduzieren, um die Auswirkungen zu verringern.

Diese Zahlen sehen viel höher aus als die ursprünglichen, aber denken Sie daran, dass wir den Speicher von 1,4 GB Standard auf etwa 8 GB erhöht haben. Dies bedeutet, dass der Garbage Collector nicht so viel Druck ausübt, um Speicher freizugeben, sodass die Dinge länger im Speicher bleiben. Zum Vergleich hier der erste Build (ohne AOT oder Build Optimizer) mit einem erhöhten Speicherlimit:

$ benchmark -- node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng build 3cconnect --prod
[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng build 3cconnect --prod (at D:\sandbox\memory-debug\jsgoupil) 
[benchmark] Process Stats
[benchmark]   Elapsed Time: 253524.00 ms (256206.00, 245034.00, 245636.00, 243953.00, 276791.00)
[benchmark]   Average Process usage: 3.44 process(es) (3.41, 3.45, 3.45, 3.46, 3.42)
[benchmark]   Peak Process usage: 8.00 process(es) (8.00, 8.00, 8.00, 8.00, 8.00)
[benchmark]   Average CPU usage: 11.65 % (12.18, 10.84, 11.67, 11.01, 12.55)
[benchmark]   Peak CPU usage: 200.90 % (200.00, 168.70, 231.20, 217.10, 187.50)
[benchmark]   Average Memory usage: 1972.97 MB (2010.47, 1927.40, 2014.74, 1939.05, 1973.17)
[benchmark]   Peak Memory usage: 3871.67 MB (3942.59, 3815.74, 3944.29, 3851.58, 3804.13)

Wenn Sie also dasselbe hohe Speicherlimit verwenden, erhöht das Hinzufügen von AOT und Build Optimizer die durchschnittliche Speichernutzung um 1 GB und die maximale Speichernutzung um 1,8 GB.

Mit nur AOT wurde die Erstellungszeit um 70% (250-> 400 s), die durchschnittliche Speichernutzung um 25% (2000-> 2500) und die maximale Speicherauslastung um 36% (3800-> 5200 mb) erhöht. Durch Hinzufügen von BO wurde die Erstellungszeit um 42% (400-> 570 s), die durchschnittliche Speichernutzung um 20% (2500-> 3000) und die maximale Speichernutzung um 7% (5200-> 5600 mb) erhöht.

Ich habe auch versucht, das differentielle Laden zu deaktivieren, indem ich "target": "es5", in ./tsconfig.json während AOT und Build Optimizer beibehalten wurden:

[benchmark] Benchmarking process over 5 iterations, with up to 5 retries.
[benchmark]   node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng build 3cconnect --prod --aot --build-optimizer (at D:\sandbox\memory-debug\jsgoupil)
[benchmark] Process Stats
[benchmark]   Elapsed Time: 332036.80 ms (291110.00, 303767.00, 297923.00, 395777.00, 371607.00)
[benchmark]   Average Process usage: 2.87 process(es) (2.89, 2.86, 2.87, 2.86, 2.85)
[benchmark]   Peak Process usage: 8.00 process(es) (8.00, 8.00, 8.00, 8.00, 8.00)
[benchmark]   Average CPU usage: 12.42 % (10.63, 11.52, 11.41, 14.30, 14.21)
[benchmark]   Peak CPU usage: 283.98 % (250.00, 237.40, 414.00, 207.70, 310.80)
[benchmark]   Average Memory usage: 2496.03 MB (2555.55, 2533.63, 2524.99, 2409.38, 2456.62)
[benchmark]   Peak Memory usage: 5084.00 MB (5386.41, 5283.17, 5257.22, 4586.35, 4906.83)

Ohne DL beträgt der verwendete Speicher ca. 500 MB, ähnlich wie bei https://github.com/angular/angular-cli/issues/13734#issuecomment -508815407. Wir wollen das verbessern.

Ich habe versucht herauszufinden, wie groß das Projekt war, indem ich Dateien in src/ nach Erweiterung aufgelistet habe:

$ find -type f | sed -e 's/.*\.//' | sort | uniq -c
      3 eot
      7 gif  
    478 html 
      1 ico  
      2 jpg  
      4 json 
     51 png  
      1 ps1  
    273 scss 
    470 svg  
   1302 ts   
      1 txt  
      3 woff 
      9 woff2
      1 xml  

Dies schließt keine Bibliotheken von Drittanbietern ein, sodass wir nicht viel über die Gesamtgröße der Kompilierung erfahren. Aber ich bin nicht überrascht, dass für dieses Projekt das Speicherlimit erhöht werden muss. Es gibt hier viele TS-Dateien. Ich habe es mir angesehen

@jsgoupil in https://github.com/angular/angular-cli/issues/13734#issuecomment -497365534 Sie haben erwähnt, dass ein Azure-Computer mit 7 GB die App nicht erstellen konnte, was ich seltsam finde, weil 5,6 GB das Maximum I waren sah auf meinem Windows-Computer.

Vielleicht verwendet die CI-Maschine bereits 1,4 GB? Das würde Sinn machen. Sie können wahrscheinlich überprüfen, wie viel Speicher der Computer vor dem Build hat. Sie sagten aber auch, dass die Maschine nur 7 GB hat und Sie --max_old_space_size=8192 . Ich bin mir nicht sicher, wie sich Node verhält, wenn Sie sagen, dass er mehr Speicher belegen sollte, als tatsächlich verfügbar ist. Ich frage mich also, ob das ein Problem ist: Sie geben ihm ein größeres Limit als verfügbar, sodass er denkt, dass er den gesamten Speicher zuweisen kann, aber wenn er benötigt wird, hat das System ihn nicht, sodass Sie einen Fehler erhalten. Sie sagen in https://github.com/angular/angular-cli/issues/13734#issuecomment -497426391, dass der Fehler mit und ohne Flag unterschiedlich ist, sodass auf ein anderes Problem hingewiesen wird. Überprüfen Sie möglicherweise, wie viel Speicher frei ist, und legen Sie ein darunter liegendes Limit fest, z. B. 5000 oder 6000.

Unabhängig von dem von Ihnen erwähnten Azure-Computer ist es beeindruckend (negativ), dass die AOT-Kompilierung die Speichernutzung um durchschnittlich 1 GB / 1,8 GB Spitzenwert erhöht. Dies ist etwas, das wir im allgemeinen Fall betrachten. Ich denke, in Ihrem Projekt ist es wirklich nur eine Funktion der Anzahl der TS-Quelldateien, die eine AOT-Kompilierung benötigen. Ich habe versucht, ein Profil der Speichernutzung zu erstellen, und es sah meistens so aus wie die anderen, die ich mir zuvor aus anderen Projekten angesehen habe.

Mir ist auch aufgefallen, dass Sie einige seltsame Importe in ../../../node_modules/@angular/core anstatt nur in @angular/core und ähnlich wie in RxJs. Ich denke, das macht keinen Unterschied, da die Auflösung dort immer noch die package.json . Aber ich fand es seltsam.

Wenn Ihre Anwendung beim Erstellen von SCSS-Dateien abstürzt und versucht, diese Abhängigkeiten Node-Sass, Style-Loader und Sass-Loader zu installieren, hat dies bei mir funktioniert!

Ich weiß nicht, ob dies interessante Informationen sind oder nicht, aber ich hatte viele Probleme mit Versionen von @angular-devkit/build-angular neuer als 0.800.2 für den Travis Build waren und kürzlich den gleichen Fehler wie oben verursachten. Das Zurücksetzen auf 0.800.2 das Problem behoben.

https://travis-ci.org/johannesjo/super-productivity/builds

das gleiche Problem auf Ubuntu Server 18.04, aber dies löste mein Problem:
node --max_old_space_size = 8192 node_modules / @ angle / cli / bin / ng build --prod

Lassen Sie dies hier einfach fallen, aber wenn jemand AWS Codebuild verwendet, stellen Sie sicher, dass Ihre Build-Umgebung so aktualisiert wird, dass sie mit mehr als mindestens 3 GB Arbeitsspeicher konfiguriert wird. Ich habe die obigen Schritte ausgeführt, musste jedoch meine Umgebung mit mehr Arbeitsspeicher neu konfigurieren.

In meinem Fall war die Neukonfiguration der CodeBuild-Umgebung für die Verwendung von mehr als 3 GB (ich wähle 15 GB) ausreichend, um das Problem zu beheben. Ich musste die Speichereinstellungen im Knoten nicht ändern.

@ThomasEg , welche Umgebung haben Sie, sodass Sie die Speichereinstellungen im Knoten nicht ändern mussten?

Meins ist Windows 10 mit 16 GB Speicher, und das Ändern der Einstellungen für max_old_space_size des Knotens löst das Problem:
node --max_old_space_size=8192 "node_modules/@angular/cli/bin/ng" build --configuration=production

während der Knoten tatsächlich 2 GB Speicher verwendete.

Ich würde vermuten, dass Ihre CodeBuild-Umgebung dem Knoten tatsächlich max_old_space_size hinter dem Sinn gibt, während ng build anscheinend nicht max_old_space_size für den Knoten liest. Können Sie das bestätigen?

@JohannesHoppe Ich bin mir nicht sicher, welchen Zweig / welche Builds ich mir dort

Ich habe versucht herauszufinden, ob es in DL-Builds (Differential Loading) wirklich einen Speicherverlust gibt. Unten sind meine Notizen.

TLDR ist, dass es keinen Speicherverlust in DL zu geben scheint, aber wenn --max_old_space_size verwendet wird, behält V8 den Speicher bei. Ein Build kann ohne Fehler mit --max_old_space_size=300 werden, benötigt jedoch bis zu 2500 MB Speicher, wenn --max_old_space_size=10000 .

Der Versuch herauszufinden, ob DL wirklich endlos Speicher stapelt. Ein DL-Build wurde geändert, um die Einträge in webpack-browser-config.js zu verdoppeln. Normale (2) Builds verwenden 480 Durchschnitt / 960 Peak, 4 Builds sind 810/1700, 8 Builds sind 1400/2500. So erhöht jeder Build Blätter durchschnittlich um 200ish.

Ich verstehe nicht ganz, warum der Peak auch so stark ansteigt. Peak sollte durchschnittlich sein + etwas ... richtig? Eigentlich ist das falsch. Weil wir bereits wissen, dass die Nutzung im Laufe der Zeit zunimmt. Der Durchschnitt während des ersten Builds ist also viel kleiner als der Durchschnitt während des letzten Builds. Ein bisschen wie ein Integral. Die Zahl, um die ich mich wirklich kümmern sollte, ist also die Spitze, weil sie die Dinge für den Multi-Build-Fall besser darstellt.

Es wurde auch festgestellt, dass process.memoryUsage (). HeapUsed mir Zahlen gab, die viel niedriger waren als die, die ich im Task-Manager sah. Ich fand das seltsam. Ich habe auch den Terser-Cache nicht deaktiviert. Ich sollte das tun, um zu sehen, ob es dort auch Skalierungskosten gibt, nachdem ich diese anfänglichen Skalierungskosten herausgefunden habe.

Es wurde versucht, alle 30 Sekunden global.gc auszuführen, um herauszufinden, ob der Speicher wirklich erhalten blieb oder ob der Knoten mit dem 10-GB-Limit nur sehr zufrieden war. Habe es über 5 Iterationen gemacht. Ohne GC bekam ich 1200/2150, mit GC bekam ich 1200/2050. Also nur ein etwas kleinerer Peak. Dies zeigt, dass der Speicher nicht freigegeben werden kann.

Hat alle 30s Heap-Profile und Heap-Snapshots erstellt. Habe auch das Speicherleckprofil auf Chrome Devtools ausprobiert. Die Heap-Profile zeigen fast keine Änderung zwischen ihnen. Sehr komisch. Vielleicht muss ich den Profiler zwischen den Samples neu starten? Die Snapshots können ebenfalls nicht geladen werden, mit einem Fehler beim Erstellen von Retainern. Wird sie neu machen.

Versuchte erneut die Profilerstellung mit einem niedrigeren Abtastintervall und sah nichts anderes. Alle Schnappschüsse bis auf den ersten sind mit derselben Meldung fehlgeschlagen. Ich habe auch versucht, am Ende nur einen Schnappschuss zu machen und habe nur einen kleinen Schnappschuss (200 MB) erhalten.

Es wurde versucht, während des 8. (und letzten) Builds manuell einen Snapshot in Chrome Devtools zu erstellen. Devtools sagte, der Prozess habe ~ 2000 MB Speicher verwendet, kurz bevor ich den Schnappschuss gemacht habe, und dann wurden nur ~ 260 MB angezeigt. Der Schnappschuss war nur 254mb.

Also dachte ich, es könnte eine GC-Sache sein. Es wurde versucht, max_old_space_size auf 1 GB zu beschränken, und es wurde noch erstellt. Ebenfalls mit 600 MB und 400 MB erstellt, jedoch mit 300 und 200 fehlgeschlagen. Ein einzelner Build-Lauf schlug mit 200 fehl, war jedoch mit 300 erfolgreich. Ein Standard-DL-Build schlug auch mit 300 fehl.

Soweit ich das beurteilen kann, wird aufgrund von DL nicht wirklich viel Speicher gespeichert. Vielleicht gibt es zu 100 zusätzliche MB. Eine neue App verwendet ungefähr denselben Speicher (~ 300 MB im Hauptprozess plus bis zu 450 MB bei erzeugten Terser-Prozessen), um 1 Build oder 8 Builds mit demselben Befehl zu erstellen. Wenn ich jedoch das Speicherlimit auf eine sehr große Zahl (10 GB) setze, bleibt mehr Speicher (bis zu 2,5 GB) erhalten, bis es freigegeben werden muss.

@filipesilva
Hier sind die Protokolle für fehlgeschlagene Builds:
https://travis-ci.org/johannesjo/super-productivity/jobs/556566074
Ich denke, Schlüssel sind die unbeabsichtigten Änderungen an der package-lock.json, die hier vorgenommen wurden:
https://github.com/johannesjo/super-productivity/commit/807a760d7d7cb9f18e706422a9f8f02af30342de

Und es gibt den Build für das Commit, der das Problem behoben hat, und das Commit selbst:
https://github.com/johannesjo/super-productivity/commit/5e6b7aaf234dbac286549a6ac74957ba15589cd8
https://travis-ci.org/johannesjo/super-productivity/jobs/557364217

(Auch du hast wieder den armen JohannesHoppe anstelle von mir erwähnt :))

Wir hatten das gleiche Problem. Es stellte sich heraus, dass wir die Basis-SCSS-Dateien in die meisten unserer Komponenten importiert haben. Das war nicht wirklich notwendig.
Jetzt, ohne die Option max-old-space-size Node zu setzen, konnten wir unsere Apps ohne Fehler im Produktionsmodus erstellen, nachdem wir die Kerndateiimporte in unsere Komponenten entfernt hatten, wo dies nicht erforderlich war.

Wir haben auch mit npm install -DE node-sass von Dart-Sass zu Node-Sass gewechselt und das hat auch funktioniert, ohne etwas zu ändern.

Unter meiner Umgebung. Vielleicht hilft das :)

     _                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/


Angular CLI: 8.1.1
Node: 10.16.0
OS: darwin x64
Angular: 8.1.1
... animations, cli, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... platform-server, router

Package                                    Version
--------------------------------------------------------------------
@angular-devkit/architect                  0.800.1
@angular-devkit/build-angular              0.801.1
@angular-devkit/build-optimizer            0.801.1
@angular-devkit/build-webpack              0.801.1
@angular-devkit/core                       8.0.6
@angular-devkit/schematics                 8.0.1
@angular/cdk                               8.0.2
@angular/flex-layout                       8.0.0-beta.26
@angular/material                          8.0.2
@ngtools/webpack                           8.1.1
@nguniversal/express-engine                8.1.1
@nguniversal/module-map-ngfactory-loader   8.1.1
@schematics/angular                        8.0.1
@schematics/update                         0.801.1
rxjs                                       6.5.2
typescript                                 3.4.5
webpack                                    4.35.2

@filipesilva Ich bezweifle, dass es irgendetwas mit differenziellem Laden zu auch ohne DL setzen. In Angular 7 oder niedriger (wir haben auch "@angular-devkit/build-angular" < "~0.800.2" ) hatten wir es auf 2048 gesetzt.

Beim Aufrufen von "ng serve" mit einer benutzerdefinierten Konfiguration ist genau dasselbe Problem aufgetreten:

npm run env -s && ng serve --aot --configuration alpha

Wenn Sie nur loslegen möchten, haben Sie die Flags "buildOptimizer" und "Optimization" in meiner Konfiguration auf "false" gesetzt, und ich konnte innerhalb von Sekunden erstellen.

@CodeEpiphany , ich wusste, dass ich wusste, dass eine solche Konfiguration für eine schnellere Build-Zeit und wahrscheinlich einen geringeren Build-Speicherverbrauch ein Handel für eine größere Build-Ausgabe und eine langsamere Laufzeitleistung ist, jedoch den Punkt des im OP erwähnten Problems verfehlt.

Ich habe das zuerst mit Dart-Sass erlebt. Wir haben es geschafft, all diese SCSS-Probleme zu beheben, die Dart-Sass hatte. Es geschah jetzt mit einer meiner Apps, die das sourceMaps-Objekt verwendeten. Das Setzen von sourceMaps auf false hat mein Problem behoben

Ich hatte das gleiche Problem mit Angular 8. Windows 10
Ich denke, verschiedene Leute haben diese Probleme aus verschiedenen Gründen.

Meine Lösung war:

node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod

Nun gibt es wieder zwei Dinge: Entweder hat es aufgrund von max_old_space_size = 8192 funktioniert oder es kann daran liegen, dass es eine unterschiedliche lokale und globale Winkelversion gibt. und mit dem obigen Befehl wurde die lokale / gleiche Version von ng verwendet

Ich habe eine relativ kleine App, vielleicht 24 Komponenten, einschließlich Routen, Modalitäten und einige Klassen für die Statusverwaltung usw. Und auf einem 16-GB-Computer besteht trotz aller hier veröffentlichten Vorschläge eine 3/4 Chance, dass sie getroffen wird dieser Fehler. Ich verstehe nicht, wie es so viel Speicher verbrauchen kann und verstehe wirklich nicht, warum es nicht zumindest versucht, es auf die SSD zu übertragen (sicher, es wäre langsam, aber wenn es überhaupt nicht erstellt wird , in 10 Minuten zu bauen, 10x die alte Bauzeit, das ist immer noch ziemlich gut).

Dies ist mit deaktivierten Quellkarten, Knoten, der die Einstellung max_old_space_size erhält, buildOptimizer deaktiviert, Optimierung deaktiviert.

Vor 3 Versionen konnte dieselbe App mit einem 3-GB-Computer erstellt werden. Sollte ich wirklich alles auf Angular 5 zurücksetzen oder bin ich besser dran, einfach auf Vue umzusteigen?

@Senneseph Was ist deine Knotenversion? Versuchen Sie Knoten 10 statt 12

@maxisam Ich bin auf 10.x, bis AWS eine neuere Version verwendet oder eine benutzerdefinierte Lambda-Ebene erstellt. Dies sollte jedoch laut Dokumentation auf 8.9+ funktionieren.

Von https://www.npmjs.com/package/@angular/cli

Sowohl die CLI als auch das generierte Projekt weisen Abhängigkeiten auf, für die Knoten 8.9 oder höher sowie NPM 5.5.1 oder höher erforderlich sind.

Ich wollte hier eine Beschimpfung hinzufügen, aber ich werde sie nur an die Chefs mit der Bitte senden, die Frameworks zu wechseln. Es scheint, dass dieses Projekt nur im totalen Chaos ist.

Hier ist etwas, das Spaß macht (8.1.3):

npm install -g @ angle / cli
ng neues Projekt erstellen
CD neues Projekt
ng Update
"rxjs 6.4.0 -> 6.5.2 ng update rxjs"

Warum erfordert ein brandneues Projekt bereits ein Paket-Update? 6.4.0 war im Januar 6.5.2 war im Mai.

Angular CLI https://github.com/angular/angular-cli/blob/cae4a9dc4afb53292cb44ebbc644d33b7d8d159e/packages/schematics/angular/utility/latest-versions.ts

RxJs: '~ 6.4.0',

Angular https://github.com/angular/angular/blob/master/package.json

"rxjs": "^6.4.0",

@Senneseph Alter, die Leute hier versuchen immer noch, das

Ich habe ein Projekt mit mehr als 100 Komponenten mit Tonnen von ngrx-Klassen und -Diensten.

Mein Build-Server befindet sich auf Knoten v12 mit ziemlich durchschnittlicher Hardware.

für es2015

Datum: 2019-07-18T13: 21: 52.536Z - Hash: 9ba50a50277fc3c9fc2e - Zeit: 54734 ms
für es5
Datum: 2019-07-18T13: 23: 12.900Z - Hash: 93e6713a4d03978a67fd - Zeit: 80111ms

Es dauert etwas länger als v7, aber es ist nichts Verrücktes.

Ich habe meinen lokalen Entwicklungscomputer am ersten Tag meines Upgrades auf V8 wieder auf Knoten v10 umgestellt, aber ich habe nichts unternommen, um einen Server zu erstellen, da ich zuversichtlich bin, dass das CLI-Team dies herausfinden wird.

Hier ist ein Ort, an dem Menschen an Themen arbeiten können, nicht ein Ort, an dem sie sich austoben können.

Ich weiß nicht einmal, was mit dem Update falsch ist? Bei rxjs gibt es keine Änderung von 6.4.0 auf 6.5.2.

@ Maxisam

Ich schätze auf jeden Fall die harte Arbeit aller. Ich habe mich anfangs für Angular entschieden, weil es das am besten organisierte und ganzheitlich durchdachte Projekt zu sein schien.

Es geht nicht darum, ob die Leute hart daran arbeiten, dieses Problem zu lösen. Das Problem ist, dass es hätte gelöst werden müssen, bevor es veröffentlicht und für die öffentliche Nutzung erklärt wurde.

Was das rxjs-Ding betrifft, sollte es keine bahnbrechenden Änderungen zwischen den Versionen geben. Das Problem ist, dass die Kommentare lauten: "// Diese Versionen sollten mit den neuesten Angular-Peer-Abhängigkeiten auf dem neuesten Stand gehalten werden." und doch gibt jemand einfach alles ein, was er will, anstatt ein Skript auszuführen, um die genaue Zeichenfolge zu extrahieren. Und dann hat niemand getestet, ob es wie beabsichtigt funktioniert hat.

Ich stelle mir vor, dass das Angular-Team zu dünn ist.

@Senneseph

Das Problem ist, dass es hätte gelöst werden müssen, bevor es veröffentlicht und für die öffentliche Nutzung erklärt wurde.

Sie wissen, dass dies BS ist, oder? Es gibt keinen Bug-Patch für Vue oder React?

IMHO ist V8 fertig. Ich habe es für eine Weile benutzt. Dieses Problem hält nicht wirklich alle auf. Niemand in unserem Team (5+) hat dieses Problem. Wir haben 10ish-Projekte mit Angular 7/8 mit AOT und Build Optimizer.

Wir sehen das Problem mit der Erstellungszeit, aber nichts hindert uns daran, zu erstellen.

Haben Sie versucht, Node-Sass, Style-Loader und Sass-Loader zu installieren? (Meins funktioniert so oder so, aber du solltest es versuchen.)

Bitte halten Sie die Diskussion zum Thema und überprüfen Sie den Verhaltenskodex auf Verhalten.

https://github.com/angular/code-of-conduct/blob/master/CODE_OF_CONDUCT.md

@ Maxisam

Vielen Dank für den Vorschlag zu Sass, aber ich verwende einfaches CSS, das in einem eigenen Projekt erstellt wurde. Ich habe es vorher nicht erwähnt, weil die Frage, ob dies mit einfachem CSS geschah, bereits beantwortet zu sein scheint.

@ Lenneseph Gibt es eine Chance, dass ich dieses Projekt sehen kann? Ich denke nicht, dass ein 24-Komponenten-Projekt 16 GB Speicher verwenden sollte. Ich habe kein Projekt gesehen, das wirklich so viel Speicher benötigt

Es gab ein schwerwiegendes, aber seltenes Problem mit Typoskript 3.4 (https://github.com/microsoft/TypeScript/issues/30050), das in einigen Fällen dazu führte, dass bei Union-Typen viel zusätzlicher Speicher verwendet wurde. Wir haben gerade die Unterstützung für TS 3.5 in Angular 8.2.0 mit @angular-devkit/[email protected] . Dies könnte sich auf Ihr Projekt auswirken. Sie können versuchen, auf diese Versionen zu aktualisieren, um festzustellen, ob dies hilfreich ist.

Danke @filipesilva . Leider kann ich keinen Zugriff auf das Projekt selbst gewähren. Ich werde die von Ihnen empfohlene @ angle-devkit / build-angle-Version ausprobieren und berichten, wie es in einer Woche oder so funktioniert.

Ich habe zwar nicht viele Komponenten, aber sie sind ziemlich abstrakt. Und obwohl ich den Operator keyof direkt verwende, definiere ich einen Typ, der eine Vereinigung von ungefähr 19 Typen darstellt. Vielleicht habe ich irgendwo diesen Typ auf eine schlechte Weise mit einem anderen kombiniert, so dass der tsc explodiert, wenn er versucht, eine Normalisierung durchzuführen.

(Wenn dies der Grund ist, warum meine eckige App in Desktop-Browsern normal ist, aber fast nicht reagiert, wenn reaktive Formulare auf der Seite angezeigt werden, bin ich sehr glücklich. Aus irgendeinem Grund hat nur Opera Mobile die gleiche Reaktionsfähigkeit / CPU-Auslastung wie Desktop Browser.)

Letzte Woche, nachdem ein relativ kleiner Zweig mit dem Hauptzweig zusammengeführt wurde, trat bei der Erstellung meines Projekts dieses hier gemeldete Speicherproblem auf. Der interessante Teil ist, dass das Problem nur auf dem CI-Server auftrat, keiner der Entwickler hatte Probleme vor Ort, selbst mit --prod .

Nachdem ich den obigen Kommentar von hatte , entschied ich mich,

$ ng update @angular/cli @angular/core
Using package manager: 'npm'
Collecting installed dependencies...
Found 60 dependencies.
Fetching dependency metadata from registry...
    Updating package.json with dependency @angular/cli @ "8.2.1" (was "8.1.2")...
    Updating package.json with dependency @angular/core @ "8.2.1" (was "8.1.2")...
    Updating package.json with dependency @angular/animations @ "8.2.1" (was "8.1.2")...
    Updating package.json with dependency @angular/compiler-cli @ "8.2.1" (was "8.1.2")...
    Updating package.json with dependency @angular/language-service @ "8.2.1" (was "8.1.2")...
    Updating package.json with dependency @angular/router @ "8.2.1" (was "8.1.2")...
    Updating package.json with dependency @angular/forms @ "8.2.1" (was "8.1.2")...
    Updating package.json with dependency @angular/common @ "8.2.1" (was "8.1.2")...
    Updating package.json with dependency @angular/platform-browser-dynamic @ "8.2.1" (was "8.1.2")...
    Updating package.json with dependency @angular-devkit/build-angular @ "0.802.1" (was "0.801.2")...
    Updating package.json with dependency @angular/compiler @ "8.2.1" (was "8.1.2")...
    Updating package.json with dependency @angular/platform-browser @ "8.2.1" (was "8.1.2")...
    Updating package.json with dependency typescript @ "3.5.3" (was "3.4.5")...
UPDATE package.json (2341 bytes)

Das Problem ist jetzt behoben!

Mein Eindruck ist, dass der zusätzliche Speicher, der für DL-Dual-Builds benötigt wird, sowie die Tatsache, dass Typoskript auf 3.4 erhöht wurde, was die oben genannten Probleme in Bezug auf Randfälle vom Typ Union aufweist, bei einigen Projekten zu diesem zusätzlichen Speicherverbrauch geführt haben.

Hallo zusammen,

Ich wollte Ihnen nur ein Update zu den Schritten geben, die wir (und andere in der Community) unternommen haben, um dieses Problem in Angular 8 zu beheben:

• Unterstützung für TypeScript 3.5 https://github.com/angular/angular/pull/31615 hinzugefügt
• Verbessern Sie die Leistung, wenn viele faule Blöcke vorhanden sind. Https://github.com/webpack/webpack/pull/9472
• Korrigieren Sie die Leistungsregression in Knoten 12 https://github.com/angular/angular/pull/31638
• Warnen Sie, wenn CSS für große Komponenten enthalten ist: https://github.com/angular/angular-cli/pull/15093
• Warnen, wenn die TS-Kompilierung nicht verwendete Dateien enthält https://github.com/angular/angular-cli/pull/15061
• Reduzieren Sie die Anzahl der von Build Optimizer https://github.com/angular/angular-cli/pull/14998 verarbeiteten Dateien
• Verbesserte Leistung von Differential Loading Builds https://github.com/angular/angular-cli/pull/15246
• Weitere Ressourcen für Nicht-Watch-Builds wurden aufgeräumt. https://github.com/angular/angular-cli/pull/15292

Diese Bemühungen sind noch im Gange:

• Verbessern Sie die Leistung des JS-Minifers https://github.com/webpack-contrib/terser-webpack-plugin/issues/104
• Verbessern Sie die Leistung des Sass-Prozessors https://github.com/sass/dart-sass/issues/744
• Reduzieren Sie den vom Angular Compiler verwendeten Speicher
• Entfernen Sie pure_getter-Optimierungen https://github.com/angular/angular-cli/issues/14316

Folgendes können Sie tun, um diese Korrekturen zu nutzen:

• Update auf @angular/[email protected] (zusammen mit den anderen Framework-Paketen)
• Aktualisieren Sie auf @angular/[email protected] und @angular-devkit/[email protected]
• Update auf [email protected]
• Installieren Sie node-sass als Entwicklungsabhängigkeit, wenn Sie Sass verwenden
• Verwenden Sie Knoten 12.8

Ein besonderer Hinweis ist, dass wir die Funktionsweise von Differential Loading komplett überarbeitet haben. Es sollte jetzt viel schneller sein, kann aber abhängig von der Anzahl der Kerne mehr Systemspeicher verwenden. Dies unterscheidet sich von der Knotenspeichergrenze.

Wenn Sie das Speicherlimit des Knotens erreichen, wird der Fehler FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory angezeigt. Wenn Sie jedoch das Systemspeicherlimit erreichen, sollten Sie Fatal process OOM in insufficient memory to create an Isolate .

Das neue Differential Loading-Setup macht es seltener, den ersten zu treffen, aber wenn Sie viele Kerne, aber nicht viel Speicher haben, kann es üblicher sein, den zweiten zu treffen. Wir möchten bitte Feedback zu @angular-devkit/[email protected] , damit wir dieses Verhalten beheben können, wenn es ein Problem darstellt, indem wir in einigen Fällen die Parallelität deaktivieren oder konfigurierbar machen.

Ich habe den gleichen Fehler in Angular 8 und dies hat mein Problem gelöst:

node --max_old_space_size=X node_modules/@angular/cli/bin/ng build --prod

Wobei X = (2048 or 4096 or 8192 o..) der Wert des Speichers ist

@filipesilva nur installieren Node 12.8 hat das Problem behoben. Vielen Dank.

Hallo! sehr interessanter Thread
vor allem das:
https://github.com/angular/angular-cli/issues/13734#issuecomment -506760767
und das :
https://github.com/angular/angular-cli/issues/13734#issuecomment -521743839

Kann mir jemand das erklären:

Installieren Sie Node-Sass als Entwicklungsabhängigkeit, wenn Sie Sass verwenden

Geben wir Dart-Sass auf?

oder ist es eine Kombination aus der Verwendung von dart-sass als Hauptcompiler und node-sass als "Unterstützung", wenn das überhaupt funktioniert? (Der Kontext, ob npm i sass --save-dev / yarn add sass --dev in diesem Fall noch verwendet wird oder nicht, wurde in der obigen Anleitung nicht angegeben.)

Wie genau würde meine package.json-Datei aussehen und müssen noch weitere Änderungen an meinem Projekt vorgenommen werden?

Ich persönlich aktualisiere mein Projekt auf Winkel 8 und möchte zu Dart-Sass wechseln

EDIT:

Gibt es weitere Änderungen an meinem Projekt?

Um zumindest diesen Teil meiner eigenen Frage zu beantworten: Es scheint, dass Dart-Sass das Tag / deep / scss nicht unterstützt.

jedoch funktioniert :: ng-deep so, dass es das Beste von allen Welten ist. Ich mag Dart-Sass bis jetzt wirklich! so viel weniger Ärger beim Bauen.

Ich hatte dieses Problem und diese Lösung funktionierte für mich:

Ersetzen Sie in der Datei angle.json den Wert des outputPath-Schlüssels durch "dist".

Nur das Aktualisieren der Knotenversion von LTS auf Current hat mein Problem gelöst.

gleicher Fehler. node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod funktioniert immer noch nicht.

Konfrontationen mit einer großen Anwendung mit vielen Blöcken. Aber es scheint ein Problem in der Quellkarte zu sein und hat den gleichen Fehler wie in https://github.com/webpack/webpack-sources/issues/66

Ich musste auf Knoten 12 aktualisieren UND unseren Codebuild-Instanzspeicher von 3 auf 7 GB erhöhen. Nur um eine eckige App zu erstellen.

@filipesilva , ich bestätige, dass ng build jetzt gut funktioniert mit:

• eckig 8.2.2
• eckig / cli 8.2.2
• Knoten 12.4

ng build --configuration=production

angle.json

                    "configurations": {
                        "production": {
                            "optimization": true,
                            "outputHashing": "all",
                            "sourceMap": false,
                            "extractCss": true,
                            "namedChunks": false,
                            "aot": true,
                            "extractLicenses": true,
                            "vendorChunk": false,
                            "buildOptimizer": true,
                            "fileReplacements": [
                                {
                                    "replace": "src/environments/environment.ts",
                                    "with": "src/environments/environment.prod.ts"
                                }
                            ],
                            "serviceWorker": true
                        }

Vor einigen Monaten, als Sie mein großes, fettes SPA getestet haben, lag der Speicherverbrauch des Knotens über 2 GB, daher musste ich Folgendes verwenden:
node --max_old_space_size=8192 "node_modules/@angular/cli/bin/ng" build --configuration=production

Jetzt, da eine größere Codebasis mit ng build , beträgt die Speicherspitze des Knotens 1,6 GB.

Gute Arbeit. :) :)

Gibt es eine andere Möglichkeit, dies auf Knoten 10 zum Laufen zu bringen?

@stevefiedler , gibt es einen Grund, warum Sie auf Knoten 10 bleiben müssen?

Nun, das Springen auf 12 schien viel mehr Änderungen für meine Anwendung zu erfordern, und ich habe mehrere Anwendungen, über die ich mir Sorgen machen muss. Es sollte Schritt für Schritt funktionieren

@stevefiedler , ich habe ein großes, fettes Angular SPA, das seit September 2016 mit Angular 2 gestartet wurde, und es scheint, dass ich beim Wechsel zu Knoten 12 kein Problem festgestellt habe. Wenn Sie das Problem an StackOverflow senden, finden Sie möglicherweise weitere Hilfen und ich habe möglicherweise ein Blick auch.

@stevefiedler Aus purer Neugier. Welche Probleme haben Sie mit Ihrer Anwendung, wenn Sie den Compiler auf Knoten 12 ändern?

Ich habe die folgende Umgebung:

Knoten 12.9.1
Winkel 8,25 (von ng Upgrade)

@ angle-devkit / build-angle und build-ng-packagr von 0.803.3
@ Angular / Cli von 8.3.3

Wenn ich ng build --prod ausführe und den Knotenprozess beobachte, sehe ich ein ähnliches Verhalten bei der Speichernutzung wie oben beschrieben, wo es kaum 2 GB Nutzung übersteigt. An einem Punkt schlägt es jedoch nur mit der folgenden Fehlermeldung fehl. Scheint mit der Nutzung der Eichelbibliothek durch das Webpack zusammenzubrechen.

Ich habe ein sehr großes SPA, das Sass verwendet, und ich verwende Node-Sass anstelle von Dart.

Beim Versuch, ng build --prod auszuführen, wird die folgende Stapelverfolgung angezeigt:

ng build --prod
90% Chunk-Assets-Verarbeitung
<--- Letzte GCs --->

[32136: 00000223FBDD0BD0] 321271 ms: Mark-Sweep 1906,3 (2091,5) -> 1906,0 (2093,0) MB, 1306,9 / 0,0 ms (durchschnittliches mu = 0,187, aktuelles mu = 0,124) Zuordnungsfehler GC im alten Raum angefordert
[32136: 00000223FBDD0BD0] 321985 ms: Mark-Sweep 1912.7 (2093.0) -> 1910.5 (2093.0) MB, 656.7 / 0.1 ms (durchschnittlicher mu = 0.152, aktueller mu = 0.081) Zuordnungsfehler GC im alten Raum angefordert

<--- JS Stacktrace --->

==== JS-Stack-Trace ========================================

0: ExitFrame [pc: 00007FF779B1224D]
1: StubFrame [pc: 00007FF779B75575]

Sicherheitskontext: 0x022679540919
2: parseExprOp [0000039FA6955EF1] [C: projectnode_moduleswebpacknode_modulesacorndistacorn.js: 2034] [bytecode = 0000007FB1EB9C01 offset = 226] (this = 0x00876aee4d010x0183701f23d111588,0x0183701f23a9

FATAL ERROR: Ineffektive Mark-Compacts nahe der Heap-Grenze Zuordnung fehlgeschlagen - JavaScript-Heap nicht genügend Speicher
1: 00007FF778F5F0DF napi_wrap + 121039
2: 00007FF778F051D6 v8 :: base :: CPU :: has_sse + 34470
3: 00007FF778F05E96 v8 :: base :: CPU :: has_sse + 37734
4: 00007FF7796F89AE v8 :: Isolate :: ReportExternalAllocationLimitReached + 94
5: 00007FF7796E0951 v8 :: SharedArrayBuffer :: Externalize + 833
6: 00007FF7795AEC8C v8 :: internal :: Heap :: EphemeronKeyWriteBarrierFromCode + 1436
7: 00007FF7795B812F v8 :: internal :: Heap :: ProtectUnprotectedMemoryChunks + 1279
8: 00007FF7795B6614 v8 :: internal :: Heap :: PageFlagsAreConsistent + 3204
9: 00007FF7795AC263 v8 :: internal :: Heap :: CollectGarbage + 1235
10: 00007FF7795AAB04 v8 :: internal :: Heap :: AddRetainedMap + 2356
11: 00007FF7795C7684 v8 :: internal :: Factory :: NewByteArray + 100
12: 00007FF7796115D7 v8 :: internal :: BasicBlockProfiler :: Data :: ResetCounts + 8647
13: 00007FF7799194AC v8 :: internal :: compiler :: CodeGenerator :: GenerateDeoptimizationData + 124
14: 00007FF779919247 v8 :: internal :: compiler :: CodeGenerator :: FinalizeCode + 103
15: 00007FF77994FAEA v8 :: internal :: compiler :: LiveRange :: End + 746
16: 00007FF77995011F v8 :: internal :: compiler :: LiveRange :: End + 2335
17: 00007FF77964F0FA v8 :: internal :: Compiler :: FinalizeBackgroundCompileTask + 922
18: 00007FF77964F583 v8 :: internal :: Compiler :: FinalizeOptimizedCompilationJob + 931
19: 00007FF779639228 v8 :: internal :: OptimizingCompileDispatcher :: InstallOptimizedFunctions + 600
20: 00007FF779605CCA v8 :: internal :: StackGuard :: HandleInterrupts + 1770
21: 00007FF779339432 v8 :: internal :: interpreter :: JumpTableTargetOffsets :: iterator :: operator = + 5138
22: 00007FF779B1224D v8 :: internal :: SetupIsolateDelegate :: SetupHeap + 575565
23: 00007FF779B75575 v8 :: internal :: SetupIsolateDelegate :: SetupHeap + 981877
24: 00007FF779A8FCFC v8 :: internal :: SetupIsolateDelegate :: SetupHeap + 41724
25: 0000039B9B7A5C28

Wollte ein bisschen mehr Informationen hinzufügen. ng build scheint gut zu funktionieren. Nur bei Verwendung des Flags --prod tritt das Heap-Problem auf. Hier ist meine Produktkonfiguration aus der angle.json:

"Produktion": {
"fileReplacements": [{
"ersetzen": "apps / standard / src / environment / environment.ts",
"with": "apps / standard / src / environment / environment.prod.ts"
}],
"Optimierung": wahr,
"outputHashing": "all",
"sourceMap": false,
"extractCss": true,
"namedChunks": false,
"aot": wahr,
"extractLicenses": true,
"vendorChunk": false,
"buildOptimizer": true,
"vendorSourceMap": false
},

Vielen Dank @filipesilva für den umfassenden Benchmark. Die Installation von Node-Sass hat uns nicht herausgeholt, aber das Upgrade von Angular auf

Ist es nicht seltsam, dass die meisten Leute, die den JavaScript-Heap als Speicherfehler melden, genau bei

Gibt es eine Möglichkeit, dieses Problem zu beheben, ohne den Knoten von LTS auf den aktuellen Stand zu aktualisieren? In meinem Projekt wird Build auf dem Server generiert. Ich kann nicht alle Server bitten, den Knoten zu aktualisieren.

@akvaliya Knoten 12 wird in weniger als einem Monat LTS sein. Ich kann nicht sehen, wie sinnvoll es ist, einen so komplizierten und weitreichenden Fehler mit einer Version zu beheben, die bald zum „Semi-Legacy“ wird. https://nodejs.org/en/about/releases/

@ Tomgruszowski Ja. Aber ich kann dem Client nicht sagen, dass er alle seine Server aktualisieren soll.

@akvaliya Warum

@benelliott Nun, ich bereitstellen .

Ich denke nicht, dass dies der Punkt sein sollte, warum wir Front-in-Server bauen. Einige Clients möchten, dass Code nach dem Festschreiben automatisch erneut bereitgestellt wird. Wie mit Jenkins.

Für mich bestand die Lösung darin, meine tsconfig (ionic4 und angle8) zu bearbeiten.

Ich habe herumgespielt und Eigenschaften zu tsconfig hinzugefügt. Gegen Ende habe ich Quell-Maps für meinen Produkt-Build in angular.json aktiviert.

Ich musste die sourceMap: true und sourceBase: "/" aus tsconfig entfernen, danach funktioniert --prod wie ein Zauber

"scripts": {
        "start": "node --max-old-space-size=4096 ./node_modules/@angular/cli/bin/ng serve",
        "start:prod": "node --max-old-space-size=4096 ./node_modules/@angular/cli/bin/ng serve --prod",
}

Die obige Konfiguration löst für mich

Für uns hat ein Upgrade von Angular 8.2.0 auf 8.2.8 den Trick gemacht und wir haben den Fehler nicht mehr bekommen. Das Zuweisen von mehr Speicher hat bei uns nicht funktioniert.

@filipesilva nur installieren Node 12.8 hat das Problem behoben. Vielen Dank.

Ich habe das gleiche Problem auch mit 12.8.

@filipesilva nur installieren Node 12.8 hat das Problem behoben. Vielen Dank.

Wurde mit Debug und Node> 12.8 für mich behoben

Ich habe ein benutzerdefiniertes Projekt, das Angular nicht verwendet, sondern mit Webpack erstellt wurde. Dieser Fehler tritt auf, wenn ich mit Webpack im Modus production erstelle. Ich habe --max_old_space_size=8192 ausprobiert, aber kein Glück (ich glaube, ich brauche mehr).

Ich frage mich, was eigentlich das Problem ist. Ich wette, unterschiedliche Frameworks / Bibliotheken / Apps haben möglicherweise ähnliche Webpack-Konfigurationen, die dies verursachen können.

Ich hatte das gleiche Problem und habe die folgenden Schritte ausgeführt:

• ng update @angular/cli @angular/core
• Aktualisieren Sie den Knoten auf v12.11.1
  funktioniert gut mit --max_old_space_size=8192
"@angular/core": "8.2.8", "@angular/cli": "^8.3.6"

Die spezifische Ursache für diesen Fehler ist für mich (in meinem nicht eckigen Projekt) die Verwendung von uglifyjs-webpack-plugin . Es verwendet eine Tonne Speicher. Im Moment habe ich die Minifizierung in der Produktion deaktiviert und muss später herausfinden, wie ich sie beheben kann.

Ich habe die Minifizierung in der Produktion deaktiviert

😨

Das hat bei mir für Entwickler-Builds funktioniert. Ich habe dieses Problem bei Produktions-Builds noch nicht gesehen.

"build:highmem": "node --max_old_space_size=8192 ./node_modules/@angular/cli/bin/ng build",

Ich brauchte dies erst, nachdem ich Angular und CLI von 8.0.0 auf die neuesten 8.2.8 und 8.3.6 aktualisiert hatte. Hier ist die PR, in der dies geändert wurde: https://github.com/angular/material.angular.io/pull/641

Die spezifische Ursache für diesen Fehler ist für mich (in meinem nicht eckigen Projekt) die Verwendung von uglifyjs-webpack-plugin . Es verwendet eine Tonne Speicher. Im Moment habe ich die Minifizierung in der Produktion deaktiviert und muss später herausfinden, wie ich sie beheben kann.

Dies hängt wahrscheinlich mit Quellkarten zusammen. Versuchen Sie, sourceMap in tsconfig.json sourceMap auf false zu setzen (oder für diejenigen mit eckigen Projekten in angular.json ).

Ein Hinweis für Angular / Windows / Docker-Benutzer

Wenn Sie versuchen, 'npm run build' oder etwas Ähnliches in Ihrer Docker-Datei auszuführen und diesen Fehler erhalten, wie oben erwähnt, möchten Sie stattdessen den folgenden Befehl run verwenden, um den Zugriff von Node.js auf den Speicher zu erhöhen.

node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod

Darüber hinaus führt Docker im Hintergrund eine Linux-VM aus, die auch Speicherbeschränkungen aufweist, die behoben werden müssen.

Navigieren Sie zu 'C: BenutzerAppDataRoamingDocker 'wobei der Profilname der Name Ihres angemeldeten Profils ist. Dort finden Sie eine Datei 'settings.json'. Öffnen Sie es und stellen Sie den Wert für 'memoryMiB' auf 8192 ein. Sie müssen neu starten, damit die Änderungen wirksam werden.

WARNUNG

Das Erhöhen des VM-Speichers kann sich drastisch auf die Leistung Ihres Computers auswirken. Stellen Sie daher sicher, dass Sie über genügend physischen Speicher verfügen, bevor Sie dies versuchen. Wenn diese Lösung für Sie funktioniert, sollten Sie versuchen, die Werte so weit wie möglich zurückzusetzen, indem Sie einen Vorgang ausführen, z. B. den Wert zunächst halbieren, testen, erneut halbieren, wenn er funktioniert, oder die Hälfte des neuen Werts hinzufügen zurück, wenn dies nicht der Fall ist usw. Dies hilft Ihnen, die Auswirkungen auf Ihre Maschine zu minimieren.

Sie möchten Docker auch als Startprogramm für Windows 10 deaktivieren. Suchen Sie einfach in der Taskleiste nach "Start-Apps" und wählen Sie die entsprechende Option aus. Auf diese Weise haben Sie keine VM, die Sie nicht verwenden, um Ihr System zu blockieren.

Für mich bestand die Lösung darin, meine tsconfig (ionic4 und angle8) zu bearbeiten.

Ich habe herumgespielt und Eigenschaften zu tsconfig hinzugefügt. Gegen Ende habe ich Quell-Maps für meinen Produkt-Build in angular.json aktiviert.

Ich musste die sourceMap: true und sourceBase: "/" aus tsconfig entfernen, danach funktioniert --prod wie ein Zauber

Das Entfernen von sourceMap hat bei mir funktioniert. Frustrierend....

set NODE_OPTIONS = - Der Befehl max-old-space-size = 30720 hat bei mir funktioniert.

Hatte das gleiche Problem und ein Upgrade des Knotens auf 12.12 heute ließ mich ng build --prod

Wir verwenden Bitbucket-Pipelines und können das Speicherlimit nicht auf 8 GB erhöhen. Außerdem dauert die Erstellung unserer Anwendung ca. 7-10 Minuten und wir benötigen die sourceMaps für unsere Sentry-Fehlerberichte.

UPDATE: Das Ausführen von ng update @angular/cli @angular/core das Problem gelöst.

Ich habe die node.js auf die neueste Version von LTS (in diesem Moment 12.13.0 ) aktualisiert und alles funktioniert perfekt. Sie müssen die max-old-space-size nicht mehr einstellen.

Wir hatten den gleichen Fehler bei Windows-Comupters, der durch eine Fehlkonfiguration in _angular.json_ verursacht wurde. outputPath wurde auf einen Pfad / ein Laufwerk gesetzt, der nicht vorhanden ist, und es kam immer zu demselben Fehler, in Angular 7/8 und mit verschiedenen Versionen von node.js (12.x).

"architect": {
  "build": {
    "options": {
      "outputPath": "Y:/apps/dist" // this caused "JavaScript heap out of memory"!
    }
  }
}

Wir verwenden Bitbucket-Pipelines und können das Speicherlimit nicht auf 8 GB erhöhen. Außerdem dauert die Erstellung unserer Anwendung ca. 7-10 Minuten und wir benötigen die sourceMaps für unsere Sentry-Fehlerberichte.

UPDATE: Das Ausführen von ng update @angular/cli @angular/core das Problem gelöst.

Das Ausführen des ng-Updates hat auch bei mir funktioniert. Eine der Nebenpunktversionen muss einen Speicherverlust gehabt haben. Der Wechsel von 8.2.8 zu 8.2.11 hat das Problem behoben.

Mit den neuesten Versionen von Node ist (zumindest für mich) gelöst. Ich empfehle den Teamknoten, der in den package.json-Konstrukten verwendet wird. Engines:
https://docs.npmjs.com/files/package.json#Engines

Dies funktioniert bei mir: https://stackoverflow.com/a/58916640/1077309

Ich hatte ein sehr großes Objekt (Array von ungefähr 100.000 Elementen), das den Builder zum Absturz brachte.

Das Entfernen dieses Objekts löste das Problem für mich.

(Um dieses Problem zu umgehen, speichere ich das Objekt jetzt als Zeichenfolge / JSON und analysiere es zur Laufzeit.)

[Fehler] Fehler: Npm fehlgeschlagen mit Rückkehrcode: 3221226505

13 ausführlicher Stapel Fehler: [email protected] dev_build2019: node --max_old_space_size=8384 ./node_modules/@angular/cli/bin/ng build --configuration=dev
13 ausführlicher Stapel Beendigungsstatus 3221226505
13 ausführlicher Stapel bei EventEmitter.(C: Programmdateiennodejsnode_modulesnpmnode_modulesnpm-lifecycleindex.js: 332: 16)
13 ausführlicher Stapel bei EventEmitter.emit (events.js: 210: 5)
13 ausführlicher Stapel bei ChildProcess.(C: Programm Filesnodejsnode_modulesnpmnode_modulesnpm-lifecyclelibspawn.js: 55: 14)
13 ausführlicher Stapel bei ChildProcess.emit (events.js: 210: 5)
13 ausführlicher Stapel bei MaybeClose (intern / child_process.js: 1021: 16)
13 ausführlicher Stapel bei Process.ChildProcess._handle.onexit (internal / child_process.js: 283: 5)
14 ausführlich pkgid [email protected]
15 ausführliches cwd D: a1sPROP-VIVO-SPA
16 ausführlich Windows_NT 10.0.14393
17 ausführliches Argument "C: \ Programme \ nodejs \ node.exe" "C: \ Programme \ nodejs \ node_modules \ npm \ bin \ npm-cli.js" "run" "dev_build2019"
18 ausführlicher Knoten v12.13.0
19 ausführliche npm v6.12.0
20 Fehlercode ELIFECYCLE
21 Fehler errno 3221226505
22 Fehler [email protected] dev_build2019: node --max_old_space_size=8384 ./node_modules/@angular/cli/bin/ng build --configuration=dev
22 Fehler Status beenden 3221226505
23 Fehler beim Skript [email protected]
23 Fehler Dies ist wahrscheinlich kein Problem mit npm. Es gibt wahrscheinlich zusätzliche Protokollierungsausgabe oben.
24 ausführlicher Ausgang [3221226505, wahr]

Bitte geben Sie mir die Lösung für dieses Build-Problem

@PritiMaurya , Versuchen Sie den folgenden Befehl, um einen Build zu generieren

node_modules / .bin / ng build --prod --aot --source-map = false --vendor-chunk = true --output-hashing none

@ Kumaresan-Subramani Ich erhalte Fehler
FATAL ERROR: Ineffektive Mark-Compacts nahe der Heap-Grenze Zuweisung fehlgeschlagen - JavaScript-Heap hat nach Ausführung über cmd nicht genügend Speicher

@ Kumaresan-Subramani Kennen Sie Fehler
Npm fehlgeschlagen mit Rückkehrcode: 3221226505

Ich erhalte diesen Fehler, während ich auf vsts aufbaue

@ Kumaresan-Subramani Ich erhalte Fehler
FATAL ERROR: Ineffektive Mark-Compacts nahe der Heap-Grenze Zuweisung fehlgeschlagen - JavaScript-Heap hat nach Ausführung über cmd nicht genügend Speicher

Sie können es so versuchen

Knoten --max-old-space-size = 4096 ./node_modules/@angular/cli/bin/ng build

Überprüfen Sie Ihren Ordnernamen. Benennen Sie ohne Leerzeichen um und starten Sie Ihren Computer neu.

Ich habe keinen Ordnernamen mit Leerzeichen

@PritiMaurya , Probieren Sie die über diesen Link vorgeschlagene Lösung aus. Es könnte helfen.

Ich habe keinen Ordnernamen mit Leerzeichen

Bitte starten Sie Ihre Maschine neu.

Das Gleiche gilt für NG8 + Knoten 10,16 + _not minitied_ Build (fand heraus , dass in meinem Fall Auth0Lock Paket verursacht das Problem)
Auf Knoten 12.13 ist alles in Ordnung

Ich stehe auch vor diesem Problem. Das ist meine Konfiguration:

    _                      _                 ____ _     ___
   / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
  / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
 / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
/_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
               |___/

Angular CLI: 1.6.8
Node: 10.17.0
OS: darwin x64
Angular: 5.2.11
... common, compiler, compiler-cli, core, forms, http
... language-service, platform-browser, platform-browser-dynamic
... router

@angular/animations: 4.4.7
@angular/cli: 1.6.8
@angular-devkit/build-optimizer: 0.0.42
@angular-devkit/core: 0.0.29
@angular-devkit/schematics: 0.0.52
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.9.8
@schematics/angular: 0.1.17
typescript: 2.5.3
webpack: 3.10.0

Im Stapelüberlauf habe ich diese Lösung gefunden . Es funktioniert, aber ich weiß nicht, ob dieser Ansatz richtig oder sinnvoll erscheint.

Ich habe die node.js auf die neueste Version von LTS (in diesem Moment 12.13.0 ) aktualisiert und alles funktioniert perfekt. Sie müssen die max-old-space-size nicht mehr einstellen.

Das hat bei mir funktioniert!

Ich habe die node.js auf die neueste Version von LTS (in diesem Moment 12.13.0 ) aktualisiert und alles funktioniert perfekt. Sie müssen die max-old-space-size nicht mehr einstellen.

Das hat bei mir funktioniert!

Das Update auf die neuesten node.js hat auch bei mir funktioniert!

Ich habe die node.js auf die neueste Version von LTS (in diesem Moment 12.13.0 ) aktualisiert und alles funktioniert perfekt. Sie müssen die max-old-space-size nicht mehr einstellen.

Das hat bei mir funktioniert!

Ich habe die node.js auf die neueste Version von LTS (in diesem Moment 12.13.0 ) aktualisiert und alles funktioniert perfekt. Sie müssen die max-old-space-size nicht mehr einstellen.

Hat auch für mich gearbeitet

Ich habe die node.js auf die neueste Version von LTS (in diesem Moment 12.13.0 ) aktualisiert und alles funktioniert perfekt. Sie müssen die max-old-space-size nicht mehr einstellen.

Hat auch für mich gearbeitet

Ich kann bestätigen, dass dies funktioniert.

Selbes Problem hier. Winkel 7. Beliebige Node 12.X-Version.

Funktioniert mit Knoten 10.

Ein Upgrade auf 12.x hat bei mir funktioniert. Angular jeden Tag immer weniger lieben ...

Bei jeder Veröffentlichung erinnere ich mich an eine Präsentation eines der eckigen Mitglieder auf NGConfg, in der Folgendes gesagt wurde:

"Wir haben über 400 Anwendungen bei Google und wir haben Hundefutter eckig, bevor wir es in die Wildnis veröffentlichen. Wenn eine der Anwendungen geändert werden muss, um das Update anzupassen, veröffentlichen wir es nicht."

Ich denke, jede einzelne Version erforderte eine Art Update des Codes.

Soweit ich mich erinnere, sagten sie, dass sie die Anwendungen testen, um sicherzustellen, dass nach den erforderlichen Code-Upgrades nichts kaputt geht. Ich glaube, ein Upgrade des Codes, um die Verbesserungen zu berücksichtigen, ist sowieso unvermeidlich.

Aber diese aktuelle Ausgabe hat nichts damit zu tun. Es geht mehr um die Anwendungsgröße. Wenn die Anwendungsgröße zunimmt, müssen Sie die Heap-Größe für den Knotenprozess erhöhen.

Ist mir gerade nach dem Update von 9.0.3 auf 9.0.5 passiert

Hallo zusammen..
Ich habe die Ubuntu 18.04 EC2-Instanz verwendet, um Docker-Images zu erstellen.
Dieses Problem ist behoben, sobald ich den Instanztyp von t2.micro in t2.medium ändere.

Ich stand vor dem gleichen Problem für ng dienen,

npm cache clean --force Beheben Sie dieses Problem

NodeJS Update auf die neueste Version hat es für mich gelöst.

Ich habe durch die Installation von Nodejs V12 gelöst,
Ich hatte Probleme mit Nodejs V10

Am Samstag, den 2. Mai 2020 um 01:59 Uhr schrieb Igor Iric [email protected] :

Node JS Update auf die neueste Version hat es für mich gelöst.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/angular/angular-cli/issues/13734#issuecomment-622554387 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AH6IJ4PME7KZY3J7J3ARITDRPMWLXANCNFSM4GY5SKAQ
.

Alles in allem ist dieses Problem zu diesem Zeitpunkt ziemlich alt und wir konzentrieren uns hauptsächlich auf Probleme bei der Ressourcennutzung in neueren CLI-Versionen. Dieses Problem enthält auch verschiedene Probleme, die sich auf ähnliche Weise zu manifestieren scheinen, was es schwierig macht, sich darauf einzulassen. Wenn Sie immer noch solche Probleme sehen, öffnen Sie bitte eine neue Ausgabe mit Details zur Reproduktion.

verwenden
" build: prod ": "node --max_old_space_size = 8000 ./node_modules/@angular/cli/bin/ng build --configuration = prod" in Ihrer Datei package.json

Dadurch wird der Knoten angewiesen, die Standardspeicherzuweisung um die im Befehl angegebene Größe zu überschreiten.

Wenn es jemand anderem hilft, hat es beim Wechsel von "@ angle-devkit / build-angle": "0.803.26" zu "@ angle-devkit / build-angle": "0.803.27" dazu geführt, dass der Speicher während des Vorgangs weggelaufen ist Prod Builds bei ~ 43% Build-Fortschritt. Es würde bei diesem Schritt hängen bleiben und auf> 25 GB RAM anstatt auf ~ 1,5 GB eskalieren.

Als wir zurück zu "@ angle-devkit / build-angle": "0.803.26" wechselten, funktionierte es wieder. 0.803.27 ist eine aktuelle Version um den 11.06.20, daher werden nur neue Vorkommen dieses Problems erklärt.

Scheint, als ob das Problem mit Version 10 zurück ist. Verwenden der Pakete @angular-devkit/build-angular v0.1000.0 und @angular/* v10.0.0 .

Knoten: v14.1.0
NPM: 6.14.5

Stapelspur:

<--- Last few GCs --->

[13013:0x108008000]  2808381 ms: Scavenge 2003.1 (2051.0) -> 2002.5 (2051.5) MB, 4.0 / 0.0 ms  (average mu = 0.117, current mu = 0.045) allocation failure 
[13013:0x108008000]  2809520 ms: Mark-sweep 2003.3 (2051.5) -> 2002.1 (2051.0) MB, 1132.9 / 0.0 ms  (average mu = 0.073, current mu = 0.026) allocation failure scavenge might not succeed
[13013:0x108008000]  2809535 ms: Scavenge 2003.1 (2051.0) -> 2002.5 (2051.5) MB, 3.3 / 0.0 ms  (average mu = 0.073, current mu = 0.026) allocation failure 


<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x100bc569b node::Abort() (.cold.1) [/usr/local/bin/node]
 2: 0x1000816b5 node::FatalError(char const*, char const*) [/usr/local/bin/node]
 3: 0x10008181e node::OnFatalError(char const*, char const*) [/usr/local/bin/node]
 4: 0x100180909 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
 5: 0x1001808b3 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
 6: 0x1002a0bfd v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/usr/local/bin/node]
 7: 0x1002a1f60 v8::internal::Heap::MarkCompactPrologue() [/usr/local/bin/node]
 8: 0x10029f947 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/local/bin/node]
 9: 0x10029e112 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node]
10: 0x1002a60d4 v8::internal::Heap::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node]
11: 0x1002a612a v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node]
12: 0x10028417d v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/usr/local/bin/node]
13: 0x1004e7b16 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/usr/local/bin/node]
14: 0x10074fe99 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/usr/local/bin/node]
zsh: abort      npm run start

Nach dem Upgrade von Node.js auf v14.4.0 scheint das Problem behoben zu sein.

@Flyrell Ich habe das gleiche Problem mit Nodejs 14.4.0 und Angular 10

@Flyrell Ich habe das gleiche Problem mit Nodejs 14.4.0 und Angular 10, aber das scheint nicht gelöst zu sein

Ja, ich habe den Entwicklungsserver heute etwas länger verwendet und das Problem besteht immer noch.

Ja, das Problem besteht weiterhin mit Winkel 10 und Knoten 12.16.1 :(

@Flyrell @gvsakhil Vermeiden Sie es, geschlossene Probleme zu kommentieren, die sich auf alte Versionen beziehen. Es gibt eine offene Ausgabe Nr. 16860 für NG9, die angemessener wäre.

Beachten Sie, dass es bereits jetzt ein Problem # 18087 für Angular 10 gibt, das geschlossen wurde, sodass Sie mit der nächsten Version einige Verbesserungen erwarten können.

Dieses Problem wurde aufgrund von Inaktivität automatisch gesperrt.
Bitte reichen Sie ein neues Problem ein, wenn Sie auf ein ähnliches oder verwandtes Problem stoßen.

Lesen Sie mehr über unsere Richtlinien zum automatischen Sperren von Konversationen .

_{_Diese Aktion wurde automatisch von einem Bot ausgeführt._}