Hola, en el seguimiento de la pila de errores, parece que estás usando una configuración diferente de "producción", ¿podrías compartir esa configuración?

Disculpe las discrepancias, aquí están los parámetros de configuración que necesita

"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"
                }
              ]
            }

Yo tengo el mismo error:

Mi env:

Chicos, aquí se describe la "solución" para este problema: https://github.com/angular/angular-cli/issues/5618

• [] nuevo
• [ ] construir
• [X] servir picana
• [ ] prueba
• [] e2e

Estoy enfrentando el mismo problema mientras ng serve --prod

Imagen de referencia

Recibí el mismo error. El proceso de NodeJs usa alrededor de 1.5GB de RAM, y después de unos minutos de intentar limpiar / asignar memoria, falla con un error.

ACTUALIZAR: -

He visto este problema solo en la máquina WINDOWS en particular. Alguien más, ¿lo notó? ¿O tienes el mismo problema en otras máquinas?

Nota: Probé 2 máquinas con Windows, todas las pruebas dieron el mismo resultado. Ambas máquinas tienen casi la misma configuración.
es decir, 8 GB de RAM / acceso de administrador para procesadores Bash / CMD / PowerShell / i3 e i5 (cuatro núcleos, ambos).

Y admito que el proyecto en el que estoy trabajando es un lío en términos de calidad de código.
Probé un código limpio, una aplicación completa, EN WINDOWS , fue más lento en el proceso de compilación, pero funcionó bien.

Probé el código del proyecto MESSY, nunca se compila en la asignación de montón de nodos predeterminada (alrededor de 1.2 GB, no estoy seguro). Funciona si asigno más memoria de pila al proceso de nodo, digamos 5 GB. Pero, también en ese caso, tomó más de 30 minutos construirlo. Probé la opción de montón de nodo 5 GB con y sin --aot AND / OR --prod .

El mismo código cuando se probó en CentOS podría ser una instancia de 1GB RAM / Virtual Xenon Processor (1 Core), genera compilación en 90 segundos. con y sin --aot Y / O --prod

No estoy seguro, pero parece que el problema es con Node Service, no con Angular CLI en sí, porque he visto un retraso en el rendimiento en las nuevas versiones de NodeJS después de la última actualización (localmente en la máquina WINDOWS solamente).

Algunas observaciones a continuación:

A pesar de asignar 5 GB de montón, nunca usó más de 1.9 GB (máx.) Y el proceso de asignación fue muy lento ... estaba aumentando el consumo de RAM 1-2 MB por 3-5 segundos. Y no estaba usando Disk Resource como solía ser en la versión anterior. (El acceso al disco era muy alto anteriormente en la máquina WINDOWS, pero el proceso de compilación fue más rápido sin asignación de RAM adicional. Esta vez, la misma máquina casi el mismo código con algunas correcciones de errores, pero el nodo se actualizó, el consumo de disco se redujo pero la generación de compilación fue lenta).

Espero que alguien pueda confirmar esto.

Sí, también me enfrento al mismo problema

El mismo problema aquí se ejecuta en un Mac book pro. macOs Mojoave. Cualquier entorno con producción: verdadero

mismo problema en el servidor ubuntu 18.04, pero esto resolvió mi problema:
node --max_old_space_size = 8192 node_modules / @ angular / cli / bin / ng build --prod

Intenté desinstalar Angular CLI 7 e instalé 6.0.8. Verificó la versión degradada por ng version , aún se rompe con el mismo error.

Quizás esto también podría deberse a nodeJs. Porque, estoy construyendo el mismo código en CentOS 7, 1.75GB de RAM (con 512MB de memoria de intercambio), procesador de un solo núcleo y con CLI 7 angular, funciona allí. Se está rompiendo en mis máquinas de 2 ventanas.

Para aquellos que no pueden permitirse asignar más RAM (debido a que hay menos memoria disponible) pueden crear una memoria SWAP desde el espacio disponible en el disco duro del sistema. Será un poco más lento, pero debería funcionar sin la actualización del sistema. Yo hice lo mismo. 👍

En mi caso, el problema solo aparece, al construir --prod --source-map . La compilación normal --prod funciona bien.

Usando --max_old_space_size=8192 como lo sugiere @nokhodian , funciona con un consumo de memoria que alcanza un máximo de ~ 3.8GiB durante la generación del mapa de origen.

Entorno de construcción:

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

En mi archivo angular.json he configurado "sourceMap": false, pero no me ayudó. Mismo problema para prod build

simplemente repicando aquí con el mismo mensaje de error al ejecutar ng build cuando la compilación está trabajando en un archivo scss en particular

También tengo este problema, pero puedo resolverlo con "NODE_OPTIONS = - max-old-space-size = 8192". El uso de RAM durante la compilación aumenta alrededor de 14 GB.

Igual que aquí. Encontré eso después de buscar más. Envié instrucciones a nuestro equipo para configurar esta variable de entorno y configurarla en nuestros servidores de compilación. Parece funcionar y la construcción parece ser más rápida que antes de dejar de funcionar.

Empecé a tener el mismo problema con Azure Pipelines: # https://github.com/Microsoft/azure-pipelines-image-generation/issues/854 Supuse que era un problema de alojamiento, ya que no tengo el problema en las instalaciones. .

También estamos viendo este problema. Con ng serve siendo el peor, pero incluso el ng build normal tiene problemas ahora. ¿Podría esto estar relacionado con el descaro? Algo parece mal.

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

Arriba está la información de mi cabeza de old_space del informe generado. ¿Qué puede hacer que estos números sean tan grandes?

¿Alguien ha experimentado esto en un proyecto que no usa descaro?

Estamos experimentando este problema cuando usamos
ng build --prod
A veces es necesario porque usamos diferentes configuraciones de entorno.
node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng serve --prod resuelve el problema pero el tiempo de construcción se excede a 3 minutos.
No creo que este problema esté resuelto

Este problema es el mismo que https://github.com/angular/angular-cli/issues/5618#issuecomment -450151214, por lo que puedo decir.

Sin embargo, no veo muchas cosas que pueda seguir e investigar. @themanojshukla mencionó que Windows estaba tardando mucho más . @ j3gb3rt pregunta sobre sass, y he visto informes en el pasado sobre sass haciendo las cosas más lentas.

¿Alguien tiene una reproducción que podamos mirar e intentar depurar?

Me encontré con este problema en un proyecto que no usa sass. Hice algunas pruebas de entorno porque originalmente pensé que era un problema relacionado con Azure Dev Ops.

Uso de Azure Dev Ops Pipelines:

• Agente de Linux alojado con el nodo 10: la compilación se realiza correctamente
• Agente alojado de Windows vs2017 con Nodo 10: la compilación falla
• Agente alojado de Windows vs2017 con el nodo 6: la compilación falla
• Agente alojado de Windows vs2019 con Nodo 10: la compilación falla
• Agente alojado de Windows vs2019 con Nodo 6: la compilación falla
• Agente de contenedor de Windows alojado con nodo 10: compilación fallida 5/10 intentos
• Instalar Build Agent en mi máquina de desarrollo (win10) con Node 10: Build Success
• Instalar Build Agent en mi máquina de desarrollo (win10) con Node 6: Build Success
• Máquina de desarrollo (win10) usando cmd con Node 10: Build exitosos
• Máquina de desarrollo (win10) usando cmd con Node 6: Build Succeeds

Sí @filipesilva y @Calidus mis proyectos tampoco usan sass.

Déjame darte algunas observaciones más ...

• El proyecto favorito (siguiendo las mejores prácticas en la medida de lo posible) que creé hace aproximadamente un año estaba funcionando muy bien en ese momento (no recuerdo la versión CLI que usé). Ahora, cuando lo estoy construyendo usando --aot --prod , lleva un poco más de tiempo que antes, pero nunca se rompe. Sin descaro.
• Nuevo proyecto (por supuesto, base de código de producción y lo admito, códigos realmente muy desordenados), se rompe en --aot --prod . No se usa Sass. Rompe ventanas siempre. A veces funciona en ubuntu sin asignar un montón adicional en el proceso de nodo, pero la tasa de éxito en ubuntu es del 10%, digamos.
• Otro proyecto de nivel medio (códigos desordenados) funciona sin asignación de montón adicional, pero lleva un poco más de tiempo tanto en Windows como en Ubuntu .
• Otro proyecto favorito (siguiendo las mejores prácticas en la medida de lo posible) funciona bien hasta ahora ... pero hay muy menos archivos para compilar, por lo que no puedo estar seguro de procesar cargas.

Al ejecutar ng build --aot --prod por primera vez después del inicio / reinicio de la máquina. tarda 57 segundos. después, solo 22-25 segundos.

Captura de pantalla de la primera ejecución ...

Captura de pantalla de la segunda ejecución ...

Ambos son para el mismo proyecto .. y son de al escribir este comentario.

Espero eso ayude.

Estoy enfrentando el mismo problema. Cada vez que construyo, obtengo un "montón de JavaScript sin memoria". No quiero usar el nodo --max_old_space_size = 8192 ya que esto no parece una buena práctica. ¿Alguna otra forma de solucionar esto?

@ noopur-dabhi No creo que sea justo decir que usar node --max_old_space_size=8192 no es la mejor práctica.

No es más que permitir que el proceso NODE _ (que va a construir su aplicación ahora) _ use más que la memoria de pila PREDETERMINADA (de su área de RAM o SWAP).

Y este tipo de asignación es muy común en la mayor parte del proceso de desarrollo de aplicaciones (especialmente de implementación). Por ejemplo, en Java, si queremos restringir el uso de la pila de nuestra aplicación Java, agregamos un indicador adicional como --Xmx64m esto significa que la memoria de pila máxima permitida es de 64 MB.

Entonces, si la 'Mejor práctica' es la única preocupación, creo que no es un problema usar node --max_old_space=8192 , esto significa que está permitiendo que el proceso NODE use un máximo de 8192 MB de memoria. nada que ver con Best Practice Concern .

Esto todavía me falla> ¿alguna sugerencia?
Intenté "ng build --aot --prod"
y "node --max_old_space_size = 8192 node_modules / @ angular / cli / bin / ng build --prod"

• Angular Live Development Server está escuchando en localhost: 4200 , abra su navegador en http: // localhost : 4200 / **
  92% de optimización de fragmentos de activos TerserPlugin
  <--- Últimos GC --->

[9568: 000002A08DC547B0] 183499 ms: Mark-sweep 1350.2 (1423.6) -> 1350.2 (1424.1) MB, 952.0 / 0.0 ms (mu promedio = 0.111, mu actual = 0.000) falla de asignación GC en el espacio anterior solicitado
[9568: 000002A08DC547B0] 184477 ms: Mark-sweep 1350.2 (1424.1) -> 1350.2 (1424.1) MB, 977.5 / 0.0 ms (mu promedio = 0.058, mu actual = 0.000) GC de último recurso en el espacio anterior solicitado

<--- Seguimiento de pila JS --->

==== Seguimiento de pila JS =========================================

0: ExitFrame [pc: 000001D7B1850481]

Contexto de seguridad: 0x008d8961d9b1
1: / * anónimo * / [0000006BEE99B319] [C: CODEV2UXnode_moduleswebpack-sourcesnode_modulessource-maplibsource-node.js: ~ 342] pc = 000001D7B3E70B48
2: SourceNode_walk [000001779ECCDF31] [C: CODEV2UXnode_moduleswebpack-so ...

ERROR FATAL: Mark-compacts ineficaz cerca del límite de almacenamiento falló en la asignación: el montón de JavaScript no tiene memoria

Escribiendo el informe Node.js en el archivo: report.20190506.161503.9568.001.json
Informe de Node.js completado
1: 00007FF775E1896A público: __cdecl v8 :: interno :: GCIdleTimeHandler :: GCIdleTimeHandler (void) __ptr64 + 4554
2: 00007FF775DC8956 uv_loop_fork + 85542
3: 00007FF775DC941D uv_loop_fork + 88301
4: 00007FF7761EE72E void __cdecl v8 :: internal :: FatalProcessOutOfMemory (clase v8 :: internal :: Isolate * __ptr64, char const * __ptr64) +798
5: 00007FF7761EE667 void __cdecl v8 :: internal :: FatalProcessOutOfMemory (clase v8 :: internal :: Isolate * __ptr64, char const * __ptr64) +599
6: 00007FF7762A2144 público: static bool __cdecl v8 :: internal :: Heap :: RootIsImmortalImmovable (int) +14068
7: 00007FF776297F52 public: bool __cdecl v8 :: internal :: Heap :: CollectGarbage (enum v8 :: internal :: AllocationSpace, enum v8 :: internal :: 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 privado: clase v8 :: internal :: HeapObject * __ptr64 __cdecl v8 :: internal :: Factory :: AllocateRawArray (int, enum v8 :: internal :: PretenureFlag) __ptr64 + 61
12: 00007FF7763D87E2 privado: clase v8 :: interno :: Handle__cdecl v8 :: internal :: Factory :: NewFixedArrayWithFiller (enumeración v8 :: internal :: Heap :: RootListIndex, int, class v8 :: internal :: Object * __ptr64, enum v8 :: internal :: PretenureFlag) __ptr64 + 66
13: 00007FF77641B0BA público: clase estática v8 :: interno :: wasm :: AsmType * __ptr64 __cdecl v8 :: interno :: wasm :: AsmType :: Void (void) +69050
14: 00007FF776407A06 clase v8 :: interno :: MaybeHandle__cdecl v8 :: internal :: BigIntLiteral (clase v8 :: internal :: Isolate * __ptr64, char const * __ptr64) +127094
15: 00007FF77649AFA0 public: static int __cdecl v8 :: internal :: StoreBuffer :: StoreBufferOverflow (clase v8 :: internal :: Isolate * __ptr64) +64256
16: 000001D7B1850481
npm ERR! código ELIFECYCLE
npm ERR! errno 134
npm ERR! Estado de salida 134
npm ERR!
npm ERR! Probablemente esto no sea un problema con npm. Es probable que haya una salida de registro adicional arriba.

Desafortunadamente, me enfrento al mismo problema. Antes de actualizar a 7+, pude construir la aplicación Angular en el entorno azul de DevOps. Ahora no es posible. Recibo el siguiente error:

ERROR FATAL: Mark-compacts ineficaz cerca del límite de almacenamiento falló en la asignación: el montón de JavaScript no tiene memoria
1: 00007FF7B388F04A v8 :: interno :: GCIdleTimeHandler :: GCIdleTimeHandler + 5114
2: 00007FF7B386A0C6 nodo :: MakeCallback + 4518
3: 00007FF7B386AA30 registro_módulo_nodo + 2032
4: 00007FF7B3AF20EE v8 :: interno :: FatalProcessOutOfMemory + 846
5: 00007FF7B3AF201F v8 :: interno :: FatalProcessOutOfMemory + 639
6: 00007FF7B4012BC4 v8 :: interno :: Heap :: MaxHeapGrowingFactor + 9556
7: 00007FF7B4009C46 v8 :: interno :: ScavengeJob :: operador = + 24310
8: 00007FF7B400829C v8 :: interno :: ScavengeJob :: operador = + 17740
9: 00007FF7B4010F87 v8 :: interno :: Heap :: MaxHeapGrowingFactor + 2327
10: 00007FF7B4011006 v8 :: internal :: Heap :: MaxHeapGrowingFactor + 2454
11: 00007FF7B3BCCDB7 v8 :: interno :: Fábrica :: NewFillerObject + 55
12: 00007FF7B3C62CC6 v8 :: interno :: WasmJs :: Instalar + 29414
13: 0000035C75D5C5C1
npm ERR! código ELIFECYCLE
npm ERR! errno 134

@vindemi , necesitará editar su node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod asegúrese de configurar su directorio de trabajo en la carpeta con su package.json.

@vindemi , necesitará editar su node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod asegúrese de configurar su directorio de trabajo en la carpeta con su package.json.

está funcionando gracias

También es de destacar que Node.js 12 configura automáticamente sus opciones de memoria en función de la memoria del sistema disponible.

¿Funcionó esta solución para alguien? Sigo recibiendo el mismo error en el proceso alojado VS2017 en Azure. Aquí está mi YAML para el paso. ¿Cuál es la causa fundamental de esto? Al ejecutar esto incluso localmente en un robusto I7, obtengo un 100% de CPU y casi 5 GB de uso de RAM. ¿Hay algo que necesite refactorizar? Tengo un montón de componentes estándar con MENOS archivos.

`pasos:

• guión: |
  nodo --max_old_space_size = 8192
  $ (Build.SourcesDirectory) node_modules.binng.cmd compilación --prod
  displayName: 'Script de línea de comando'
  '

Error:

`## [sección] Inicio: Script de línea de comandos

Tarea: Línea de comandos
Descripción: Ejecute una secuencia de comandos de línea de comandos con cmd.exe en Windows y bash en macOS y Linux.
Versión: 2.148.0
Autor: Microsoft Corporation

Ayuda: más información

Generando guión.
========================== Salida de comando de inicio ===================== ======

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

Browserslist: caniuse-lite está desactualizado. Ejecute el siguiente comando yarn upgrade caniuse-lite browserslist
ERROR FATAL: Mark-compacts ineficaz cerca del límite de almacenamiento falló en la asignación: el montón de JavaScript no tiene memoria
1: 00007FF747A7F04A v8 :: interno :: GCIdleTimeHandler :: GCIdleTimeHandler + 5114
2: 00007FF747A5A0C6 nodo :: MakeCallback + 4518
3: 00007FF747A5AA30 registro_módulo_nodo + 2032
4: 00007FF747CE20EE v8 :: interno :: FatalProcessOutOfMemory + 846
5: 00007FF747CE201F v8 :: interno :: FatalProcessOutOfMemory + 639
6: 00007FF748202BC4 v8 :: internal :: Heap :: MaxHeapGrowingFactor + 9556
7: 00007FF7481F9C46 v8 :: interno :: ScavengeJob :: operador = + 24310
8: 00007FF7481F829C v8 :: interno :: ScavengeJob :: operador = + 17740
9: 00007FF748200F87 v8 :: interno :: Heap :: MaxHeapGrowingFactor + 2327
10: 00007FF748201006 v8 :: interno :: Heap :: MaxHeapGrowingFactor + 2454
11: 00007FF747DBCBE8 v8 :: interno :: Fábrica :: AllocateRawArray + 56
12: 00007FF747DC2CFA v8 :: interno :: Fábrica :: NewTransitionArray + 58
13: 00007FF7482A6684 v8 :: interno :: CodeStubAssembler :: InitializeFunctionContext + 26932
14: 00007FF747FDCBFE v8 :: interno :: JSReceiver :: GetOwnPropertyDescriptor + 17550
15: 00007FF747FDCD69 v8 :: interno :: JSReceiver :: GetOwnPropertyDescriptor + 17913
16: 00007FF747FDEB9B v8 :: interno :: JSReceiver :: GetOwnPropertyDescriptor + 25643
17: 00007FF747FCDD94 v8 :: interno :: JSReceiver :: nombre_clase + 4132
18: 00007FF747FDE2D9 v8 :: interno :: JSReceiver :: GetOwnPropertyDescriptor + 23401
19: 00007FF747EAACFE v8 :: interno :: LookupIterator :: PrepareTransitionToDataProperty + 478
20: 00007FF747FD1E11 v8 :: interno :: JSReceiver :: nombre_clase + 20641
21: 00007FF747DACFE9 v8 :: interno :: wasm :: WasmCodeManager :: LookupCode + 17993
22: 00007FF747DB00A4 v8 :: internal :: wasm :: WasmCodeManager :: LookupCode + 30468
23: 0000023D7E05C5C1

[error] Cmd.exe salió con el código '134'.

[sección] Acabado: secuencia de comandos de línea de comandos`

no, tampoco funcionó para mí. Terminé haciendo un trabajo completamente diferente.

Es posible que esté utilizando una clase dentro de sí misma con el mismo nombre.

También ocurre con el angular 8 (rc4). Cuando apago los mapas de origen para la producción, vuelve a funcionar.

Con Angular 8, no puedo construir en Azure . Estoy en el nivel más alto de Azure Web App con 7 GB de RAM (S3). He probado el truco --max_old_space_size=8192 , pero aparece el siguiente error.

He cambiado AOT para producción. Haciendo que mi archivo main.js sea de 3 MB en lugar de 2,5 MB, pero se basa en Azure.
En Azure, el nodo 10.15.2 es el nodo más alto instalado en la máquina en este momento.

#

# 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 Creo que el problema con 8 tiene que ver con una fuga de memoria en las compilaciones de prod con carga diferencial. ¿Puedes intentar desactivarlo? Consulte https://angular.io/guide/deployment#opting -out-of-diferencial-loading

cc @ alan-agius4

@filipesilva Nope. No soluciona nada:

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

Actualicé a Angular 8 esta mañana y comencé a experimentar este problema. Probé la sugerencia de

https://angular.io/guide/deployment#opting -out-of-diferencial-loading

archivo de lista de navegadores

not dead
not IE 9-11

Cambiado a

dead
IE 9-11

archivo tsconfig.json

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

Cambiado a

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

@johannesjo @jsgoupil ¿estás usando sass / scss?

@filipesilva sí.
@ gak10100 , ¿estableciste sourceMap en true en angular.json?

@johannesjo mi sourceMap se establece en false . Lo probé con sourceMap establecido en true y todavía se construye

@ gak10100 y ¿estás usando scss / sass?

Creo que el aumento de los requisitos de memoria podría estar relacionado con el procesamiento sass entonces. Pasamos de node-sass a sass en 8.

¿Puedes seguir las instrucciones en @angular-devkit/build-angular: use sass instead of node-sass (ce15899) para forzar el uso de node-sass lugar?

@johannesjo Sí

También puede intentar usar el nodo 12, ya que debería aumentar la memoria automáticamente. Si hay suficiente memoria, las compilaciones deberían realizarse correctamente.

Solo para su información, estoy en el nodo v12.3.1

@ gak10100 gracias.

Probé todas las combinaciones de lo siguiente:
nodo: 10.15.3 / 12.3.1
angular: 7,4, 8,0
os: win10 / ubuntu18.04

Todos dan como resultado el mismo error.

Tengo una computadora portátil para juegos bastante poderosa, por lo que la memoria y la potencia de la CPU normalmente no deberían ser un problema.
El código del proyecto es de código abierto y se puede consultar aquí: https://github.com/johannesjo/super-productivity

La actualización del nodo 10 al nodo 12 resolvió mi problema de memoria de compilación al usar Angular 8.

Sin embargo, cuando intento ejecutar el código compilado desde ng build --prod, solo muestra una pantalla en blanco: / Aunque funciona bien con ng serve

@johannesjo ¡Estoy muy, muy agradecido por la repro! Es muy difícil encontrar repros para estos problemas.

@filipesilva Probé muchas cosas aquí (me tomó bastante tiempo reunir esto). Yo uso SASS.

Con --max_old_space_size:
ES2015 AOT ON => falla con el proceso fatal OOM en memoria insuficiente para crear un aislamiento
ES2015 AOT OFF => éxito
ES5 AOT ON => falla con el proceso fatal OOM en memoria insuficiente para crear un aislamiento

Sin --max_old_space_size
ES2015 AOT ON => falla con marca ineficaz compactos cerca del límite de almacenamiento dinámico Error en la asignación
ES2015 AOT OFF => éxito
ES5 AOT ON => falla con marca ineficaz, compactos cerca del límite de almacenamiento dinámico Error en la asignación
ES5 AOT OFF => éxito

Esta lista de navegadores, no estoy seguro de dónde la está eligiendo, actualicé una aplicación grande, así que la actualización o cualquier cosa sobre el esquema no funcionó correctamente, así que actualicé todo manualmente.
Traté de colocarlo en la carpeta raíz. No cambia nada.

Como se mencionó, Azure no tiene el Nodo 12. Pero solo el Nodo 10. Quiero repetir, esto está en Azure, una máquina S3.

Nunca he usado la bandera --aot. Yo uso la bandera --prod. Usé angular.json con "aot" y "buildOptimizer" configurados en verdadero. Moví mi aplicación de Angular 6.0.4 a 8.0.0.

@johannesjo Probé tu repositorio, aquí están mis resultados.

Primero actualicé manualmente a CLI y construí el último establo angular. La actualización está en https://github.com/filipesilva/super-productivity/tree/benchmark-8.

Esto es lo que veo por 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

Luego ejecuté una herramienta de referencia personalizada que tenemos en este repositorio para medir el uso de recursos para los comandos.

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)

Así que veo un uso máximo de memoria justo por debajo del límite predeterminado de 1,7 g. No entiendo muy bien cómo está alcanzando el límite de memoria de su máquina. ¿Hay algo más sobre su entorno en lo que pueda pensar? Quizás enlaces simbólicos en alguna parte.

@jsgoupil No estoy en Azure, pero hice mis pruebas en una máquina con Windows. Se espera que AOT requiera más memoria principalmente porque es una construcción más compleja. Ahí está sucediendo más.

Pero sus resultados me parecen interesantes. Dices que without --max_old_space_size + AOT off las construcciones se realizan correctamente. Así que tienen éxito con menos de 1,7 g de memoria (el valor predeterminado por ahora). Pero dices que with --max_old_space_size=8192 + AOT on , siempre falla.

Entonces, la compilación AOT está ocupando al menos 5 veces más memoria. Lo cual no creo que sea muy razonable. Me refiero a 2x que podría imaginar para una configuración de TS increíblemente compleja, pero 5x es demasiado. Creo que es más probable que haya una fuga de memoria en el compilador o algo tonto.

¿Tiene algún repositorio que podamos ver? Incluso si solo se comparte en privado.

Hola @filipesilva , gracias por estar dispuesto a investigar esto. Puedo compartir mi repositorio, de hecho es privado y está en Bitbucket. Puedo construir AOT en mi máquina con Windows con el Nodo 12. Me lleva bastante tiempo pero funciona. No estoy acostumbrado a tomar evaluaciones comparativas y comprobar todas esas cosas.
¿Puedes ir a mi perfil y enviarme un correo electrónico rápido? Puedo configurarlo.

@filipesilva gracias por comprobar esto.

No estoy seguro de entenderte correctamente.

Primero: ¿Estoy asumiendo correctamente que en su máquina la compilación está funcionando bien? ¿O es simplemente que técnicamente _no debería_ fallar de acuerdo con el punto de referencia?

Segundo: ¿Te refieres a un repositorio de otra aplicación angular? ¿Quizás los registros de compilación de travis también sean útiles? Si no me equivoco, deberían ser públicos de todos modos:
https://travis-ci.org/johannesjo/super-productivity/builds/539736050
Los resultados parecen ser los mismos, a pesar de que la compilación de mac se está tomando su tiempo nuevamente :)

Por favor, avíseme si puedo brindarle algo más de ayuda.

Creo que el aumento de los requisitos de memoria podría estar relacionado con el procesamiento sass entonces. Pasamos de node-sass a sass en 8.

¿Puedes seguir las instrucciones en @angular-devkit/build-angular: use sass instead of node-sass (ce15899) para forzar el uso de node-sass lugar?

Instalé node-sass como una dependencia de desarrollo, pero aún experimenté un consumo de memoria increíblemente alto. Nuestras compilaciones utilizan más de 12 GB.

No estoy seguro de si esto ayudará, pero aquí hay un gráfico de nuestro consumo de memoria.

El primer pico es una compilación predeterminada con carga diferencial. El segundo pico es la carga diferencial usando node-sass.

El pico final es una construcción con carga diferencial desactivada.

Ambas compilaciones con carga diferencial fallaron después de alcanzar el límite de memoria del servidor. La última construcción fue exitosa.

Tenemos alrededor de 20 proyectos diferentes definidos en nuestro angular.json. Normalmente fallaría al construir el segundo o tercer proyecto.

A continuación se muestran dos problemas más relacionados con la desaceleración en la versión 8. Los siguientes tienen registros y una reproducción también.

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

@ Troyd-Destin lo mismo que tú, ¿resolviste tu problema?

Oigan todos,

Solo quiero darle una actualización sobre este tema. Lo he estado investigando para ver si puedo encontrar algo. A continuación se muestran mis hallazgos hasta ahora.

Depurando la situación de la memoria en CLI 8

Ambiente:

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

Medir el uso de la memoria

Tenemos un paquete de evaluación comparativa privado para la CLI https://github.com/angular/angular-cli/tree/master/packages/angular_devkit/benchmark.

Para instalarlo, clone el repositorio CLI, luego ejecute y siga estos comandos:

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

El nombre de archivo del último comando puede cambiar, según la versión de la CLI que clone.

Para usarlo, ejecute benchmark -- command . El comando dependerá del proyecto que utilice. Para comparar una compilación de producción, haga benchmark -- ng build --prod .

También puede hacer benchmark --iterations 20 -- ng build --prod para obtener un tamaño de muestra más grande (20 en lugar de 5).

Metodología

He reunido un montón de proyectos de varios tamaños y he configurado una carpeta v7 y v8 para cada uno.

Para obtener las diferentes versiones, primero actualizo un proyecto a la versión 8 siguiendo https://update.angular.io/. Esa es la variante v8.

Luego hago la variante v7 reemplazando:

• @angular-devkit/build-angular versión desde ~0.800.0 a 0.13.8
• @angular/cli versión desde ~8.0.1 a 7.3.9
• target en ./tsconfig.json desde es2015 a es5 .

Para cambiar entre las versiones de nodo utilicé NVM. Para deshabilitar la carga diferencial (DL) cambié target en ./tsconfig.json de es2015 a es5 .

En cada uno hago benchmark -- ng build --prod , luego comparo los resultados.

Matriz de referencia:

• v8, DL, nodo 10.10.0
• v8, DL, nodo 12.3.1
• v8, sin DL, nodo 10.10.0
• v8, sin DL, nodo 12.3.1
• v7, nodo 10.10.0
• v7, nodo 12.3.1

Resultados

nuevo proyecto

Desde ng new new-project

Generado con Angular CLI 8.0.1

• v8, DL, nodo 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, nodo 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, sin DL, nodo 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, sin DL, nodo 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, nodo 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, nodo 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)

Superproductividad

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

Proporcionado por @johannesjo en https://github.com/angular/angular-cli/issues/13734#issuecomment-497393904

• v8, DL, nodo 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, nodo 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, sin DL, nodo 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, sin DL, nodo 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, nodo 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, nodo 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)

Mis conclusiones son este punto son:

• Veo un mayor uso de memoria solo por usar el Nodo 12:
  
  
  
  • La superproductividad mostró un pico de 1753 MB en v8, DL, Node 10.10.0 frente a 2335 MB v8, DL, Node 12.3.1
  
  
• Veo aproximadamente un 15% de uso de memoria adicional entre v7 y v8 para el mismo caso (no DL):
  
  
  
  • La superproductividad mostró un pico de 1664 MB en v8, no DL, Node 10.10.0 frente a 1456 MB v7, Node 10.10.0
  
  
  • La superproductividad mostró un pico de 2064 MB en v8, no DL, Node 12.3.1 frente a 1892 MB v7, Node 12.3.1
  
  
• En Windows, el uso máximo del proceso es siempre 1. Nuestro complemento minificador (Terser) es lo único que utiliza procesos adicionales. Creo que no los está usando en Windows, no sé por qué. Quizás lo investigue más tarde. Pero no es muy relevante para el uso de la memoria porque paralelizar algo siempre usará más memoria, incluso si no es mucha. Sin embargo, podría estar relacionado.

He reunido algunos repositorios de ejemplo más, pero después de hacer todos estos puntos de referencia manualmente, creo que tengo que automatizar esto. Realmente debería haberlo automatizado desde el principio. Así que configuraré un repositorio que haga esto usando CI.

bueno, en realidad tenemos un proyecto en el que la configuración max_old_space_size=8192 funcionó, pero falló con max_old_space_size=4096 , sin embargo, con 8192 el uso de memoria alcanzó su punto máximo en alrededor de 4-6 g por cierto. usamos max_old_space_size=2048 con angular v7.x.

Estoy bastante seguro de que hay una fuga. ¿Quizás solo sucede con build-optimizer ?

¿Hay noticias? soluciones alternativas? ¿Necesitan más puntos de referencia?

Este también es un problema al que nos enfrentamos con https://github.com/vmware/clarity en la rama maestra en este momento. No podemos crear e implementar nuestro sitio web porque nos quedamos sin memoria y otros problemas de SSR. Para ver problemas de memoria, ejecute npm run website:prerender para activar la construcción del sitio web.

Heya, he puesto los resultados y la metodología en https://github.com/filipesilva/angular-cli-perf-benchmark. Agregará más proyectos allí la próxima semana.

El único detalle adicional que tengo es que en el proyecto awesome-angular-workshop tiempos de construcción casi se duplicaron de CLI 7 a 8. Pero no fue así en los otros proyectos que probé.

Si alguien quiere seguir la metodología utilizando los scripts, debería ser bastante fácil. Si encuentra algo interesante, hágamelo saber. Si tiene un proyecto grande que cree que podría generar puntos de referencia interesantes, hágamelo saber (o agregue un PR) y lo agregaré allí.

mismo problema aquí en
Darwin Miguels-MacBook-Pro.local 17.7.0 Darwin Kernel Versión 17.7.0: jueves 20 de diciembre 21:47:19 PST 2018; raíz: xnu-4570.71.22 ~ 1 / RELEASE_X86_64 x86_64

cli angular 5.2.11

Problema de construcción resuelto. La sugerencia es cambiar la lógica de construcción. En lugar de angular ng build use node build

@ arayik-yervandyan Me gustaría mantener esto abierto, ya que hay más en este problema que simplemente aumentar el límite de memoria. Algunos proyectos muestran aumentos desproporcionados en el uso de memoria, y también parece que tenemos memoria que no se libera en compilaciones de carga diferencial.

@filipesilva seguro que no hay problema. Solo para la información, puedo decir que en nuestra versión aumentamos el límite de memoria a 4096 o 8192. No lo recordaba correctamente, pero el problema aún existe y cuando la compilación se cambió de ng build a node build, el proceso de compilación pasó con éxito.

Cuando dices node build , ¿qué quieres decir exactamente?

Creo que quiso decir algo en las líneas de node --max_old_space_size=4096 ./node_modules/@angular/cli/bin/ng build --prod , por lo que el argumento se pasaría al entorno del nodo. Pero hay otros problemas relacionados con este, como la gran cantidad de tiempo y memoria invertidos en la compilación.

Estoy de acuerdo con @ hugo-marello, mi caso de uso es este. Durante un simple ng serve + args, pasé por errores de memoria cada vez que intentaba volver a compilar. La CPU se volvió loca al 100% para mí. Probé la solución estableciendo node --max_old_space_size=4096 ./node_modules/@angular/cli/bin/ng + args y funcionó bien para mí.

Sin embargo, veo tiempos más grandes para recompilar, pero ya no se bloquea. Entonces, siento que algo todavía está mal yendo al angular 8 (+ cli). Por cierto, ya uso el nodo 12.

Terminé de comparar los proyectos que tenía en https://github.com/filipesilva/angular-cli-perf-benchmark.

Al mirar esos resultados, tenga en cuenta esta nota:

Es importante tener en cuenta que la primera compilación de las variantes CLI version 8 with differential loading y CLI version 7 siempre usará más núcleos y ocupará más memoria.
Esto sucede porque terser-webpack-plugin usa tanto procesos paralelos como un caché que se borra al reinstalar los módulos de nodo. Los aciertos de caché no generan procesos adicionales ni realizan ningún trabajo.

Esto es un poco desafortunado y dificulta la lectura de los resultados. Si repito esto en el futuro, intentaré encontrar una manera de siempre romper / ignorar el caché de Terser. En los resultados a continuación, miro principalmente los números con caché, pero también agrego una única comparación sin caché.

A continuación se muestran los resultados. Los valores atípicos están en negrita. N10 y N12 significa Node 10.16.0 y Node 12.4.0 respectivamente. CLI7, CLI8 y CLI8DL significan Angular CLI versión 7, versión 8 y versión 8 con carga diferencial.

Resultados

proyecto cli-ocho

En N12, pasar de CLI7 a CLI8 agrega ~ 20 MB (5%) al uso de memoria y ~ 60 MB (7%) a la memoria máxima.

CLI8DL agrega ~ 190 MB tanto a la memoria como a la memoria máxima, y ​​un tiempo de construcción adicional del 60%.

N10 muestra números similares.

N12 parece utilizar aproximadamente un 6% de memoria adicional sobre N10.

Las compilaciones sin caché en N12 van del uso máximo de memoria de 1063 MB en CLI 7 a 1191 MB en CLI8DL.

superproductividad

En N12, pasar de CLI7 a CLI8 agrega ~ 60mb (5%) al uso de memoria, pero la memoria máxima permanece igual.

CLI8DL agrega ~ 200 MB tanto a la memoria como a la memoria máxima, y ​​un tiempo de construcción adicional del 90%.

N10 muestra números similares.

N12 parece utilizar aproximadamente un 30% de memoria adicional sobre N10.

Las compilaciones sin caché en N12 van del uso máximo de memoria de 2886 MB en CLI 7 a 3131 MB en CLI8DL.

impresionante-taller-angular

En N12, pasar de CLI7 a CLI8 agrega ~ 410 MB (45%) al uso de memoria y ~ 300 MB (30%) a la memoria máxima **.

CLI8DL agrega ~ 200mb tanto a la memoria como a la memoria máxima, y un tiempo de construcción adicional del 150% .

N10 muestra números similares.

N12 parece utilizar aproximadamente un 25% de memoria adicional sobre N10.

Las compilaciones sin caché en N12 van del uso máximo de memoria de 2515 MB en CLI 7 a 2554 MB en CLI8DL.

angular.io

En N12, pasar de CLI7 a CLI8 agrega ~ 50 MB (6%) al uso de memoria y ~ 350 MB (25%) a la memoria máxima.

CLI8DL agrega ~ 270 MB a la memoria, 100 MB a la memoria máxima y un tiempo de compilación adicional del 90%.

N10 muestra números similares.

N12 parece utilizar aproximadamente un 17% de memoria adicional sobre N10.

Las compilaciones sin caché en N12 van del uso máximo de memoria de 2898 MB en CLI 7 a 2243 MB en CLI8DL.

Espartaco

En N12, pasar de CLI7 a CLI8 agrega ~ 290 MB (32%) al uso de memoria y ~ 420 MB (25%) a la memoria máxima.

N10 muestra un 40% de uso de memoria adicional y memoria máxima .

N12 parece utilizar aproximadamente un 27% de memoria adicional sobre N10.

Las compilaciones sin caché en N12 van del uso máximo de memoria de 2011mb en CLI 7 a 2326mb en CLI8.

claridad

En N12, pasar de CLI7 a CLI8 agrega ~ 50 MB (2%) al uso de memoria, pero la memoria máxima permanece igual.

N10 muestra números similares.

N12 parece utilizar aproximadamente un 70% de memoria adicional sobre N10.

Las compilaciones sin caché en N12 pasan de un uso máximo de memoria de 6000 MB en CLI 7 a 5000 MB en CLI8.

Conclusiones

La primera compilación siempre toma más tiempo y usa más memoria debido al almacenamiento en caché de algunos resultados de compilación. En escenarios realistas, la mayoría de las compilaciones invalidarán parte del caché y también tardarán más.

El uso de carga diferencial parece agregar ~ 200 MB al uso de memoria. Este valor no cambia mucho, lo que parece indicar que algo que no depende mucho del tamaño del proyecto se retiene en la memoria entre compilaciones.

El nodo 12 está utilizando entre un 6% y un 70% de memoria adicional que el nodo 10. La mayoría de los proyectos probados mostraron un aumento de ~ 30%.

awesome-angular-workshop sufre un aumento desproporcionado en el uso de memoria (45%) y el tiempo de compilación (150%) de CLI7 a CLI8DL. Esto indica una regresión localizada.

spartacus muestra una mayor diferencia de uso de memoria entre CLI7 y CLI8 en el Nodo 10 en comparación con el Nodo 12. Esto indica que el Nodo 12 está administrando mejor la memoria en algunos casos.

clarity usa un 70% de memoria adicional en el Nodo 12 en comparación con el Nodo 10. Esto indica que el Nodo 12 puede usar mucha más memoria en algunos casos.

Si está en el Nodo 12 y está alcanzando el límite de memoria, debería probar el Nodo 10 por ahora.

Examinaremos la memoria retenida durante las compilaciones de carga diferencial y los valores atípicos como awesome-angular-workshop .

de hecho, estoy bastante seguro de que incluso con "target": "es5" el uso de memoria se ha ido por las nubes. No solo culparía a la carga diferencial por eso. De hecho, culparía a TerserPlugin que puede ser muy ineficaz y en realidad lo es desde el angular 8.

@schmitch por lo que puedo decir, DL representa una cantidad casi estática de memoria extra (~ 200ish). Así que no es genial, pero tampoco gran cosa en la mayoría de los casos.

Con respecto a TerserPlugin, puede desactivarlo con --optimization=false . También puede establecer esta opción en la configuración de prod en angular.json . Pero los casos en los que lo apaga son casos en los que simplemente usaría el modo sin producción en su lugar.

Si bien el nodo 12 intentará configurar automáticamente la opción --max_old_space_size , el método V8 utilizado para hacerlo limitará el valor a 2048 MB .

Informó el nuevo máximo predeterminado de 2048 MB en https://github.com/nodejs/node/issues/28202.

Nodo 12 informado usando más memoria en https://github.com/nodejs/node/issues/28205.

Me encontré con esto hoy al intentar habilitar mapas de origen para mi compilación de producción.

ERROR FATAL: Mark-compacts ineficaz cerca del límite de almacenamiento falló en la asignación: el montón de JavaScript no tiene memoria
1: 0x8dc510 nodo :: Abort () [ng build --prod]

Tuve este error; resulta que fue porque había dejado una carpeta de respaldo node_modules en el directorio de mi proyecto. Eliminarlo solucionó el problema.

Mis compilaciones de Angular están demorando mucho más hoy y algunas incluso fallan con un ERROR FATAL.

de servir --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
nodo v10.13.0
"@ angular / core": "~ 7.2.0"
"@ angular / cli": "~ 7.3.7",

@filipesilva , lo

En mi computadora, pasa, realmente está en Azure que no lo está. En mi computadora, con AOT, obtengo aproximadamente 2GB para la compilación.
Di una oportunidad con AOT activado / desactivado, porque DL no es una preocupación para mí.
He actualizado Angular a 8.0.2.

En Azure, sin AOT, funciona, pero obtengo un Aw Snap sin memoria después de 15 minutos de inactividad en Chrome. No puedo señalar con el dedo a AOT todavía porque me moví de Angular 6 a Angular 8. Además, en mi máquina, no obtengo este complemento de Aw (el código tampoco está minimizado y uso ng serve).

Todo este Angular 8 me está dando bastante dolor de cabeza para ejecutar en producción. Pero queríamos beneficiarnos de una versión superior de TypeScript ...

AOT = activado

[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 = desactivado

[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)

mismo problema en el servidor ubuntu 18.04, pero esto resolvió mi problema:
node --max_old_space_size = 8192 node_modules / @ angular / cli / bin / ng build --prod

Simplemente colocando esto aquí, pero si alguien está usando la compilación de código de AWS, asegúrese de actualizar su entorno de compilación para que se configure con más de la memoria mínima de 3 GB, seguí los pasos anteriores pero tuve que volver a configurar mi entorno con más memoria.

Hola a todos,

Primero que nada perdón por el retraso. Me preocupo por una buena parte de la semana pasada.

Estoy tratando de dar tantos detalles sobre lo que hice para investigar este tipo de problema porque en el pasado me preguntaron al respecto (mirándote @wardbell , @johnpapa y @DanWahlin : wave :). También me resulta útil volver a estos artículos en el futuro porque olvido los detalles de cómo hacer estas cosas, o quiero compartir con colegas para que puedan hacer lo mismo. Mucho del trabajo que se describe aquí se realiza jugando directamente en node_modules y cambiando la lógica allí para escribir archivos que luego depuro, o registro de información, o uso diferentes paquetes, cosas así. Me parece que jugar con las fuentes de JS realmente es la mejor manera de investigar las cosas porque no sé lo que estoy buscando la mayor parte del tiempo, por lo que es útil explorar.

En este punto, ya nos hemos asegurado de que el nodo 12 tiene un límite de memoria predeterminado de 2048 MB (https://github.com/nodejs/node/issues/28202) y está usando más memoria que el nodo 10 (https://github.com / nodejs / node / issues / 28205). Esto es desafortunado pero es una realidad en este momento, por lo que deberíamos centrarnos en el Nodo 10 por ahora mientras la gente del nodo aborda los problemas de memoria. Yo mismo estoy usando Node 10.16.0 para realizar pruebas.

He estado trabajando en perfilar dónde se usa la memoria en las compilaciones problemáticas. El primer paso para hacerlo es decidir de qué proyecto obtener los datos de perfil. Elegí el asombroso taller angular de @johnpapa porque en https://github.com/angular/angular-cli/issues/13734#issuecomment-500849058 llegué a la conclusión de que era el proyecto en el que podíamos ver el mayor impacto :

awesome-angular-workshop sufre un aumento desproporcionado en el uso de memoria (45%) y el tiempo de compilación (150%) de CLI7 a CLI8DL. Esto indica una regresión localizada.

Hice una bifurcación en https://github.com/filipesilva/awesome-angular-workshop, comprometí SHA 9076a3d, con modificaciones locales para obtener puntos de referencia reproducibles fácilmente. Ese es el código que usé en https://github.com/filipesilva/angular-cli-perf-benchmark. El comando de compilación que uso es ng build 5-ngrx-end --prod , ya que este espacio de trabajo tiene varios proyectos y solo quiero usar este específico.

Mi idea inicial era utilizar las herramientas de desarrollo de nodos de Chrome, recopilar una gran cantidad de datos de creación de perfiles y luego intentar explorarlos para encontrar información procesable.

Para abrir las DevTools del nodo de Chrome, abraen Chrome y haga clic en "Abrir DevTools dedicadas para el nodo". Cuando tiene un proceso de nodo iniciado con la bandera --inspect-brk , DevTools debería adjuntarlo automáticamente. Una forma fácil de ejecutar Angular CLI de esta manera es hacer un script npm: "ng-inspect": "node --inspect-brk node_modules/@angular/cli/bin/ng", . Luego, si ejecuta npm run ng-inspect -- build --prod y tiene DevTools abierto, se conectará automáticamente. En este punto, puede establecer puntos de interrupción y tomar perfiles.

La pestaña de memoria tiene un par de herramientas de creación de perfiles diferentes y descripciones de lo que hacen. Cuando los use, tendrá que ir a las fuentes y hacer clic en la ejecución del script de reanudar (arriba a la derecha) antes de que sucedan las cosas. Pasé un tiempo probando los diferentes tipos de perfiles en procesos de nodo más simples para descubrir cuál sería mejor. Ya estaba acostumbrado a leer los perfiles de CPU de cuando depuro el tiempo de compilación, por lo que el muestreo de asignación (también conocido como perfil de pila) sonaba interesante porque debería mostrar cuánta memoria está usando cada función en un momento dado. Las instantáneas de montón muestran lo que hay en la memoria en un momento dado y lo que retiene esos objetos, también funcionaría, pero no es tan fácil de leer y obtener una imagen general de lo que está sucediendo.

Para ser honesto, capturar perfiles con DevTools ha sido mucho más difícil de lo que esperaba. En realidad, no parece funcionar bien con la captura de perfiles de grandes procesos de Node en ejecución. Lo vi fallar al tomar perfiles, o al final al procesarlos, para la mayoría de los perfiles que intenté tomar.

Intenté explorar alternativas. Uno de ellos era perfilar partes más pequeñas a la vez para que DevTools no se bloqueara, pero parecía que siempre se bloquearía en algunos tipos de perfiles de todos modos, incluso en nuevos proyectos CLI, por lo que eso no pareció importar mucho. Probé ndb pero parecía sufrir los mismos problemas. El perfil automatizado de Chrome parecía prometedor, pero no se había actualizado en un tiempo y solo tomaba perfiles de CPU. @manekinekko sugirió, pero por lo que pude ver, no me daría información muy detallada sobre el uso de la memoria. node-oom-heapdump se veía bien para las instantáneas del montón, pero requería enlaces nativos, lo que no me gustó mucho porque dificultaría la integración posterior directamente en la CLI para la creación de perfiles de usuario. sample-heap-profiler se veía genial para los perfiles de montón, pero también necesitaba enlaces nativos. @ofrobots sugirió https://github.com/google/pprof-nodejs que probé y pareció darme visualizaciones realmente agradables, pero también necesitaba enlaces nativos y necesitaba una herramienta para leerlo, lo que dificultaría la integración .

Al final, opté por crear un código de creación de perfiles personalizado basado en el soporte del generador de perfiles experimental de Node que se describe aquí . Me inspiré en el código de Sample-Heap-Profiler y la API Profiler para averiguar qué usar. A partir de esto, hice un prototipo de un código de creación de perfiles automatizado que se parece a https://github.com/angular/angular-cli/pull/14936. En el momento de escribir este artículo, controlo manualmente las banderas dentro del archivo, pero tal vez en el futuro podamos exponerlo de alguna manera. Puede tomar perfiles de CPU de todo el proceso, o apilar instantáneas / perfiles a intervalos establecidos. Esta parecía una buena forma de hacerlo porque en el futuro podría pedir a las personas con problemas de memoria o velocidad de construcción que tomaran estos perfiles y nos los enviaran.

Con esta configuración, pude tomar perfiles reproducibles con un mínimo de manipulación. Reducir el violín es realmente importante cuando se necesita mucho tiempo para recopilar su información, porque cuanto más manipule el violín necesita hacer, mayor será la probabilidad de que estropee una muestra determinada. Si estropea una muestra y solo la encuentra horas más tarde, es posible que deba descartar la mayoría de sus conclusiones para ese período, ya que sus puntos de partida fueron malos y, por lo tanto, las conclusiones y las comparaciones no fueron precisas.

Armado con esta herramienta necesaria, logré capturar algunos perfiles de montón de compilaciones CLI7 y CLI8 (sin carga diferencial) para compararlos. Los abrí en DevTools e intenté averiguar qué partes del proceso de compilación estaban involucradas en cada sección del perfil.

El CLI7 se veía así:

El CLI8 se veía así:

CLI8 usa alrededor de 180 MB más de memoria, para un total de 760 MB, en comparación con los 580 MB que usa CLI7. Lo que más me llamó la atención fue la diferencia en el procesamiento de CSS. Parece que lleva mucho más tiempo en CLI8. En CLI8 comenzamos a usar dart-sass (publicado en npm como solo sass ) de forma predeterminada en lugar de node-sass (consulte https://github.com/angular/angular-cli/pull/11791, https: //github.com/angular/angular-cli/pull/13950) por lo que es un gran candidato para la investigación.

Esperábamos que dart-sass no tuviera el mismo rendimiento que node-sass por lo que le permitimos volver a node-sass instalándolo en su proyecto ( npm install node-sass --save-dev ). Siempre que esté instalado, lo recuperaremos automáticamente. También puede usar dart-sass con el paquete de fibras para un mejor rendimiento instalándolo de la misma manera que node-sass . Tanto node-sass como fibers usan enlaces nativos y es posible que no funcionen en todas las máquinas, por lo que no los instalamos de forma predeterminada.

Luego comparé los perfiles de CLI8, CLI8 con node-sass , CLI8 con fibers y CLI 7 uno al lado del otro para ver cómo cambiaban.

Por lo tanto, el uso de node-sass parece devolver el uso de memoria a niveles CLI7, al menos en este proyecto. Usar solo fibers solo reduce la memoria en unos 20 MB.

Como señaló @clydin , esta podría no ser la imagen completa ya que los perfiles de pila son solo para la memoria administrada por V8. node-sass podría estar usando más memoria que no aparece en el perfil. Así que comparé los procesos en sí:

• 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 con 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 con 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)

Así que parece que el node-sass realmente es el que usa menos memoria y lleva menos tiempo compilar. fibers es el segundo mejor. Sin embargo, la memoria promedio utilizada en el caso fibers parece entrar en conflicto con los resultados que obtuvimos de los perfiles del montón, aquí vemos CLI8 con fibers usando ~ 750mb frente al CLI8 original ~ 1000mb, pero en el perfil de pila usando fibers solo redujo la memoria en ~ 20mb. No sé por qué es esto. Tal vez sea por la naturaleza de promediar la memoria usada, o tal vez sea porque hay más ciclos de recolección de basura que toman perfiles de montón. Pero al final del día node-sass parece ser el ganador en lo que respecta al rendimiento.

También me pareció extraño que una gran parte de la memoria adicional en el perfil del montón de CLI8 pareciera provenir del procesamiento PostCSS. No esperaba que PostCSS tuviera que hacer algo diferente. Pensé que tal vez simplemente malinterpreté para qué se usaba esa sección. Pero quizás la salida de dart-sass podría ser diferente de node-sass y eso podría causar más trabajo para PostCSS. Valió la pena investigarlo, así que agregué un código directamente en sass-loader para escribir los resultados de la compilación de sass en el disco. La salida para dart-sass y node-sass parecía que era la misma en realidad, aparte de algunos espacios en blanco, así que creo que malinterpreté la memoria asignada al procesamiento de Sass como asignada a PostCSS.

@johnpapa , aparte, noté que la mayoría de los archivos CSS de componentes en este proyecto están importando mixin.scss . En realidad, este archivo ~ no tiene mixins y solo ~ incluye todo el tema del material a 70 kb (optimizaciones previas) de definiciones CSS de nivel superior. El componente CSS es independiente y está aislado de otros CSS, por lo que no hay deduplicación ni nada. Cuando se importa en el componente CSS, está agregando 70 kb de CSS en ese componente, que probablemente supere varias veces el tamaño del componente en sí. @jelbourn ha descrito la importación de Sass no

Otro aparte es que también noté que compilar solo un proyecto a través de ng build 5-ngrx-end --prod realidad compila todos los archivos .ts y .scss dentro de src/ . Esto sucede porque todos los proyectos en este espacio de trabajo usan el mismo ./src/tsconfig.app.json , y este tsconfig incluye todos los archivos ts (excepto las pruebas unitarias). Es decir, compilar un solo proyecto aquí compila todos los proyectos. La única forma de abordar realmente esto es tener un tsconfig para cada aplicación. Me pregunto qué tan común es este error. No me sorprendería que los proyectos más grandes incluyan accidentalmente archivos TS adicionales. Tal vez podamos advertir a los usuarios cuando veamos que la compilación de TS tiene muchos más archivos que los que carga el paquete web (cc @vikerman , @clydin).

Así que supongo que la conclusión aquí es que si tienes un proyecto grande, debes instalar node-sass en tus devDependencies. Esto hará que la construcción sea más rápida y consumirá menos memoria.

Aunque no pareció cambiar entre CLI7 y CLI8, la compilación Angular en sí sigue siendo, con mucho, el mayor contribuyente a la huella de memoria, alrededor de 230 MB. Tal vez podamos eliminar por completo todas las referencias cuando no se esté construyendo en modo reloj, permitiendo que Node libere esa memoria. Exploraré eso a continuación.

@filipesilva solo una breve actualización: intenté usar node-sass con angular 8 para obtener superproductividad. El resultado es el mismo:

• todas las compilaciones funcionan sin mapas de origen
• ng build --aot & ng serve ambos funcionan con mapas de origen
• ng build --prod arroja el error JavaScript heap out of memory

Probé el Nodo 10 y el 12. Los resultados son los mismos.

@johannesjo ng build --aot y ng serve son muy diferentes a ng build --prod . No creo que se gane nada comparándolos. Las compilaciones de producción siempre usarán más memoria que las compilaciones que no son de producción.

Cuando comparé super-productivity obtuve estos resultados para el nodo 10.16.0:

• CLI versión 8 con carga diferencial

[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 versión 8 sin carga diferencial

[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 versión 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)

Para las compilaciones de producción, no vi una diferencia real entre "CLI versión 7" y "CLI versión 8 sin carga diferencial". Sin embargo, hay una diferencia de ~ 200mb cuando se usa la carga diferencial. Pero parece que no está utilizando la carga diferencial actualmente (su tsconfig raíz tiene un objetivo es5).

Sin embargo, podríamos estar comparando cosas diferentes. Estoy comparando el uso de Angular 8 con CLI 7 y 8. Si está probando con Angular 7 y Angular 8, es posible que obtenga resultados diferentes. ¿Qué comparación estás haciendo? ¿Tiene dos confirmaciones que pueda ver donde solo cambió la versión de los paquetes Angular, pero ng build --prod pasó de completarse correctamente a fallar sin errores de memoria?

@filipesilva La configuración crucial parece ser la bandera buildOptimizer (o es al menos la que tiene el mayor impacto en el uso de la memoria). Cuando lo desactivo. La compilación se ejecuta bien independientemente de los otros parámetros de configuración incluso con sourceMap establecido en verdadero.

No tengo idea de cómo funcionan todos los componentes internos, por lo que probablemente esto no sea demasiado útil, pero mis conjeturas sobre la causa serían las siguientes:

• Las optimizaciones de compilación se ven afectadas de alguna manera por la existencia de los mapas fuente o el código relacionado dentro del CSS.
• La extracción del mapa de origen se ejecuta en paralelo con las optimizaciones de compilación
• La extracción del mapa de origen se ejecuta antes de las optimizaciones de compilación, pero la memoria no se limpia hasta que se ejecuta toda la tarea de compilación o viceversa.
• Ambos procesos están de alguna manera entrelazados

Tal vez haya algo de inspiración sobre la causa real;)

@johannesjo, tanto el optimizador de compilación como los mapas de origen, necesitan memoria adicional para procesar, por lo que se espera. Es solo más trabajo por hacer y más datos intermedios para almacenar en la memoria. Estamos buscando mover el paso del Optimizador de compilación de compilaciones de aplicaciones a compilaciones de bibliotecas, pero eso sería en 9 solo en el mejor de los casos.

Editar: etiquetado @JohannesHoppe en lugar de @johannesjo. ¡Lo siento por eso!

Sigo trabajando en este problema. Notas de los últimos días a continuación.

Mientras lo discutía con @clydin , mencionó que la memoria promedio no es realmente lo que rompe el límite. Es el recuerdo máximo. El promedio es ~ 750 MB mientras que el pico es ~ 1500 MB. En cambio, deberíamos centrarnos en eso.

Primero necesito averiguar qué está usando la memoria en el pico. Supongo que es feo y optimizador de compilación, pero no lo sé. Sin embargo, es extraño que los perfiles que tomo nunca muestren un uso máximo. Me pregunto si estoy haciendo algo mal allí. Acabo de iniciar un proceso sin ningún perfil y veo la memoria en ~ 1200 durante lo que parece ser la compilación ng, luego bajé a ~ 900mb al cargar archivos, luego ~ 1300 y ~ 1500mb en las etapas del 90% +. Pero mis perfiles muestran una asignación máxima de ~ 800 MB.

Tal vez necesito controlar el momento en que tomo estos perfiles. Si eso es todo, entonces necesito encontrar el momento exacto en que el uso es alto y tomar un perfil allí. El uso de process.memoryUsage() como se describe en https://www.valentinog.com/blog/memory-usage-node-js/ podría permitirme identificar los períodos de alto uso de memoria. Puedo establecer un umbral de memoria y solo tomar perfiles en ese momento.

Puede ser que tomar un perfil de montón active GC, o simplemente que el aumento del tiempo de ejecución solicite GC con más frecuencia. Puedo intentar activar gc justo antes de cada perfil de montón y ver si el resultado es el mismo. https://stackoverflow.com/questions/27321997/how-to-request-the-garbage-collector-in-node-js-to-run muestra cómo. Hice eso y no vi ninguna diferencia real en los perfiles. Lo que sea que muestren los perfiles, parece que se conserva.

Usé setInterval con un registro para process.memoryUsage () dentro, y también estuve atento al uso de memoria del administrador de tareas informado, y noté un par de cosas. Cuando digo que vi 1234/5678, me refiero a que 1234 estaba en el administrador de tareas y 5678 estaba en el proceso de registro de memoria.

El 1300 más alto / ???? sucedió durante la fase del compilador angular, pero solo con dart-sass. Con node-sass, baja a 900/700 y registra el intervalo de corte. Casi no tengo registro para esa fase con dart-sass, creo que porque el setInterval nunca entró correctamente en el ciclo de eventos, supongo que porque muchas cosas están sincronizadas. Con node-sass vi muchos registros en ese momento. Tal vez sea un enlace nativo, podría liberar el bucle de eventos. De todos modos, dart-sass parece hacer que la carga de recursos en el compilador angular sea más mala al acumular memoria en un conjunto de operaciones ya caro.

Vi algunos picos de 1200/900 mientras el progreso mostraba la carga de archivos individuales. Creo que eso es Build Optimizer ya que es un cargador js.

Apenas vi uso de memoria durante Terser, pero apuesto a que es por el caché. Apagué el caché terser-webpack-plugin y vi 1100/940, pero también un montón de procesos generados entre 40 y 400 MB.

Por lo que pude ver, lo sass fue en realidad una gran parte de alcanzar el pico porque se ejecuta durante la compilación ng y se acumula en algo que ya consume mucha memoria.

Apuesto a que tampoco ayuda que estemos haciendo subcompilaciones de paquetes web para eso. Esto también significa que incluso si liberáramos todas las referencias al uso de la memoria durante la compilación ng, no importaría tanto porque esa compilación sigue siendo parte del pico.

Ya tenemos planes para eliminar Build Optimizer para que no me moleste mucho.

Con respecto a terser ... Bueno, si tuviéramos una huella de memoria de proceso principal más pequeña, obviamente el total se reduciría. Pero tal vez también podamos hacer que ese complemento sea más inteligente. Parece que se ejecuta en trozos adecuados
https://github.com/webpack-contrib/terser-webpack-plugin/blob/a0d83170168e786004fa12b94525b2934a17a4f5/src/index.js#L416 -L419
Pero sabemos que terser no puede salir del cargador del módulo de paquete web, por lo que no tiene sentido procesar fragmentos completos. También podría procesar los módulos individuales del paquete web, que deberían ser mucho más pequeños.

Cosas tan importantes a seguir:

• mejorar el rendimiento de terser-webpack-plugin (https://github.com/webpack-contrib/terser-webpack-plugin/issues/104)
• mejorar el rendimiento del cargador sass (https://github.com/webpack-contrib/sass-loader/issues/701)
• reducir el uso máximo de memoria ngc
• memoria ngc libre después de emitir
• eliminar optimizador de compilación

Finalmente, como sugirió el otro, ejecutar node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod soluciona el problema y node.exe podría usar hasta 5.5 GB de memoria para compilar mi gran aplicación NG. Aparentemente, la compilación de Angular 8 usa mucha más memoria que la compilación de Angular 7.

ahora para la compilación de depuración, uso:
node --max_old_space_size=8192 "node_modules/@angular/cli/bin/ng" build --base-href /ng/ --aot

para la construcción de producción, uso:
node --max_old_space_size=8192 "node_modules/@angular/cli/bin/ng" build --configuration=production

Sin embargo, preferiría usar ng build ... lugar de ` node --max_old_space_size=8192 "node_modules/@angular/cli/bin/ng" build .

Sería bueno que el equipo CLI de NG haga ng build read max_old_space_size en algún lugar de la configuración.

Por cierto, con una base de código casi idéntica antes de pasar a NG8, el uso de memoria del nodo con la compilación NG7 es de 1,3 GB. Había visto que los demás habían informado de un uso excesivo de memoria en la compilación de NG 8.

@zijianhuang pasar de 1.3 a 5.5 es mucho más que en otros proyectos que he probado. ¿Está su proyecto en algún lugar al que pueda ver para ejecutar algunos puntos de referencia? Además, ¿qué versión de Node estás usando?

@filipesilva , si pudiera proporcionar una ubicación de carga segura o su dirección de correo electrónico, puedo comprimir los códigos ng7 y el código ng8 para que pueda construir ambos y comparar. Node y npm son básicamente los últimos.

Me encantaría echarle un vistazo. ¿Por qué tienes un proyecto privado de github al que me concedes acceso? Los privados ahora son gratuitos para hasta tres colaboradores por lo que no pagarías nada. También puede eliminar el acceso en cualquier momento.

En mi caso, una gran diferencia es tener es2015 como destino en el tsconfig.json , no pude usar su herramienta de referencia (no he encontrado en ninguna parte cómo usarla) pero con time el rss máximo de es5 es 1.3GB con es2015 5.9GB, después de pasar de node10 + angular7 a node12 + angular8 todas nuestras compilaciones fallaron debido al uso de memoria

@filipesilva , invitación enviada. Por favor, verifique también mi resultado de referencia en readme.txt.

@ alex88 puede encontrar la herramienta de referencia que utilicé en https://github.com/filipesilva/angular-cli-perf-benchmark#benchmark -package. Si desea proporcionarme una reproducción a través de un repositorio privado de github, también me encantaría echarle un vistazo.

@zijianhuang un gran agradecimiento por darme una reproducción para mirar. Lo eché un vistazo hoy usando el paquete de referencia descrito en https://github.com/filipesilva/angular-cli-perf-benchmark.

Una cosa a tener en cuenta es que los números de memoria recopilados por esa herramienta incluyen procesos generados. En la CLI usamos un paquete minificador ( terser-webpack-plugin ) que genera múltiples procesos, por lo que también es útil capturar la memoria que usan los procesos secundarios.

Pero ese paquete también almacena en caché los resultados de la minificación. Entonces, la primera ejecución hace más trabajo que las siguientes. Entonces, cuando comparé sus paquetes, edité manualmente ./node_modules/@angular-devkit/build-angular/src/angular-cli-files/models/webpack-configs/common.js y cambié cache: true a cache: false para deshabilitar ese caché y obtener números consistentes.

También agregué estos dos scripts npm para ayudarme a comparar cosas:

        "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",

Establezco el mismo límite de memoria para todos los proyectos porque sé que Node se comportará de manera diferente cerca del límite. Entonces, de esta manera deberíamos obtener números más precisos.

Tuve que eliminar la importación Bounds de avatar.component.ts porque eso me dio un error de compilación en NG7. Solo se usó como tipo, por lo que fue fácil de quitar. Reemplacé "target": "es2015" con "target": "es5" en ./tsconfig.json . Esto deshabilita la carga diferencial como se describe aquí . Sé que es una parte importante de las aplicaciones CLI8, pero ya estamos viendo una implementación diferente que no debería requerir tantos recursos, por lo que no quería compararlo también. De esta manera podría comparar aplicaciones en su mayoría iguales.

Noté que su package.json entre las dos versiones cambia muchos paquetes que no son solo los paquetes Angular. Eso podría tener un impacto en los puntos de referencia. Después de intentar reproducir sus números iniciales, también intentaré alterar solo los paquetes angulares para ver si obtengo resultados diferentes.

Entorno de desarrollo

En tu reproducción tu dijiste:

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

Benchmarking tool: Process Explorer

Estoy usando mi máquina de trabajo (Win10, i7, 16GB RAM, SSD) que parece similar a su env. Para comparar utilicé la herramienta mencionada en https://github.com/filipesilva/angular-cli-perf-benchmark#benchmark -package. También estoy usando Node 10.16.0 y npm 6.9.0.

Tus casos de prueba

En tu reproducción tu dijiste:

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

Realmente no voy a probar Test case 3 porque ya sabemos que el Nodo 12 está usando más memoria en general (https://github.com/nodejs/node/issues/28205). No creo que podamos hacer mucho al respecto.

Su Test case 1 es el escenario CLI7/NG7/NG7deps . También digo NG7deps porque esas dependencias son diferentes de su proyecto NG8, que diré que tiene NG8deps. Más adelante, eso podría marcar la diferencia. Idealmente, solo cambiaríamos CLIx / NGx para obtener números.

Entonces, por CLI7/NG7/NG7deps (su Test case 1 ) obtuve:

$ 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)

Esto no parece ser muy diferente del punto de referencia ES5. @ alex88 tal vez cuando es2015 realidad estabas obteniendo las compilaciones DL? Tampoco debería usar el Nodo 12 por ahora debido a https://github.com/nodejs/node/issues/28205.

@zijianhuang, así que para terminar, creo que la razón por la que su proyecto usa más recursos con NG8 / CLI8 que con NG7 / CLI7 es que DL estaba activado y que algunas compilaciones no tenían caché. Realmente no puedo estar seguro del segundo punto porque no sé cómo está almacenando cosas en caché localmente y en CI, pero los números que obtuve aquí parecen apuntar a eso.

Para nosotros, el seguimiento de la investigación de la transición de su proyecto de la versión 7 a 8 de Angular es que realmente necesitamos averiguar qué memoria se retiene entre las compilaciones de DL porque eso apunta a una fuga, y que necesitamos tener una configuración de DL más eficiente ( @clydin tiene algunas ideas sobre eso).

Hola @filipesilva , escribí hace un tiempo en este hilo mencionando mis puntos de referencia y lo que no funcionó para mi caso. Parece que el AOT realmente no me funciona. ¿Se está realizando alguna investigación en esta área?

@jsgoupil en https://github.com/angular/angular-cli/issues/13734#issuecomment -506760767 Vi un mínimo de 240 MB y un máximo de aproximadamente 1 GB de memoria que se utiliza en la compilación AOT. Intenté durante un par de días averiguar exactamente dónde, pero no tuve mucho éxito. Sin embargo, todavía hay un par de cosas más que quiero probar. Y también creo que el mínimo está relacionado con la memoria de "transferencia" que veo en las compilaciones de DL.

Pero dicho esto, no hay forma de evitar el hecho de que AOT hace mucho más trabajo y requiere más recursos. Eso no es un error. Es solo un paso de construcción mucho más complicado. Es posible que requiera desproporcionadamente más recursos que los que no son AOT, pero nunca requerirá menos.

¿Viste los comentarios finales en https://github.com/angular/angular-cli/issues/13734#issuecomment -506760767 sobre las unidades de compilación? Puede ser que su tsconfig incluya muchos archivos que no usa tan bien, o que el componente sass sea más grande de lo esperado (si usa sass).

Si me da acceso a su código de alguna manera, puedo echar un vistazo y ver si encuentro algo extraño.

@filipesilva , muchas gracias por un análisis tan detallado e inspirador. Hice algunos cambios menores en la configuración de compilación, algunos de los cuales son similares a los que hizo el equipo de CLI durante el análisis. Había alterado la lista de navegadores:

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

para garantizar que solo se produzca la compilación es2015.

Para la compilación DEBUG, el uso máximo de memoria es de 1,9 GB.
Para la versión de producción, el uso máximo de memoria es de 2,0 GB.

En realidad, esto es un pequeño salto de 1.3 GB en comparación con la compilación con NG7 / NG CLI 7, que también produce solo la compilación es2015. El límite de memoria predeterminado de 1,5 GB de Node es la trampa, sin embargo, en general, el pequeño salto es razonable. Similar al que había analizado.

@jsgoupil se puso en contacto y me dejó ver su proyecto. Apagué el caché terser (descrito en https://github.com/angular/angular-cli/issues/13734#issuecomment-508815407) y comparé el comando "ng build 3cconnect --prod":

[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)

Esta compilación tiene AOT y Build Optimizer desactivados y usa la carga diferencial. El uso promedio de memoria también es el máximo, lo que significa que el recolector de basura está haciendo mucho trabajo para liberar memoria a medida que avanza la compilación.

Intenté activar AOT y Build Optimizer y obtuve OOM en la segunda compilación de DL, durante TerserPlugin. Usó el comando node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng build 3cconnect --prod --aot --build-optimizer para construir y tuvo éxito.

El punto de referencia para esta compilación muestra los siguientes números:

$ 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)

También probé sin Build Optimizer activado:

[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)

No esperaba que Build Optimizer afectara tanto el uso de memoria promedio o máximo. 500 MB es bastante. Ya estábamos buscando una forma de reducir la cantidad de archivos procesados ​​en https://github.com/angular/angular-cli/pull/14998 , lo que ayudaría a reducir el impacto.

Estos números parecen mucho más altos que los iniciales, pero tenga en cuenta que aumentamos la memoria de 1.4gb por defecto a alrededor de 8gb. Esto significa que el recolector de basura no tiene tanta presión para liberar memoria, por lo que las cosas permanecen en la memoria por más tiempo. A modo de comparación, aquí está la compilación inicial (sin AOT ni Build Optimizer) con un límite de memoria aumentado:

$ 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)

Entonces, cuando se usa el mismo límite alto de memoria, agregar la activación de AOT y Build Optimizer aumentó el uso promedio de memoria en 1GB y el uso máximo de memoria en 1.8GB.

Usar solo AOT aumentó el tiempo de compilación en un 70% (250-> 400 s), el uso promedio de memoria en un 25% (2000-> 2500) y el uso máximo de memoria en un 36% (3800-> 5200 mb). La adición de BO aumentó el tiempo de compilación en un 42% (400-> 570 s), el uso promedio de memoria en un 20% (2500-> 3000) y el uso máximo de memoria en un 7% (5200-> 5600 mb).

También intenté desactivar la carga diferencial configurando "target": "es5", en ./tsconfig.json mientras mantenía AOT y 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: 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)

Sin DL, la memoria utilizada se reduce a ~ 500 MB, similar a https://github.com/angular/angular-cli/issues/13734#issuecomment -508815407. Estamos buscando mejorar eso.

Traté de averiguar qué tan grande era el proyecto enumerando archivos en src/ por extensión:

$ 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  

Esto no incluye bibliotecas de terceros, por lo que no nos da mucha información sobre el tamaño total de la compilación. Pero no me sorprende que este proyecto necesite aumentar el límite de memoria, hay muchos archivos TS aquí. Yo eché un vistazo a

@jsgoupil en https://github.com/angular/angular-cli/issues/13734#issuecomment -497365534 mencionaste que una máquina Azure con 7gb no podía construir la aplicación, lo que me parece extraño porque 5.6gb era el máximo que vi en mi máquina con Windows.

¿Quizás la máquina de CI ya esté usando 1.4gb? Eso tendría sentido. Probablemente pueda verificar cuánta memoria tiene la máquina antes de la compilación. Pero también dijiste que la máquina solo tiene 7GB y estás usando --max_old_space_size=8192 . No estoy realmente seguro de cómo se comporta Node cuando dices que debería usar más memoria de la que realmente está disponible. Entonces me pregunto si eso es un problema: le da un límite mayor que el disponible, por lo que cree que puede asignar toda esta memoria, pero cuando es necesario, el sistema no la tiene, por lo que obtiene un error. Dice en https://github.com/angular/angular-cli/issues/13734#issuecomment -497426391 que el error es diferente con y sin la bandera, por lo que apunta a un problema diferente. Tal vez verifique cuánta memoria hay disponible y establezca un límite por debajo de eso, como 5000 o 6000.

Independientemente de la máquina Azure que mencionó, es impresionante (de manera negativa) que la compilación AOT aumente el uso de memoria en un promedio de 1GB / pico de 1.8GB. Esto es algo que estamos viendo en el caso general. Creo que en su proyecto realmente es solo una función de la cantidad de archivos fuente de TS que necesitan compilación AOT, intenté tomar un perfil del uso de memoria y en su mayoría se parecía a los otros que he visto antes en otros proyectos.

También noté que tiene algunas importaciones extrañas a ../../../node_modules/@angular/core lugar de solo @angular/core , y similares a RxJs. Creo que esto no hace ninguna diferencia porque la resolución seguirá usando package.json allí. Pero pensé que era extraño.

Si su aplicación falla mientras crea archivos scss, intente instalar esas dependencias node-sass, style-loader y sass-loader, ¡esto funcionó para mí!

No sé si esta es información interesante o no, pero tuve muchos problemas con las versiones de @angular-devkit/build-angular más nuevas que 0.800.2 para la compilación de travis que recientemente produjeron el mismo error que el anterior. Volver a 0.800.2 solucionó el problema.

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

mismo problema en el servidor ubuntu 18.04, pero esto resolvió mi problema:
node --max_old_space_size = 8192 node_modules / @ angular / cli / bin / ng build --prod

Simplemente colocando esto aquí, pero si alguien está usando la compilación de código de AWS, asegúrese de actualizar su entorno de compilación para que se configure con más de la memoria mínima de 3 GB, seguí los pasos anteriores pero tuve que volver a configurar mi entorno con más memoria.

En mi caso, reconfigurar el entorno de CodeBuild para usar más de 3 GB (elijo 15 GB) fue suficiente para eliminar el problema ... no necesitaba cambiar la configuración de memoria en el nodo ...

@ThomasEg , ¿qué entorno tienes para no tener que cambiar la configuración de la memoria en el nodo?

El mío es Windows 10 con 16 GB de memoria, y cambiar la configuración del nodo max_old_space_size resuelve el problema:
node --max_old_space_size=8192 "node_modules/@angular/cli/bin/ng" build --configuration=production

mientras que el nodo en realidad usó 2 GB de memoria.

Sospecho que su entorno CodeBuild en realidad le da al nodo max_old_space_size detrás del sentido, mientras que ng build aparentemente no lee max_old_space_size para node. ¿Puedes confirmar eso?

@JohannesHoppe No estoy seguro de qué rama / compilación debería estar mirando allí. ¿Puedes vincularme compilaciones específicas en las que hayas notado una diferencia? Esto también podría estar relacionado con la configuración de almacenamiento en caché. Cuando actualice Angular CLI, es probable que elimine la caché de minificación que las compilaciones dejan dentro de node_modules. Entonces, la primera compilación sin ese caché necesita más memoria.

He estado tratando de averiguar si realmente hay una pérdida de memoria en las compilaciones de Carga diferencial (DL). A continuación están mis notas.

TLDR es que no parece haber ninguna pérdida de memoria en DL, pero cuando se usa --max_old_space_size V8 mantendrá la memoria disponible. Una compilación puede terminar con éxito con --max_old_space_size=300 sin errores, pero usará hasta 2500 MB de memoria si se le da --max_old_space_size=10000 .

Tratando de averiguar si DL realmente acumula memoria sin cesar. Se modificó una compilación de DL para duplicar las entradas en webpack-browser-config.js. Las compilaciones normales (2) usan 480 promedio / 960 pico, 4 compilaciones son 810/1700, 8 compilaciones son 1400/2500. Así que cada build deja un promedio de 200ish.

Sin embargo, no entiendo por qué el pico también aumenta tanto. El pico debería ser promedio + algo ... ¿verdad? En realidad eso está mal. Porque ya sabemos que el uso aumentará con el tiempo. Entonces, el promedio durante la primera construcción es mucho menor que el promedio durante la última construcción. Un poco como una integral. Entonces, el número que debería preocuparme es el máximo, porque representa mejor las cosas para el caso de compilación múltiple.

También noté que process.memoryUsage (). HeapUsed me dio números mucho más bajos de lo que vi en el administrador de tareas. Eso me pareció extraño. Tampoco desactivé el caché terser. Debería hacer eso para ver si también hay un costo de escala allí, después de calcular este costo de escala inicial.

Intenté hacer global.gc cada 30 segundos para averiguar si la memoria realmente se retuvo o si el nodo estaba muy cómodo con el límite de 10 GB. Lo hizo en 5 iteraciones. Sin GC obtuve 1200/2150, con GC obtuve 1200/2050. Entonces solo un pico un poco más pequeño. Esto muestra que la memoria no se puede liberar.

Tomó perfiles de montón e instantáneas de montón cada 30 segundos. También probé el perfil de fuga de memoria en devtools de Chrome. Los perfiles del montón casi no muestran cambios entre ellos. Muy raro. ¿Quizás necesito reiniciar el generador de perfiles entre muestras? Las instantáneas tampoco se cargan, con un error al crear retenedores. Los volverá a hacer.

Intenté crear perfiles nuevamente con un intervalo de muestreo más bajo y no vi nada diferente. Todas las instantáneas, pero la primera aún fallaron con el mismo mensaje. También intenté tomar solo una instantánea al final y obtuve solo una pequeña instantánea (200mb).

Intenté tomar una instantánea manualmente en Chrome Devtools durante la octava (y última) compilación. Devtools dijo que el proceso estaba usando ~ 2000mb de memoria justo antes de tomar la instantánea, y luego mostró solo ~ 260mb. La instantánea fue de solo 254 MB.

Así que pensé que podría ser una cosa de GC. Intenté limitar max_old_space_size a 1gb y aún así se construyó. También se construyó con 600 MB y 400 MB, pero falló con 300 y 200. Una sola ejecución de compilación falló con 200 pero tuvo éxito con 300. Una compilación DL predeterminada también falló con 300.

Por lo que puedo decir, no se guarda una cantidad real de memoria debido a DL. Tal vez haya 100 mb extra. Una nueva aplicación utilizará aproximadamente la misma memoria (~ 300 MB en el proceso principal, más hasta 450 MB en los procesos Terser generados) para producir 1 compilación u 8 compilaciones en el mismo comando. Pero si establezco el límite de memoria en un número muy grande (10 gb), mantendrá más memoria (hasta 2,5 gb) hasta que sea necesario liberarla.

@filipesilva
Aquí están los registros de fallas en la construcción:
https://travis-ci.org/johannesjo/super-productivity/jobs/556566074
Creo que la clave son los cambios no deseados en el package-lock.json realizados aquí:
https://github.com/johannesjo/super-productivity/commit/807a760d7d7cb9f18e706422a9f8f02af30342de

Y está la compilación para el compromiso que solucionó el problema y el compromiso en sí:
https://github.com/johannesjo/super-productivity/commit/5e6b7aaf234dbac286549a6ac74957ba15589cd8
https://travis-ci.org/johannesjo/super-productivity/jobs/557364217

(también mencionaste al pobre Johannes Hoppe en lugar de a mí otra vez :))

Estábamos experimentando el mismo problema. Resultó que importamos los archivos scss base en la mayoría de nuestros componentes. Eso no fue realmente necesario.
Ahora, sin configurar la opción de nodo max-old-space-size , pudimos construir nuestras aplicaciones en modo de producción sin el error, después de eliminar las importaciones de archivos centrales en nuestros componentes, donde no era necesario.

También cambiamos de dart-sass a node-sass con npm install -DE node-sass y eso funcionó también, sin cambiar nada.

Debajo de mi entorno. Quizás esto ayude :)

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


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 Dudo que tenga algo que ver con la carga diferencial o que "apile" la memoria. construimos en docker / k8s y necesitamos establecer max_old_space_size> 4096 incluso sin DL. En Angular 7 o inferior (también usamos "@angular-devkit/build-angular" < "~0.800.2" ) lo teníamos configurado en 2048.

Me encontré con este mismo problema al llamar a "ng serve" con alguna configuración personalizada:

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

Si solo está buscando comenzar, cambiar las banderas "buildOptimizer" y "optimización" en mi configuración a falso hizo el truco y pude construir en segundos.

@CodeEpiphany , sabía que sabía, dicha configuración para un tiempo de compilación más rápido y probablemente un consumo de memoria de compilación más pequeño es un cambio por una salida de compilación más grande y un rendimiento de tiempo de ejecución más lento, sin embargo, no capta el punto del problema mencionado en el OP.

Primero experimenté esto con dart-sass. Logramos solucionar todos esos problemas de scss, lo había hecho Dart-Sass. Ahora sucedió con una de mis aplicaciones usando el objeto sourceMaps. Establecer sourceMaps en falso solucionó mi problema

Tuve el mismo problema con Angular 8. Windows 10
Supongo que diferentes personas tienen estos problemas por diferentes razones.

Mi solucion fue:

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

Ahora, nuevamente, hay dos cosas en esto, o funcionó debido a max_old_space_size = 8192 o puede deberse a que tengo una versión angular cli local y global diferente. y usando el comando anterior usó la versión local / misma de ng

Tengo una aplicación relativamente pequeña, tal vez 24 componentes, incluidas rutas, modales y algunas clases para la gestión del estado, etc. Y en una máquina de 16 GB, incluso con todas las sugerencias publicadas aquí, hay 3/4 de probabilidad de que llegue este error. No entiendo cómo puede usar tanta memoria y realmente no entiendo por qué al menos no está tratando de paginarlo en el SSD (seguro, sería lento, pero si no se construye en absoluto , para construir en 10 minutos, 10 veces el tiempo de construcción anterior, eso sigue siendo bastante bueno).

Esto es con sourcemaps desactivado, nodo obteniendo la configuración max_old_space_size, buildOptimizer desactivado, optimización desactivada.

Hace 3 versiones, esta misma aplicación podría construirse con una máquina de 3GB. ¿Realmente debería revertir todo a Angular 5 o es mejor simplemente cambiar a Vue?

@Senneseph ¿cuál es su versión de nodo? prueba el nodo 10 en lugar de 12

@maxisam Estoy en 10.x hasta que AWS decida usar una versión más reciente o decido crear una capa Lambda personalizada. Pero esto debería funcionar en 8.9+ según los documentos.

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

Tanto la CLI como el proyecto generado tienen dependencias que requieren Node 8.9 o superior, junto con NPM 5.5.1 o superior.

Iba a agregar una perorata aquí, pero solo se la enviaré a los jefes con una solicitud para cambiar de marco. Parece que este proyecto es un caos total.

Aquí hay algo divertido para probar (8.1.3):

npm install -g @ angular / cli
ng crear nuevo proyecto
cd nuevo proyecto
ng actualización
"rxjs 6.4.0 -> 6.5.2 ng actualizar rxjs"

¿Por qué un proyecto nuevo ya requiere una actualización de paquete? 6.4.0 fue en enero. 6.5.2 fue en mayo.

CLI angular 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 amigo, la gente aquí todavía está tratando de arreglarlo. Nadie ignora este tema. Si tiene un pequeño problema y le hace decidir salir de Angular, buena suerte con otros "frameworks" (Vue y React no son frameworks, IMO). Estoy seguro de que son tan perfectos con 0 problema.

Tengo un proyecto con más de 100 componentes con toneladas de clases y servicios ngrx.

Mi servidor de compilación está en el nodo v12 con hardware bastante promedio.

para es2015

Fecha: 2019-07-18T13: 21: 52.536Z - Hash: 9ba50a50277fc3c9fc2e - Hora: 54734ms
para es5
Fecha: 2019-07-18T13: 23: 12.900Z - Hash: 93e6713a4d03978a67fd - Hora: 80111ms

Tarda un poco más que la v7 pero no es una locura.

Cambié mi máquina de desarrollo local al nodo v10 el primer día que actualicé a V8, pero no he hecho nada para construir el servidor porque estoy seguro de que el equipo de CLI resolverá esto.

Este es un lugar para que la gente trabaje en problemas, no un lugar para desahogarse.

Ni siquiera sé qué está mal con la actualización. No hay ningún cambio importante en rxjs de 6.4.0 a 6.5.2.

@maxisam

Definitivamente aprecio el arduo trabajo de todos. Inicialmente elegí Angular porque parecía ser el proyecto mejor organizado y más holísticamente pensado.

El problema no es si la gente está trabajando duro para resolver este problema. El problema es que debería haberse resuelto antes de su lanzamiento y declarado listo para uso público.

En cuanto a rxjs, no debería haber cambios importantes entre las versiones. El problema es que los comentarios dicen "// Estas versiones deben mantenerse actualizadas con las últimas dependencias de pares de Angular". y, sin embargo, alguien simplemente está escribiendo lo que quiera en el campo en lugar de ejecutar un script para extraer la cadena exacta. Y luego nadie probó si estaba funcionando como se esperaba.

Imagino que el equipo de Angular se ha estirado demasiado.

@Senneseph

El problema es que debería haberse resuelto antes de su lanzamiento y declarado listo para uso público.

Sabes que esto es BS, ¿verdad? ¿No hay un parche de error para Vue o React?

En mi humilde opinión, V8 está listo. Lo he usado por un tiempo. Este problema realmente no detiene a todos. Nadie en nuestro equipo (5+) tiene este problema. Tenemos proyectos de 10ish que usan Angular 7/8 con AOT y Build Optimizer en.

Vemos el problema del tiempo de construcción, pero nada nos impide construir.

¿Intentaste instalar node-sass, style-loader y sass-loader? (El mío funciona de cualquier manera, pero deberías probarlo).

Mantenga la discusión sobre el tema y revise el código de conducta para el comportamiento.

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

@maxisam

Gracias por la sugerencia sobre Sass, pero estoy usando CSS simple que está construido en su propio proyecto. No lo mencioné antes porque la pregunta de si esto estaba sucediendo con CSS simple parece estar ya respondida.

@Senneseph, ¿hay alguna posibilidad de que pueda ver ese proyecto? No creo que un proyecto de 24 componentes deba usar 16 GB de memoria. No he visto ningún proyecto que use tanta memoria en absoluto

Hubo un severo, pero raro, pero con mecanografiado 3.4 (https://github.com/microsoft/TypeScript/issues/30050) que causó que se usara mucha memoria extra en algunos casos con tipos de unión. Acabamos de lanzar soporte para TS 3.5 en Angular 8.2.0 con @angular-devkit/[email protected] . Eso podría ser lo que está afectando a su proyecto, puede intentar actualizar a esas versiones para ver si ayuda.

Gracias @filipesilva . Desafortunadamente, no puedo otorgar acceso al proyecto en sí. Probaré la versión @ angular-devkit / build-angular que recomendó e informaré cómo funciona en una semana más o menos.

Aunque no tengo muchos componentes, son bastante abstractos. Y aunque no estoy usando el operador keyof directamente, defino un tipo que es una unión de aproximadamente 19 tipos. Quizás en algún lugar he combinado este tipo con otro de mala manera, de modo que explota el tsc cuando intenta realizar la normalización.

(Si esta es la razón por la que mi aplicación angular es normal en los navegadores de escritorio, pero casi no responde cuando hay formularios reactivos en la página, estaré realmente feliz. Por alguna razón, solo Opera Mobile tiene la misma capacidad de respuesta / uso de CPU que el escritorio navegadores.)

La semana pasada, después de fusionar una rama relativamente pequeña en la rama maestra, la compilación de mi proyecto comenzó a experimentar este problema de memoria que se informa aquí. La parte interesante es que el problema estaba ocurriendo solo en el servidor de CI, ninguno de los desarrolladores tenía problemas localmente, incluso con --prod .

Después de leer el comentario de @filipesilva anterior, decidí actualizar angular de la siguiente manera:

$ 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)

¡El problema esta ahora arreglado!

Mi impresión es que la memoria adicional necesaria para las compilaciones duales de DL, más el hecho de que el mecanografiado se subió a 3.4, que tiene los problemas mencionados anteriormente con respecto a los casos de borde de tipo union, comenzó a causar este consumo de memoria adicional para algunos proyectos.

Oigan todos,

Solo quería brindarle una actualización sobre los pasos que nosotros (y otros en la comunidad) tomamos para abordar este problema en Angular 8:

• Se agregó soporte para TypeScript 3.5 https://github.com/angular/angular/pull/31615
• Mejore el rendimiento cuando hay muchos fragmentos perezosos https://github.com/webpack/webpack/pull/9472
• Corregir la regresión del rendimiento en el nodo 12 https://github.com/angular/angular/pull/31638
• Advertir cuando se incluye CSS de componente grande https://github.com/angular/angular-cli/pull/15093
• Advertir cuando la compilación de TS incluye archivos no utilizados https://github.com/angular/angular-cli/pull/15061
• Reducir la cantidad de archivos procesados ​​por Build Optimizer https://github.com/angular/angular-cli/pull/14998
• rendimiento mejorado de las compilaciones de carga diferencial https://github.com/angular/angular-cli/pull/15246
• aclaró más recursos en compilaciones que no son de reloj https://github.com/angular/angular-cli/pull/15292

Estos esfuerzos aún están en marcha:

• Mejore el rendimiento del minificador JS https://github.com/webpack-contrib/terser-webpack-plugin/issues/104
• Mejore el rendimiento del procesador Sass https://github.com/sass/dart-sass/issues/744
• Reducir la memoria utilizada por el compilador angular
• Elimine las optimizaciones de pure_getter https://github.com/angular/angular-cli/issues/14316

Esto es lo que puede hacer para aprovechar estas correcciones:

• Actualice a @angular/[email protected] (junto con los otros paquetes de marco)
• Actualice a @angular/[email protected] y @angular-devkit/[email protected]
• Actualizar a [email protected]
• Instale node-sass como dependencia de desarrollo si usa Sass
• Utilice el nodo 12.8

Una nota especial es que reelaboramos por completo el funcionamiento de la carga diferencial. Ahora debería ser mucho más rápido, pero puede usar más memoria del sistema dependiendo de la cantidad de núcleos que tenga. Esto es diferente del límite de memoria del nodo.

Cuando alcanza el límite de memoria del nodo, ve el error FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory . Pero si alcanza el límite de memoria del sistema, debería ver Fatal process OOM in insufficient memory to create an Isolate .

La nueva configuración de carga diferencial hace que sea más raro llegar al primero, pero si tiene muchos núcleos pero no mucha memoria, puede ser más común llegar al segundo. Nos gustaría recibir comentarios sobre @angular-devkit/[email protected] por favor, para que podamos abordar este comportamiento si es un problema, desactivando el paralelismo en algunos casos o haciéndolo configurable.

Tengo el mismo error en Angular 8 y esto resolvió mi problema:

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

Donde X = (2048 or 4096 or 8192 o..) es el valor de la memoria

@filipesilva acaba de instalar Node 12.8 resolvió el problema. Gracias.

¡Hola! hilo muy interesante
especialmente esto:
https://github.com/angular/angular-cli/issues/13734#issuecomment -506760767
y esto :
https://github.com/angular/angular-cli/issues/13734#issuecomment -521743839

¿Alguien puede explicarme esto?

Instale node-sass como una dependencia de desarrollo si usa Sass

¿Estamos "rindiéndonos" en dardos?

¿O es una combinación de usar dart-sass como compilador principal y node-sass como "soporte", si eso funciona? (el contexto de si npm i sass --save-dev / yarn add sass --dev todavía estaría en uso en este caso no se proporcionó en la guía anterior).

¿Cómo se vería exactamente mi archivo package.json y hay otros cambios que realizar en mi proyecto?

Personalmente estoy actualizando mi proyecto a angular 8 y quiero cambiar a dart-sass

EDITAR:

¿Hay otros cambios que realizar en mi proyecto?

para responder al menos esa parte de mi propia pregunta: parece que dart-sass no admite la etiqueta / deep / scss.

sin embargo :: ng-deep funciona, por lo que es el mejor de todos los mundos. ¡Hasta ahora me gusta mucho el dardo! mucho menos complicado al construir.

Tuve este problema y esta solución funcionó para mí:

en el archivo angular.json, reemplace el valor de la clave outputPath con "dist"

Simplemente actualizando la versión del nodo de LTS a Current resolvió mi problema.

mismo problema. node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod todavía no funciona.

Se ha enfrentado a fallos de una gran aplicación con muchos fragmentos. Pero parece un problema en el mapa de origen y tiene el mismo error que en https://github.com/webpack/webpack-sources/issues/66

Tuve que actualizar al nodo 12 Y aumentar nuestra memoria de instancia de creación de código de 3 a 7 GB. Solo para construir una aplicación angular.

@filipesilva , confirmo que ng build está funcionando bien ahora con:

• angular 8.2.2
• angular / cli 8.2.2
• nodo 12.4

ng build --configuration=production

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

Hace unos meses, cuando probaste mi gran SPA, el consumo de memoria del nodo superaba los 2 GB, así que tuve que usar:
node --max_old_space_size=8192 "node_modules/@angular/cli/bin/ng" build --configuration=production

Ahora, con una base de código más grande que se está construyendo con ng build , el pico de memoria del nodo es de 1,6 GB.

Buen trabajo. :)

¿Hay alguna otra forma de hacer que esto funcione en el nodo 10?

@stevefiedler , ¿hay alguna razón por la que

Bueno, saltar a 12 parecía requerir muchos más cambios para mi aplicación, y tengo varias aplicaciones de las que preocuparme. Debería estar funcionando paso a paso

@stevefiedler , tengo un gran Angular SPA que comenzó desde septiembre de 2016 con Angular 2, y parece que no encontré ningún problema al pasar al nodo 12. Si publica el problema en StackOverflow, puede encontrar más ayuda y es posible que haya una mirada también.

@stevefiedler Por pura curiosidad. ¿Qué problemas tiene con su aplicación cuando cambia el compilador al Nodo 12?

Tengo el siguiente entorno:

Nodo 12.9.1
Angular 8.25 (de la actualización de ng)

@ angular-devkit / build-angular y build-ng-packagr de 0.803.3
@ angular / cli de 8.3.3

Al ejecutar ng build --prod y observar el proceso del nodo, veo un comportamiento similar en el uso de la memoria como se describe anteriormente, donde apenas eclipsa los 2 GB de uso. Sin embargo, en un momento, simplemente falla con el siguiente mensaje de error. Parece estar fallando con el uso de webpack de la biblioteca de bellotas.

Tengo un SPA muy grande que utiliza sass, y estoy usando node-sass en lugar de dart.

Veo el siguiente seguimiento de la pila cuando intento ejecutar ng build --prod:

ng build --prod
Procesamiento de activos en trozos del 90%
<--- Últimos GC --->

[32136: 00000223FBDD0BD0] 321271 ms: Mark-sweep 1906.3 (2091.5) -> 1906.0 (2093.0) MB, 1306.9 / 0.0 ms (mu promedio = 0.187, mu actual = 0.124) falla de asignación GC en el espacio anterior solicitado
[32136: 00000223FBDD0BD0] 321985 ms: Mark-sweep 1912.7 (2093.0) -> 1910.5 (2093.0) MB, 656.7 / 0.1 ms (mu promedio = 0.152, mu actual = 0.081) falla de asignación GC en el espacio anterior solicitado

<--- Seguimiento de pila JS --->

==== Seguimiento de pila JS =========================================

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

Contexto de seguridad: 0x022679540919
2: parseExprOp [0000039FA6955EF1] [C: projectnode_moduleswebpacknode_modulesacorndistacorn.js: 2034] [bytecode = 0000007FB1EB9C01 offset = 226] (this = 0x00876aee4d01, 0x0183701f23d1, 11588,0x0183701f23a9

ERROR FATAL: Mark-compacts ineficaz cerca del límite de almacenamiento falló en la asignación: el montón de JavaScript no tiene memoria
1: 00007FF778F5F0DF napi_wrap + 121039
2: 00007FF778F051D6 v8 :: base :: CPU :: has_sse + 34470
3: 00007FF778F05E96 v8 :: base :: CPU :: has_sse + 37734
4: 00007FF7796F89AE v8 :: Aislar :: ReportExternalAllocationLimitReached + 94
5: 00007FF7796E0951 v8 :: SharedArrayBuffer :: Externalizar + 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 :: interno :: Heap :: CollectGarbage + 1235
10: 00007FF7795AAB04 v8 :: internal :: Heap :: AddRetainedMap + 2356
11: 00007FF7795C7684 v8 :: interno :: Fábrica :: NewByteArray + 100
12: 00007FF7796115D7 v8 :: internal :: BasicBlockProfiler :: Data :: ResetCounts + 8647
13: 00007FF7799194AC v8 :: interno :: compilador :: CodeGenerator :: GenerateDeoptimizationData + 124
14: 00007FF779919247 v8 :: interno :: compilador :: CodeGenerator :: FinalizeCode + 103
15: 00007FF77994FAEA v8 :: interno :: compilador :: LiveRange :: End + 746
16: 00007FF77995011F v8 :: interno :: compilador :: 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 :: interno :: StackGuard :: HandleInterrupts + 1770
21: 00007FF779339432 v8 :: internal :: intérprete :: JumpTableTargetOffsets :: iterator :: operador = + 5138
22: 00007FF779B1224D v8 :: interno :: SetupIsolateDelegate :: SetupHeap + 575565
23: 00007FF779B75575 v8 :: interno :: SetupIsolateDelegate :: SetupHeap + 981877
24: 00007FF779A8FCFC v8 :: interno :: SetupIsolateDelegate :: SetupHeap + 41724
25: 0000039B9B7A5C28

Quería agregar un poco más de información. ng build parece funcionar bien. solo cuando se usa el indicador --prod es donde ocurre el problema del montón. Aquí está mi configuración de prod del angular.json:

"producción": {
"fileReplacements": [{
"reemplazar": "aplicaciones / estándar / src / entornos / entorno.ts",
"con": "aplicaciones / estándar / src / entornos / entorno.prod.ts"
}],
"optimización": verdadero,
"outputHashing": "todos",
"sourceMap": falso,
"extractCss": verdadero,
"namedChunks": falso,
"aot": cierto,
"extractLicenses": verdadero,
"vendorChunk": falso,
"buildOptimizer": verdadero,
"vendorSourceMap": falso
},

Muchas gracias @filipesilva por el exhaustivo benchmark. La instalación de node-sass no nos sacó, pero la actualización de angular a v8.2.6 hizo el truco.

Aún así, ¿no es extraño que la mayoría de las personas que informan del error de memoria acumulada de JavaScript se atasque en el 92% con precisión ? Culparía al proceso de optimización de Terser por el pico de memoria repentino.

¿Hay alguna forma de resolver este problema sin actualizar el nodo a actual desde LTS? En mi proyecto, la compilación se genera en el servidor. No puedo pedir a todos los servidores que actualicen el nodo.

@akvaliya node 12 será LTS en menos de un mes. No veo cómo un error de este intrincado y amplio alcance tiene sentido para abordar con una versión que está a punto de convertirse en 'semi-legado'. https://nodejs.org/en/about/releases/

@tomgruszowski Sí. Pero no puedo decirle al cliente que actualice todos sus servidores.

@akvaliya ¿

@benelliott Bueno, simplemente empujo el código al repositorio y los probadores del equipo del cliente lo

No creo que este debería ser el punto de por qué estamos construyendo fron-ent en server. Algunos clientes quieren que el código se vuelva a implementar automáticamente después de la confirmación. Como usar jenkins.

para mí, la solución fue editar mi tsconfig (ionic4 y angular8)

Estaba jugando agregando propiedades a tsconfig, hacia el final habilité mapas de origen para mi compilación de prod dentro de angular.json .

Tuve que eliminar sourceMap: true y sourceBase: "/" de tsconfig, después de eso --prod funciona como un encanto

"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",
}

La configuración anterior me resuelve

Para nosotros, la actualización de Angular 8.2.0 a 8.2.8 funcionó y ya no obtuvimos el error. Aunque asignar más memoria no funcionó para nosotros.

@filipesilva acaba de instalar Node 12.8 resolvió el problema. Gracias.

También tengo el mismo problema con 12.8.

@filipesilva acaba de instalar Node 12.8 resolvió el problema. Gracias.

Estaba recibiendo debug y Node> 12.8 fix para mí

Tengo un proyecto personalizado que no usa Angular pero construido con Webpack, y obtengo este error cuando construyo con Webpack en el modo production . Intenté --max_old_space_size=8192 pero no tuve suerte (supongo que necesito más).

Sin embargo, me pregunto cuál es el problema en realidad, apuesto a que diferentes frameworks / libs / apps pueden tener configuraciones de Webpack similares que pueden causar esto.

Tuve el mismo problema e hice estos pasos:

• ng update @angular/cli @angular/core
• actualizar nodo a v12.11.1
  funciona bien con --max_old_space_size=8192
"@angular/core": "8.2.8", "@angular/cli": "^8.3.6"

La causa específica de este error para mí (en mi proyecto no angular) es el uso de uglifyjs-webpack-plugin . Utiliza una tonelada de memoria. Por ahora, desactivé la minificación en producción y tendré que averiguar cómo solucionarlo más tarde.

Inhabilité la minificación en producción

😨

Esto me ha funcionado para las compilaciones de desarrollo. Todavía no he visto este problema con las compilaciones de producción.

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

Solo comencé a necesitar esto después de actualizar Angular y CLI desde 8.0.0 a los últimos 8.2.8 y 8.3.6 . Aquí está el PR donde se cambió esto: https://github.com/angular/material.angular.io/pull/641

La causa específica de este error para mí (en mi proyecto no angular) es el uso de uglifyjs-webpack-plugin . Utiliza una tonelada de memoria. Por ahora, desactivé la minificación en producción y tendré que averiguar cómo solucionarlo más tarde.

Probablemente esto esté relacionado con los mapas de origen. Intente configurar sourceMap en falso en tsconfig.json (o, para aquellos con proyectos angulares, en angular.json ).

Una nota para los usuarios de Angular / Windows / Docker

Si está intentando ejecutar 'npm run build' o algo por el estilo dentro de su archivo Docker y obtiene este error, como se mencionó anteriormente, desea usar el siguiente comando de ejecución en su lugar, aumentar el acceso de Node.js a la memoria.

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

Sin embargo, además, Docker está ejecutando una máquina virtual Linux en segundo plano que también tendrá limitaciones de memoria que deben abordarse.

Navegue a 'C: UsuariosAppDataRoamingDocker 'donde el nombre del perfil es el nombre de su perfil registrado. Allí encontrará un archivo 'settings.json'. Ábralo y ajuste el valor de 'memoryMiB' para que también sea 8192. Deberá reiniciar para que los cambios surtan efecto.

ADVERTENCIA

El aumento de la memoria de la máquina virtual puede tener un impacto drástico en el rendimiento de su máquina, así que asegúrese de tener suficiente memoria física para hacer esto antes de intentarlo. Si esta solución funciona para usted, entonces debería intentar revertir los valores tanto como pueda, haciendo un proceso como, dividir el valor a la mitad inicialmente, probarlo, dividirlo nuevamente a la mitad si funciona, o agregar la mitad del nuevo valor si no lo hace, etc. Esto le ayudará a minimizar el impacto en su máquina.

También querrá deshabilitar Docker como un programa de inicio para Windows 10. Simplemente busque "aplicaciones de inicio" en la barra de tareas y seleccione la opción correspondiente que aparece. De esta manera, no tendrá una máquina virtual que no esté usando atascando su sistema.

para mí, la solución fue editar mi tsconfig (ionic4 y angular8)

Estaba jugando agregando propiedades a tsconfig, hacia el final habilité mapas de origen para mi compilación de prod dentro de angular.json .

Tuve que eliminar sourceMap: true y sourceBase: "/" de tsconfig, después de eso --prod funciona como un encanto

Simplemente eliminar sourceMap funcionó para mí. Frustrante....

set NODE_OPTIONS = - max-old-space-size = 30720 comando funcionó para mí.

Tuve el mismo problema y actualicé el nodo a 12.12 hoy, déjame ng build --prod

Estamos usando canalizaciones de Bitbucket y no podemos aumentar el límite de memoria a 8 GB. Además, nuestra aplicación tarda entre 7 y 10 minutos en compilarse y necesitamos los mapas de origen para nuestros informes de errores de Sentry.

ACTUALIZACIÓN: ejecutar ng update @angular/cli @angular/core resolvió el problema.

Actualicé node.js a la última versión LTS (en este momento 12.13.0 ) y todo funciona perfectamente. Ya no es necesario configurar el max-old-space-size .

Tuvimos el mismo error en Windows-Comupters, causado por una configuración incorrecta en _angular.json_. outputPath se configuró en una ruta / unidad que no existe y siempre terminó con el mismo error, en Angular 7/8 y con diferentes versiones de node.js (12.x).

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

Estamos usando canalizaciones de Bitbucket y no podemos aumentar el límite de memoria a 8 GB. Además, nuestra aplicación tarda entre 7 y 10 minutos en compilarse y necesitamos los mapas de origen para nuestros informes de errores de Sentry.

ACTUALIZACIÓN: ejecutar ng update @angular/cli @angular/core resolvió el problema.

Ejecutar la actualización ng también funcionó para mí. Una de las versiones de puntos menores debe haber tenido una pérdida de memoria de algún tipo. Pasar de 8.2.8 a 8.2.11 solucionó el problema.

Con las últimas versiones del nodo se soluciona (al menos para mí). Recomiendo el nodo del equipo para usar en el package.json construye Engines:
https://docs.npmjs.com/files/package.json#Engines

Esto funciona para mí: https://stackoverflow.com/a/58916640/1077309

Tenía un objeto muy grande (una matriz de aproximadamente 100.000 elementos) que hacía que el constructor se bloqueara.

Quitar ese objeto resolvió el problema para mí.

(Como solución alternativa, ahora almaceno el objeto como una cadena / json y lo analizo en tiempo de ejecución).

[error] Error: Npm falló con el código de retorno: 3221226505

13 Error de pila detallado: [email protected] dev_build2019: node --max_old_space_size=8384 ./node_modules/@angular/cli/bin/ng build --configuration=dev
13 Estado de salida de pila detallada 3221226505
13 pila detallada en EventEmitter.(C: Archivos de programanodejsnode_modulesnpmnode_modulesnpm-lifecycleindex.js: 332: 16)
13 pila detallada en EventEmitter.emit (events.js: 210: 5)
13 pila detallada en ChildProcess.(C: Archivos de programanodejsnode_modulesnpmnode_modulesnpm-lifecyclelibspawn.js: 55: 14)
13 pila detallada en ChildProcess.emit (events.js: 210: 5)
13 pila detallada en maybeClose (internal / child_process.js: 1021: 16)
13 pila detallada en Process.ChildProcess._handle.onexit (internal / child_process.js: 283: 5)
14 pkgid detallado [email protected]
15 cwd detallado D: a1sPROP-VIVO-SPA
16 Windows_NT 10.0.14393 detallado
17 argv detallado "C: \ Archivos de programa \ nodejs \ node.exe" "C: \ Archivos de programa \ nodejs \ node_modules \ npm \ bin \ npm-cli.js" "ejecutar" "dev_build2019"
18 nodo detallado v12.13.0
19 npm detallado v6.12.0
20 código de error ELIFECYCLE
21 error errno 3221226505
22 error [email protected] dev_build2019: node --max_old_space_size=8384 ./node_modules/@angular/cli/bin/ng build --configuration=dev
22 error Estado de salida 3221226505
23 error Falló en el script [email protected] dev_build2019.
23 error Esto probablemente no sea un problema con npm. Es probable que haya una salida de registro adicional arriba.
24 salida detallada [3221226505, true]

Proporcione la solución para este problema de compilación

@PritiMaurya , prueba el siguiente comando para generar compilación

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

@ kumaresan-subramani estoy recibiendo un error
ERROR FATAL: Mark-compacts ineficaz cerca del límite del montón Error en la asignación: el montón de JavaScript sin memoria después de ejecutarlo por encima de cmd

@ kumaresan-subramani ¿sabes acerca del error?
Npm falló con el código de retorno: 3221226505

Recibo este error mientras construyo en vsts

@ kumaresan-subramani estoy recibiendo un error
ERROR FATAL: Mark-compacts ineficaz cerca del límite del montón Error en la asignación: el montón de JavaScript sin memoria después de ejecutarlo por encima de cmd

Puedes probar así

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

Verifique el nombre de su carpeta. Cambie el nombre sin espacios y reinicie su máquina.

No tengo ningún nombre de carpeta con espacio

@PritiMaurya , prueba la solución sugerida en este enlace . Podría ayudar.

No tengo ningún nombre de carpeta con espacio

reinicie amablemente su máquina.

Lo mismo con ng8 + node 10.16 + _not minitied_ build (descubrí que en mi caso el paquete Auth0Lock causa el problema)
En el nodo 12.13 todo se construye bien

Yo también estoy enfrentando este problema. Esta es mi configuración:

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

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

En Stack Overflow encontré esta solución . Funciona, pero no sé si este enfoque parece correcto o tiene sentido.

Actualicé node.js a la última versión LTS (en este momento 12.13.0 ) y todo funciona perfectamente. Ya no es necesario configurar el max-old-space-size .

¡Esto funcionó para mí!

Actualicé node.js a la última versión LTS (en este momento 12.13.0 ) y todo funciona perfectamente. Ya no es necesario configurar el max-old-space-size .

¡Esto funcionó para mí!

¡La actualización a la última versión de node.js también me funcionó!

Actualicé node.js a la última versión LTS (en este momento 12.13.0 ) y todo funciona perfectamente. Ya no es necesario configurar el max-old-space-size .

¡Esto funcionó para mí!

Actualicé node.js a la última versión LTS (en este momento 12.13.0 ) y todo funciona perfectamente. Ya no es necesario configurar el max-old-space-size .

Funcionó para mí también

Actualicé node.js a la última versión LTS (en este momento 12.13.0 ) y todo funciona perfectamente. Ya no es necesario configurar el max-old-space-size .

Funcionó para mí también

Puedo confirmar que esto está funcionando.

El mismo problema aqui. Angular 7. Cualquier versión de Node 12.X.

Funciona con el nodo 10.

Actualizar a 12.x funcionó para mí. Amar a Angular cada día menos ...

Cada lanzamiento recuerdo una presentación en NGConfg por uno de los miembros angulares que dice algo como:

"Tenemos más de 400 aplicaciones en Google y probamos angular antes de lanzarlo a la naturaleza. Si alguna de las aplicaciones tiene que cambiar para adaptar la actualización, no la lanzamos".

Creo que cada lanzamiento requirió algún tipo de actualización del código.

Por lo que recuerdo, dijeron que prueban las aplicaciones para asegurarse de que nada se rompa después de las actualizaciones de código necesarias. Creo que, de todos modos, actualizar el código para incorporar las mejoras es inevitable.

Pero este problema actual no tiene nada que ver con eso. Se trata más del tamaño de la aplicación. Si el tamaño de la aplicación está creciendo, deberá aumentar el tamaño del montón para el proceso de nodo.

Me acaba de pasar después de actualizar de 9.0.3 a 9.0.5

Hola a todos..
Estaba usando la instancia de ubuntu 18.04 EC2 para crear imágenes de Docker.
Este problema se resuelve tan pronto como cambio el tipo de instancia a t2.medium desde t2.micro.

Estaba enfrentando el mismo problema para ng serve,

npm cache clean --force resolver este problema

La actualización de NodeJS a la última versión me lo resolvió.

Lo resolví instalando Nodejs V12,
Estaba enfrentando un problema con Nodejs V10

El sábado 2 de mayo de 2020 a las 01:59, Igor Iric [email protected] escribió:

Node JS Update a la última versión lo resolvió por mí.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/angular/angular-cli/issues/13734#issuecomment-622554387 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AH6IJ4PME7KZY3J7J3ARITDRPMWLXANCNFSM4GY5SKAQ
.

Hola a todos, este problema es bastante antiguo en este punto y nos centramos principalmente en problemas de uso de recursos en la versión más reciente de CLI. Este problema también contiene varios problemas diferentes que parecen manifestarse de manera similar, lo que hace que sea difícil concentrarse. Si sigues teniendo problemas como este, abre un nuevo problema con los detalles de reproducción.

utilizar
" build: prod ": "node --max_old_space_size = 8000 ./node_modules/@angular/cli/bin/ng build --configuration = prod", en su archivo package.json

esto le dirá al nodo que exceda la asignación de memoria predeterminada según el tamaño dado en el comando.

Si ayuda a alguien más, cuando cambiamos de "@ angular-devkit / build-angular": "0.803.26" a "@ angular-devkit / build-angular": "0.803.27" hizo que la memoria se escapara durante prod se construye a ~ 43% de progreso de construcción. Se atascaría en este paso y aumentaría a> 25 GB de RAM en lugar de ~ 1,5 GB.

Cuando volvimos a cambiar a "@ angular-devkit / build-angular": "0.803.26", funcionó de nuevo. 0.803.27 es una versión reciente alrededor del 11/6/20, por lo que solo explicaría las nuevas apariciones de este problema.

Parece que el problema ha vuelto con la versión v10. Usando los paquetes @angular-devkit/build-angular v0.1000.0 y @angular/* v10.0.0 .

Nodo: v14.1.0
NPM: 6.14.5

Seguimiento de pila:

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

Después de actualizar Node.js a v14.4.0, el problema parece estar resuelto.

@Flyrell tengo el mismo problema con Nodejs 14.4.0 y Angular 10

@Flyrell tengo el mismo problema con Nodejs 14.4.0 y Angular 10 pero eso no parece resuelto

Sí, estaba usando el servidor de desarrollo por un poco más hoy y el problema aún existe.

Sí, el problema aún existe con angular 10 y nodejs 12.16.1 :(

@Flyrell @gvsakhil Evite comentar sobre temas cerrados que se refieran a versiones antiguas. Hay un problema abierto # 16860 para NG9, que sería más apropiado.

Tenga en cuenta que incluso ahora hay un problema # 18087 para Angular 10, que se cerró, por lo que puede esperar algunas mejoras con la próxima versión.

Este problema se ha bloqueado automáticamente debido a la inactividad.
Por favor, presente un nuevo problema si se encuentra con un problema similar o relacionado.

Obtenga más información sobre nuestra política de bloqueo automático de conversaciones .

_{_Esta acción ha sido realizada automáticamente por un bot._}