Esto es similar a https://github.com/angular/angular-cli/issues/1652 , pero parece estar localizado en las compilaciones de AOT. Podría haber mejoras que podamos hacer para ayudar.

También tengo el mismo problema.

Entonces, intenté construir el mismo proyecto ( @angular 4.0.0) usando ng-cli 1.0.0-rc.4 y funciona bien.
ng build --prod --aot

@ angular / cli: 1.0.0-rc.4
nodo: 6.9.5
sistema operativo: win32 x64
@ angular / común: 4.0.0
@ angular / compilador: 4.0.0
@ angular / núcleo: 4.0.0
@ angular / formas: 4.0.0
@ angular / http: 4.0.0
@ angular / plataforma-navegador: 4.0.0
@ angular / plataforma-navegador-dinámico: 4.0.0
@ angular / enrutador: 4.0.0
@ angular / cli: 1.0.0-rc.4
@ angular / compilador-cli: 4.0.0

También quiero agregar que aunque trato de aumentar max_old_space_size editando ng.cmd y ngc.cmd , parece que el proceso node.js nunca usa más de 1600 MB de RAM de acuerdo con el monitor de proceso en mi sistema, que está dentro del límite de configuración de 8192 MB y todavía dice "memoria insuficiente".

Tengo el mismo problema. mi proyecto funciona en cli rc.4. falla cuando ng build --prod después de actualizar a 1.0.0.

Me temo que no habrá solución para este problema.
Volví a rc.2 debido a esto :(

En mi caso, instalé [email protected] en lugar de @ ~ 2.2.0 y el problema de la memoria desapareció. Darle una oportunidad.

Hay un problema en ~ 2.2.0 y @ angular / language-service 4.0.0 (en mi caso lo uso)

Cambié max_old_space_size en% AppData% npm (Windows) y me funciona cuando lanzo ng serve con 1.0.0.

@efstahiosntonas ¿estás usando ng4?

@ zigzag95 sí, ng4

el mismo problema aqui

¡Gracias @AngelVlc !

¡Cambiar el límite en ng.cmd debajo de% appdata% funcionó! Ahora node.js usa alrededor de 4GB de RAM y la compilación está completa.

Recibo errores OOM con @ngtools/webpack 1.3.0 y @angular 4.0.0. Esto es en OSX y no también en Windows.

<--- Last few GCs --->

   17671 ms: Mark-sweep 1241.3 (1413.6) -> 1241.3 (1413.6) MB, 615.1 / 0.0 ms [allocation failure] [GC in old space requested].
   18286 ms: Mark-sweep 1241.3 (1413.6) -> 1241.3 (1413.6) MB, 614.2 / 0.0 ms [allocation failure] [GC in old space requested].
   18897 ms: Mark-sweep 1241.3 (1413.6) -> 1249.0 (1410.6) MB, 610.8 / 0.0 ms [last resort gc].
   19484 ms: Mark-sweep 1249.0 (1410.6) -> 1256.6 (1410.6) MB, 586.6 / 0.0 ms [last resort gc].


<--- JS stacktrace --->

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

Security context: 0x51588dcfb51 <JS Object>
    1: /* anonymous */ [/Users/chrisnicola/src/wealthbar/node_modules/webpack/node_modules/enhanced-resolve/lib/UnsafeCachePlugin.js:~28] [pc=0x33d385eb70d4] (this=0xd76ce5e1e71 <a Resolver with map 0x20b5bd9fe3f1>,request=0x3f6f1fa5ec39 <an Object with map 0x1fbc4c2b91c1>,callback=0xfd0ab9f8a9 <JS Function (SharedFunctionInfo 0x395f78d2a061)>)
    2: applyPluginsParallelBailResult1 [/Users/chri...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/usr/local/Cellar/node/6.9.1/bin/node]
 2: node::FatalException(v8::Isolate*, v8::Local<v8::Value>, v8::Local<v8::Message>) [/usr/local/Cellar/node/6.9.1/bin/node]
 3: v8::Utils::ReportApiFailure(char const*, char const*) [/usr/local/Cellar/node/6.9.1/bin/node]
 4: v8::Utils::ApiCheck(bool, char const*, char const*) [/usr/local/Cellar/node/6.9.1/bin/node]
 5: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/usr/local/Cellar/node/6.9.1/bin/node]
 6: v8::internal::Factory::NewInternalizedStringImpl(v8::internal::Handle<v8::internal::String>, int, unsigned int) [/usr/local/Cellar/node/6.9.1/bin/node]
 7: v8::internal::InternalizedStringKey::AsHandle(v8::internal::Isolate*) [/usr/local/Cellar/node/6.9.1/bin/node]
 8: v8::internal::StringTable::LookupKey(v8::internal::Isolate*, v8::internal::HashTableKey*) [/usr/local/Cellar/node/6.9.1/bin/node]
 9: v8::internal::StringTable::LookupString(v8::internal::Isolate*, v8::internal::Handle<v8::internal::String>) [/usr/local/Cellar/node/6.9.1/bin/node]
10: v8::internal::LookupIterator::LookupIterator(v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Name>, v8::internal::LookupIterator::Configuration) [/usr/local/Cellar/node/6.9.1/bin/node]
11: v8::internal::LookupIterator::PropertyOrElement(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>,v8::internal::Handle<v8::internal::Object>, bool*, v8::internal::LookupIterator::Configuration) [/usr/local/Cellar/node/6.9.1/bin/node]
12: v8::internal::Runtime::GetObjectProperty(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>) [/usr/local/Cellar/node/6.9.1/bin/node]
13: v8::internal::Runtime_KeyedGetProperty(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/Cellar/node/6.9.1/bin/node]
14: 0x33d384d092a7
[1]    9536 abort      npm start

El mismo problema aquí con:

@ angular / cli: 1.0.0-rc.2
nodo: 6.9.2
sistema operativo: darwin x64
@ angular / común: 2.4.10
@ angular / compilador: 2.4.10
@ angular / núcleo: 2.4.10
@ angular / formas: 2.4.10
@ angular / http: 2.4.10
@ angular / plataforma-navegador: 2.4.10
@ angular / plataforma-navegador-dinámico: 2.4.10
@ angular / enrutador: 3.4.10
@ angular / cli: 1.0.0-rc.2
@ angular / compilador-cli: 2.4.10

Tengo el mismo problema al ejecutar "ng build -w"
@ angular / cli: 1.0.0
nodo: 7.8.0
@ angular / * 4.0.2

setting --max_old_space_size = 8192 funciona para mí, pero no es realmente una buena solución ya que no puedo redistribuirlo con el código fuente a mis desarrolladores.

Sin embargo, una nota, hay un archivo ng.cmd y un archivo ng (el último es un archivo sh), y si está en Windows como nosotros, ambos se pueden usar dependiendo de si ejecuta ng desde git bash o cmd. ambos necesitan ser cambiados.

Mi solución al problema probablemente será cambiar el comando npm build de ng build para llamar a una copia del archivo ng bash que distribuyo con mi código.

@Ristaaf ¿Cómo cambió el archivo ng? ¿Dónde agregaste --max_old_space_size en este archivo? ¿Puedes compartir tu archivo?

@omeralper : esta es mi solución, requiere que la gente use git bash como terminal si está en Windows, pero sería fácil de cambiar si fuera necesario (solo use el archivo cmd en su lugar):

En la raíz de mi proyecto tengo una carpeta llamada scripts y en ella un archivo llamado ng.sh, que es una copia de node_modules / .bin / ng pero con más RAM permitida para ser utilizada

#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")

case `uname` in
    *CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac

if [ -x "$basedir/node" ]; then
  "$basedir/node" --max_old_space_size=8192 "./node_modules/@angular/cli/bin/ng" "$@"
  ret=$?
else
  node --max_old_space_size=8192 "./node_modules/@angular/cli/bin/ng" "$@"
  ret=$?
fi
exit $ret

Luego, en mi package.json hago:

"scripts": {
    "build-prod": "bash ./scripts/ng.sh build --prod --aot --env=prod"
}

Estoy experimentando un problema similar que resulta en un error JavaScript heap out of memory al llamar a ng e2e en un proyecto usando:

• @angular/[email protected]
• @angular/*@4.1.0
• [email protected]

Pude crear una solución alternativa multiplataforma cambiando la entrada de script package.json e2e a:

    "test-browser-e2e-cucumber": "node --max_old_space_size=4096 node_modules/@angular/cli/bin/ng e2e --webdriver-update",

En windows
@IF EXISTE "% ~ dp0node.exe" (
"% ~ dp0node.exe" --max_old_space_size = 4096 "% ~ dp0node_modules @ angular \ cli \ bin \ ng"% *
) DEMÁS (
@SETLOCAL
@SET PATHEXT =% PATHEXT:;. JS; =;%
node --max_old_space_size = 4096 "% ~ dp0node_modules @ angular \ cli \ bin \ ng"% *
)

consulte este paquete npm https://github.com/endel/increase-memory-limit

Escribí un pequeño script que me permite controlar el límite de memoria en la sección de configuración de package.json .
https://github.com/isaacplmann/angular-cli-alias

increase-memory-limit ve bastante dulce. No existía cuando escribí mi guión y no te permite establecer tu propio límite de memoria.

he podido reproducir esto con un caso de prueba mínimo usando una aplicación cli lista para usar; archivo relevante aquí .

Básicamente, parece que intentar hacer coincidir un comodín sin especificadores hará explotar la aplicación, lo cual es extraño ya que el caso de prueba se extrae casi directamente de la documentación mecanografiada .

tenga en cuenta que "*": ["*"] no bloquea la aplicación, solo "*": ["*", "$dir/*"]

Como solución alternativa, he especificado manualmente cada uno de mis mapas de ruta, lo cual es molesto pero me permite compilar:

"paths": {
  "app.*": ["app/app.*"],
  "app-*": ["app/app-*"],
  "authentication/*": ["app/authentication/*"],
  "core/*": ["app/core/*"],
  "navigation/*": ["app/navigation/*"],
  "pages/*": ["app/pages/*"]
}

También encontramos ese problema en NativeScript cuando usamos el complemento @ngtools/webpack con nativescript-dev-webpack . Usamos rutas tsconfig para mapear nuestros módulos tns-core-modules. Se ven así:

"paths": {
  "*": [
    "./node_modules/*",
    "./node_modules/tns-core-modules/*"
  ]
}

Sin embargo, la agrupación falla con el error mencionado (montón de JavaScript sin memoria). Al igual que @zackschuster , como solución alternativa, especificamos cada mapeo de ruta manualmente:

"paths": {
  "application": ["node_modules/tns-core-modules/application"],
  "application-settings": ["node_modules/tns-core-modules/application-settings"],
  "camera": ["node_modules/tns-core-modules/camera"],
  "color": ["node_modules/tns-core-modules/color"],
  "connectivity": ["node_modules/tns-core-modules/connectivity"],
  "console": ["node_modules/tns-core-modules/console"],
  "data/*": ["node_modules/tns-core-modules/data/*"],
  "fetch": ["node_modules/tns-core-modules/fetch"],
  "file-system": ["node_modules/tns-core-modules/file-system"],
  "fps-meter": ["node_modules/tns-core-modules/fps-meter"],
  "globals": ["node_modules/tns-core-modules/globals"],
  "http": ["node_modules/tns-core-modules/http"],
  "image-asset": ["node_modules/tns-core-modules/image-asset"],
  "image-source": ["node_modules/tns-core-modules/image-source"],
  "location": ["node_modules/tns-core-modules/location"],
  "platform": ["node_modules/tns-core-modules/platform"],
  "text": ["node_modules/tns-core-modules/text"],
  "timer": ["node_modules/tns-core-modules/timer"],
  "trace": ["node_modules/tns-core-modules/trace"],
  "ui/*": ["node_modules/tns-core-modules/ui/*"],
  "utils/*": ["node_modules/tns-core-modules/utils/*"],
  "xhr": ["node_modules/tns-core-modules/xhr"],
  "xml": ["node_modules/tns-core-modules/xml"]
}

@ sis0k0 ¿cómo son los tiempos de recompilación con esa configuración? Estaba obteniendo recompilaciones de 40-50 segundos (en un proyecto absurdamente pequeño) hasta que eliminé los mapas de ruta, momento en el que bajó a ~ 2 segundos.

@zackschuster
¿A qué te refieres con mapas de ruta?

@ zigzag95

"paths": {
 // ...
}

@zackschuster , tiempos similares.

https://github.com/angular/angular-cli/issues/5618#issuecomment -304545043

Probé el paquete de aumento de límite de memoria y todavía obtengo el montón de Javascript sin memoria

Sigue siendo un problema en 4.2.6, macOS, incluso cuando se le da 8GB al nodo.

Este es un problema bastante serio ... es hora de solucionarlo.

¡Es hora de arreglar esto! En un gran proyecto real, ¡angular es malo por eso! ¡¡Quizás un problema con el paquete web !! Gracias

Me pregunto si la solución es AOT por módulo, luego un paso de enlace separado. No estoy seguro de si es posible implementarlo ... En ese caso, lo que se pierde en las opciones globales debe recuperarse en un LTO.

¿Todavía nada sobre esto?

Estoy usando @ angular / cli 1.0.0-rc.4, si actualizo a 1.0.0 me da el error de
CLI angular ERROR FATAL: CALL_AND_RETRY_LAST Error en la asignación: pila de JavaScript sin memoria

Ahora entendemos por qué Google no usa webpack con ng para sus aplicaciones

Trabajar alrededor de la solución
Pude solucionar el problema cambiando mi archivo ng.cmd a
<strong i="7">@IF</strong> EXIST "%~dp0\node.exe" ( "%~dp0\node.exe" --max_old_space_size=8192 "%~dp0\node_modules\@angular\cli\bin\ng" %* ) ELSE ( <strong i="8">@SETLOCAL</strong> <strong i="9">@SET</strong> PATHEXT=%PATHEXT:;.JS;=;% node --max_old_space_size=8192 "%~dp0\node_modules\@angular\cli\bin\ng" %* )

@cimachris esto no es exactamente una solución, sino más bien una solución que posiblemente puede posponer el problema

¿Eso está mejor?

@hansl @filipesilva No puedo actualizar mi aplicación a angular / cli 1.0.0, ya que estoy en angular / cli 1.0.0.rc-4, no quiero dar el salto a la última versión sin probar mi componentes

@cimachris ya estamos más allá del truco "--max_old_space_size". Una vez que la aplicación se vuelve lo suficientemente grande, muchas compilaciones son imposibles debido a este problema. Por supuesto, somos un caso extremo, porque tenemos muchos componentes generados (basados ​​en definiciones de un sistema heredado recortadas en la pantalla), pero aún así debería compilarse, por supuesto. Este es un error muy grave en mi opinión.

Se han visto afectados por este problema desde que se lanzó @ angular / cli 1.0
Pero actualmente podemos solucionarlo ejecutando
ng build --aot --sourcemaps = false --environment = prod

No es exactamente lo mismo que el parámetro --prod, pero al menos funciona.

ng e2e también da como resultado un error similar:

 92% chunk asset optimization
<--- Last few GCs --->

[2164:000002C715EFDC90]   117246 ms: Mark-sweep 1401.4 (1543.7) -> 1401.3 (1545.7) MB, 1088.0 / 0.0 ms  allocation failure GC in old space requested
[2164:000002C715EFDC90]   118473 ms: Mark-sweep 1401.3 (1545.7) -> 1401.2 (1504.2) MB, 1227.0 / 0.0 ms  last resort
[2164:000002C715EFDC90]   119591 ms: Mark-sweep 1401.2 (1504.2) -> 1401.1 (1504.2) MB, 1117.8 / 0.0 ms  last resort


<--- JS stacktrace --->

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

Security context: 000000799D9A66A1 <JS Object>
    2: addMapping(aka SourceMapGenerator_addMapping) [xxx\node_modules\source-map\lib\source-map-generator.js:~94] [pc=0000003D3772300C](this=0000022DE262CAF1 <a SourceMapGenerator with map 000000A8E17906F1>,aArgs=0000005D8F791BF9 <an Object with map 00000399007FF561>)
    3: /* anonymous */ [xxx\node_modules\source-map\l...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

@filipesilva Esto es bastante serio y la solución no siempre funciona; parece afectar a todos los proyectos medianos / grandes. Necesidades resueltas para que angular + angularcli siga siendo una tecnología viable para proyectos web serios.

@ edmund-lee

ng build --aot --sourcemaps = false --environment = prod

No es exactamente lo mismo que el parámetro --prod, pero al menos funciona.

No funciona para proyectos suficientemente grandes.

@ angular / cli: 1.2.3
nodo: 6.10.0
sistema operativo: linux x64
@ angular / animaciones: 4.3.1
@ angular / común: 4.3.1
@ angular / compilador: 4.3.1
@ angular / núcleo: 4.3.1
@ angular / formas: 4.3.1
@ angular / http: 4.3.1
@ angular / plataforma-navegador: 4.3.1
@ angular / plataforma-navegador-dinámico: 4.3.1
@ angular / enrutador: 4.3.1
@ angular / cli: 1.2.3
@ angular / compilador-cli: 4.3.1
@ angular / language-service: 4.3.1

Aplicación con 3 módulos y aproximadamente 50 componentes, después de cambiar @ angular / cli de 1.1.xa 1.2.x

ng build -target=production

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [@angular/cli]
 2: 0x109bf8c [@angular/cli]
 3: v8::Utils::ReportApiFailure(char const*, char const*) [@angular/cli]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [@angular/cli]
 5: v8::internal::Factory::NewInternalizedStringImpl(v8::internal::Handle<v8::internal::String>, int, unsigned int) [@angular/cli]
 6: v8::internal::StringTable::LookupString(v8::internal::Isolate*, v8::internal::Handle<v8::internal::String>) [@angular/cli]
 7: v8::internal::LookupIterator::PropertyOrElement(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, bool*, v8::internal::LookupIterator::Configuration) [@angular/cli]
 8: v8::internal::Runtime::GetObjectProperty(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>) [@angular/cli]
 9: 0xed3501 [@angular/cli]
10: v8::internal::Runtime_KeyedGetProperty(int, v8::internal::Object**, v8::internal::Isolate*) [@angular/cli]
11: 0x2174585092a7
Aborted (core dumped)

Análisis de raíz de la causa:

• OOM en la máquina CI (también después de agregar --max-old-space-size = 4096 al nodo) debido a un enlace simbólico roto

Después de arreglarlo:

ng build --prod

ERROR in ./src/main.ts Module not found: Error: Can't resolve './$$_gendir/app/app.module.ngfactory' @ ./src/main.ts 3:0-74 @ multi ./src/main.ts
'
Actualizado @ angular / cli a 1.2.4, todavía obteniendo el mismo error (hilo)

Después de mirar el número 7125, parecía que se trataba de un problema de dependencia de paquetes relacionado con aot.
Volviendo a npm lo solucionó.

También he visto aparecer este error al usar @ngtools/webpack por sí mismo. Curiosamente, no sucede hasta después de algunas reconstrucciones, lo que implica que hay una gran pérdida de memoria en algún lugar del paquete web (dudoso) o del complemento ngtools.

esto es tan java :))

Mismo problema. Tan pronto como el proyecto gana tamaño, esto sucede.

Exactamente el mismo error aquí, pero con @ngtools/webpack
Intenté ejecutarlo con Node LTS 6.11.2 y Node Latest también 8.2.1
Probé con Typecript 2.3.2 y 2.4.2 .
Todos mis paquetes angulares están en 4.3.3

AoT es bastante necesario para aplicaciones grandes, por lo que es un poco irónico que no podamos obtenerlo, así que compárelo para esas.

después de actualizar a angular / [email protected] tiene el mismo problema.

@ angular / cli: 1.3.0
nodo: 8.2.1
sistema operativo: darwin x64
@ angular / animaciones: 4.3.3
@ angular / común: 4.3.3
@ angular / compilador: 4.3.3
@ angular / núcleo: 4.3.3
@ angular / formas: 4.3.3
@ angular / http: 4.3.3
@ angular / plataforma-navegador: 4.3.3
@ angular / plataforma-navegador-dinámico: 4.3.3
@ angular / enrutador: 4.3.3
@ angular / cli: 1.3.0
@ angular / compilador-cli: 4.3.3

mando:
ng build -prod --build-optimizer --aot = true --progress = false --sourcemap

Solo como un aviso. Resulta que cuando uso YARN en lugar de NPM para RESTAURAR paquetes, la compilación se completa con éxito.

estoy usando

ng build --env=prod --aot

Cuando restauro paquetes usando npm install, el mismo error de este problema (memoria insuficiente)
Cuando restauro paquetes usando yarn install - sin error - éxito

También obtuve este error después de actualizar a @ angular / cli 1.3.0.

Problema resuelto después de actualizar mecanografiado tanto local como globalmente a 2.4.2

También tengo este error.

Bloquear @ ngtools / webpack a la versión 1.5.4 ayuda.

Tuve que aumentar la memoria dada a Node, así como subir TS a 2.4.2, pero después de eso obtuve una compilación exitosa. esperando el compilador NG5 AoT

El mismo problema aquí después de actualizar a @ angular / cli 1.3.0.

@williangd también para mí con 1.3.0

También he tenido el problema de falta de memoria al ejecutar ng serve . Funciona bien durante horas, pero si he estado desarrollando durante un tiempo (lo he visto entre 2 y 5 horas), saldré de la memoria. Cuando vuelvo a ejecutar el comando de servicio, normalmente puedo hacerlo durante otras 2-5 horas. La primera vez que vi esto fue al actualizar a una versión beta de 1.3, pero no he visto una mejora con la versión actual.

Para mí también pasa con el "ng serve" normal después de actualizar a la versión 1.3, cada vez que el proyecto se recompila, toma más tiempo que el anterior (6s, 10s, 30s, 60s) y después de 4 o 5 veces, se apaga. de memoria.

Mismo problema.

95% emisor
<--- Últimos GC --->

160332 ms: Mark-sweep 1346,8 (1439,3) -> 1346,7 (1439,3) MB, 648,6 / 0,0 ms [error de asignación] [el barrido podría no tener éxito].
160934 ms: Mark-sweep 1346,7 (1439,3) -> 1346,8 (1439,3) MB, 602,0 / 0,0 ms [error de asignación] [el barrido podría no tener éxito].
161564 ms: Mark-sweep 1346,8 (1439,3) -> 1346,8 (1423,3) MB, 629,5 / 0,0 ms [último recurso gc].
162181 ms: Mark-sweep 1346,8 (1423,3) -> 1346,7 (1423,3) MB, 616,9 / 0,0 ms [gc de último recurso].

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

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

Contexto de seguridad: 0000009DB903FA99
1: DoJoin (también conocido como DoJoin) [native array.js: ~ 129] [pc = 000000A40AE7FE82] (this = 0000009DB9004241, w = 00000355FBAF7F99, J = 0
000009DB904A369 2: Join (también conocido como Join) [native array.js: 180] [pc = 000000A406C83FF2] (this = 0000009DB9004241...

ERROR FATAL: CALL_AND_RETRY_LAST Error en la asignación: pila de JavaScript sin memoria

tsc -v
Versión 2.4.2

@ angular / cli: 1.3.0
nodo: 6.11.2
sistema operativo: win32 x64

¿Cómo está funcionando la actualización a mecanografiado 2.4.2? Obtendrá problemas de compilación de RxJs ya que 2.4 rompieron los tipos de rxjs

Este problema también le está sucediendo a nuestro proyecto. No se puede construir aot en el servidor de compilación con el mismo montón de javascript sin memoria. También estamos utilizando el soporte experimental webpack 3.

@sbabeal solo ve a RxJS 5.4.2

Para nosotros - construyendo localmente con
ng build --target=production --environment=prod --base-href /myproject/ --aot --build-optimizer
funciona bien, pero cuando lo construimos en nuestro servidor, obtenemos el
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
error. Sin embargo, si eliminamos el --build-optimizer, todo funcionará bien.

Intenté agregar la biblioteca increase-memory-limit , pero sin suerte.

¿Existe una solución para esto que realmente funcione?

Saludos cordiales Chris

Probé la última versión de mecanografiado y todavía no ayudó. A nivel local, se construye pero consume 1,5 gigas de memoria. Parece bastante excesivo.

92% de optimización de fragmentos de activos
<--- Últimos GC --->

[3933: 0x2a7d710] 355436 ms: Mark-sweep 1395.8 (1546.4) -> 1395.3 (1546.4) MB, falla de asignación de 975.3 / 0.0 ms GC en el espacio anterior solicitado
[3933: 0x2a7d710] 356584 ms: Mark-sweep 1395,3 (1546,4) -> 1395,3 (1546,9) MB, 976,0 / 0,0 ms error de asignación GC en el espacio antiguo solicitado
[3933: 0x2a7d710] 357953 ms: Mark-sweep 1395,3 (1546,9) -> 1395,3 (1539,9) MB, 1195,7 / 0,0 ms último recurso
[3933: 0x2a7d710] 359143 ms: Mark-sweep 1395,3 (1539,9) -> 1395,3 (1539,9) MB, 1188,8 / 0,0 ms último recurso

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

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

ERROR FATAL: CALL_AND_RETRY_LAST Error en la asignación: pila de JavaScript sin memoria
1: nodo :: Abort () [@ angular / cli]
2: 0x12b717c [@ angular / cli]
3: v8 :: Utils :: ReportOOMFailure (char const , bool) [@ angular / cli]4: v8 :: internal :: V8 :: FatalProcessOutOfMemory (char const , bool) [@ angular / cli]
5: v8 :: internal :: Factory :: NewCode (v8 :: internal :: CodeDesc const &, unsigned int, v8 :: internal :: Handle <: internal :: object i = "18">, bool, bool, int , bool) [@ angular / cli]
6: v8 :: internal :: CodeGenerator :: MakeCodeEpilogue (v8 :: internal :: MacroAssembler , v8 :: internal :: EhFrameWriter , v8 :: internal :: CompilationInfo , v8 :: internal :: Handle <: internal :: object i = "22">) [@ angular / cli]7: v8 :: internal :: FullCodeGenerator :: MakeCode (v8 :: internal :: CompilationInfo , unsigned long) [@ angular / cli]
8: v8 :: internal :: FullCodegenCompilationJob :: ExecuteJobImpl () [@ angular / cli]
9: v8 :: internal :: CompilationJob :: ExecuteJob () [@ angular / cli]
10: 0xd577dc [@ angular / cli]
11: 0xd59faa [@ angular / cli]
12: 0xd5b7a9 [@ angular / cli]
13: v8 :: internal :: Compiler :: Compile (v8 :: internal :: Handle <: internal :: jsfunction i = "30">, v8 :: internal :: Compiler :: ClearExceptionFlag) [@ angular / cli]
14: v8 :: internal :: Runtime_CompileLazy (int, v8 :: internal :: Object *, v8 :: internal :: Isolate ) [@ angular / cli]
15: 0x3e6ef29040c7
Abortado (núcleo volcado)

Parece que enfrentamos el error incluso al asignar 12 GB de memoria para la compilación.
¿Hay alguna forma de depurar lo que está causando la pérdida de memoria? Además, ¿podría esto resolverse implementando la carga diferida de módulos, ya que esto es durante el tiempo de compilación?

Comandos utilizados:
1.node --max_old_space_size = 12000 ./node_modules/@angular/cli/bin/ng build --prod --aot --env = prod

1. actualizó el ng para aceptar el parámetro --max_old_space_size

La compilación solo funciona con --sourcemap = false y --aot = false; pero esto está causando pérdidas de memoria y problemas de carga de páginas en el navegador debido al enorme tamaño de la aplicación.

S tackTrace: -
[INFO]
[INFO] <--- Últimos GC --->
[INFO]
[INFO] [11944: 0x2710b70] 898052 ms: Mark-sweep 11998.2 (13529.5) -> 11998.2 (13529.5) MB, 4991.9 / 0.0 ms falla de asignación GC en el espacio anterior solicitado
[INFO] [11944: 0x2710b70] 903445 ms: Mark-sweep 11998.2 (13529.5) -> 11998.1 (13434.0) MB, 5366.9 / 0.0 ms último recurso
[INFO] [11944: 0x2710b70] 908749 ms: Mark-sweep 11998.1 (13434.0) -> 11998.1 (13378.0) MB, 5266.9 / 0.0 ms último recurso
[INFO]
[INFO]
[INFO] <--- seguimiento de pila JS --->
[INFO]
[INFO] ==== Seguimiento de pila JS ====================================== =
[INFO]
[INFO] Contexto de seguridad: 0x2b8a8b3a66a1
[INFO]

No sé si puede ayudar a alguien, pero tuvimos el mismo problema después de actualizar a la versión 1.3.0. Y también tuvimos otros problemas: compilación lenta y nombres incorrectos para el fragmento generado.

Todos nuestros problemas se resolvieron con esto: https://github.com/angular/angular-cli/pull/7338

FTR, para un proyecto, abandonamos Angular debido a esto. Ya no ayuda la cantidad de --max_old_space_size.

Gran trabajo enajenando a los usuarios empresariales.

Siempre hay una opción para expulsar la aplicación.

¿Qué quieres decir con expulsar la aplicación?

El martes 22 de agosto de 2017 a las 5:12 p.m., Arseny E. Naryshkin <
[email protected]> escribió:

Siempre hay una opción para expulsar la aplicación.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/angular/angular-cli/issues/5618#issuecomment-324021572 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADuwsXkLSkoHTg9-AMuUESUfM2sCLVbOks5satPRgaJpZM4Mn-Nn
.

Sigue siendo un problema para nosotros incluso después de la actualización de CLI a 1.3.1 y la actualización de @angular a 4.3.5

Probé mecanografiado 2.5 pero encontré algunos problemas de compilación. estamos en 2.4.2.

editado:

En nuestras máquinas locales o en nuestras instancias de gitlab runner no podemos reproducir el problema. Por alguna razón, la compilación solo falla en nuestra caja jenkins. La única diferencia que he podido recopilar es que jenkins está en una versión un poco más antigua de la versión de node / npm:

v6.9.1
3.10.8

en lugar de

v6.11.0
3.10.10

_corregido_ cambiando nuestro script de construcción npm de producción a:

"build-prod": "node --max_old_space_size=4096 ./node_modules/@angular/cli/bin/ng build --prod --aot",

No es tanto un _fix_ como una solución de fuerza bruta, pero al menos ganará tiempo mientras averiguamos qué está consumiendo todo el espacio del montón.

@Masquer ¿cómo ayudaría la expulsión? En realidad, es un problema de paquete web.

@notsonotso oh, entonces no lo será.

mi aplicación, sin embargo, no se compila con ng con el error 'montón sin memoria', pero lo hace como se expulsa.

Aquí hay un problema relacionado y resuelto en angular-seed . Espero que esto ayude a alguien.

Ninguna cantidad de configuración max-old-space-size ayudó en nuestro proyecto. Sin embargo, como solo compilamos AOT en prod, hemos deshabilitado temporalmente los mapas de origen que parecían solucionarlo en nuestro servidor de CI.

Al igual que @mattem ,

El mismo problema, pero hemos encontrado una solución alternativa más confiable para aumentar el límite de memoria.

Desde el Nodo 8.x, puede establecer una variable de entorno NODE_OPTIONS y pasar la bandera --old-max-space-size . Actualmente necesitamos 6GB.

Por ejemplo, en Windows CMD: set NODE_OPTIONS=--old-max-space-size=6411 antes de ejecutar la compilación AOT.

Me pregunto si hay un proceso hijo que no obtiene los argumentos que se establecen en el ejecutable del nodo.

Lo sé, y créame, estoy luchando mucho con esto. No es divertido cuando el servidor de compilación comienza a quedarse sin memoria. Es un problema grave que debe abordarse. Esta solución me ayudó a avanzar un poco más, como si apagara los mapas de origen. Su experiencia puede ser diferente.

Hola.
este problema es serio.

En mi computadora estaba limitando a 8Gb y la compilación ng funcionaba bien.
(con tamaño de espacio máximo antiguo)

Pero ahora tengo un gran proyecto y créanme, no tengo memoria.

Tengo un generador de código que lo construye todo a la perfección.
pero el nuevo proyecto cuenta con más de 200 entidades.
La creación de módulos y la carga diferida depende de la configuración realizada por el cliente y sus entidades.

No quisiera separar en varias aplicaciones porque hay mucha dependencia.
(200 servicios, 600 componentes)

El proyecto funciona bien con ng serve, pero no con ng build.
Alquilé una máquina virtual con 28 Gb de RAM y créanme, hice la construcción usando 27 Gb de RAM.
El nodo de servicio ocupaba exactamente 27 Gb.

(Pongo el límite de 28gb)

Todo funciona bien con ng serve.

¿Alguien puede saber que me diga si solo separándose en varios módulos de carga diferida necesitará menos memoria para compilar con ng build? ¿O funciona solo para separar el JS?

No puedo alquilar una máquina virtual cada vez que necesito ejecutar ng build.
Y el esfuerzo de cambio será altísimo.
Así que necesitaba estar seguro de qué hacer.

Gracias.

@Tolitech En lugar de depender de tener suficiente RAM para que esto se compile, simplemente agregue swap a su máquina. La compilación será un poco más lenta, pero no es necesario alquilar máquinas con 28 GB de RAM.

Yo también quiero que esto se resuelva lo antes posible, pero agregar espacio de intercambio soluciona el problema de la memoria.

@joecot Gracias.
Intentaré hacer esto y ver si funciona.
Si funciona, no veo ningún problema si tarda 8 horas.
Dejo un trabajo nocturno para publicarlo sin problemas.

Esa fue una buena idea.
Voy a tratar de.

Gracias.

@joecot @notsonotso
Funcionó.
Configuré memoria virtual de 32 Gb (intercambio), --max_old_space_size y finalmente funcionó.
Usó 28gb (es demasiado alto), pero funcionó.
Muchas gracias por la idea, @joecot

@mhevery @bradlygreen : disculpas por llevarte a este, pero con el caso extremo de @Tolitech anterior, la propuesta de valor de Angular está comenzando a debilitarse seriamente.

Nuestro código base está creciendo rápidamente y nuestro equipo se encuentra continuamente con estos problemas de memoria, donde incluso llegamos a las limitaciones de nuestro desarrollo y construcción de máquinas. En todos mis años de desarrollo web, nunca ha habido un caso en el que me quede sin las capacidades de la máquina, solo para compilar en varios archivos de 300k para mi aplicación web / sitio web. Parece ser una optimización de la memoria o un problema de arquitectura que, con suerte, se puede evitar.

Ya hemos perdido innumerables horas en estos problemas, y la premisa de que Angular es un marco que se adapta a las grandes aplicaciones empresariales ya no se sostiene.

Realmente apreciaría si se pudiera priorizar este problema, ya que realmente estoy comenzando a dudar si nuestra elección de Angular como un marco adecuado fue correcta, considerando que solo las compilaciones de AOT tienen un rendimiento y son lo suficientemente pequeñas como para enviarlas a los clientes por cable. y que estamos luchando para que funcionen. Gracias.

@bgever Aparentemente, Google no está usando angular-cli / webpack ellos mismos, por lo que no se encuentran con problemas como este. Sospecho que esta es la razón por la que este problema recibe tan poca atención de los desarrolladores angulares. Si esto continúa, se debe advertir públicamente a la comunidad que el angular no es adecuado para proyectos grandes.

Fuiste perfecto en tus palabras, @bgever .
Ya estoy pensando que Angular no funciona para aplicaciones grandes, después de todo, ahora necesito 28 Gb de RAM y el proyecto podría crecer más. (Este es el primer día de esta aplicación).

Ya estoy pensando en otra estrategia para este tipo de proyectos, tal vez incluso cambiar de tecnología porque me estoy dando cuenta de que este problema está ocurriendo con mucha gente y desde hace mucho tiempo.

Creo que mi cliente no me aceptará diciendo que necesita 28 Gb de RAM para compilar su propio proyecto.
Estoy muy preocupado por esto.

Solo me quedo en Angular CLI 1.2.7 mientras arreglan esto, espero que lo hagan pronto, pero con 1.2.7 no tengo ningún problema de memoria.

Aquí igual. Ejecución de Angular CLI 1.3.2 y Angular 4.3.6. Agregué esto basado en otro hilo para que funcione. Mi aplicación no es muy grande, pero CLI registró 4 GB para crear mi aplicación.

"scripts": {
    "build": "node --max_old_space_size=8192 ./node_modules/@angular/cli/bin/ng build --target production --environment prod --aot",
    "ng": "ng",
    "start": "ng serve",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },

@bjornharvold @Tolitech Necesitamos 1024go ram 32ghz cpu, entonces 32'000'000'000 cálculo por segundo para construir angular pero si aprendes bazel de google puede ser más rápido 😂

https://github.com/endel/increase-memory-limit

Esto funcionó para mi

El mismo problema aqui.

Tuve que degradar a @ angular / cli 1.2.6 con TS 2.4.2 para que la compilación vuelva a funcionar.

Es una pena que no pueda usar el último cli angular ... ¿Por qué no se considera un error grave?

@hugodes

¿Por qué esto no se considera un error grave?

Creo que es por https://github.com/angular/angular/issues/19058

¡La última versión es la misma!

Lo mismo aquí, esto es ridículo. Estoy usando un servidor VPS barato para construir y simplemente falla con 2GB de memoria

Lo que me resolvió fue hacer ng build --prod en lugar de ng build --aot --prod.

La opción --prod ya incluye la opción --aot, y optimiza el proceso de compilación y ya no recibo errores de memoria.

Espero que ayude a algunos de ustedes.

Prueba -sm false

Me sucede cuando el parámetro es allowJS _true_ en tsconfig.json. Aparentemente, los archivos javascript están sobrecargando la memoria.

Esto funcionó para mí, agregue a la sección de scripts de package.json. Al observar el uso de la memoria en el administrador de tareas, llegó a un uso de alrededor de 4 GB. ¡Parece un toque excesivo!

"build2": "nodo --max_old_space_size = 8192 ./node_modules/@angular/cli/bin/ng build --prod --aot"

npm ejecutar build2

Este comando funciona para mí:
node --max-old-space-size = 4096 ./node_modules/@angular/cli/bin/ng build --prod

"guiones":{
"prod": "nodo --max-old-space-size = 4096 ./node_modules/@angular/cli/bin/ng build --prod"
}

prueba process.nextTick ()？

Con Node 8.xy la última versión de cli funciona sin ningún truco :)

Es triste ver que han pasado meses y este problema aún no está resuelto. Tengo el mismo problema aquí:

´
ng build --aot

92% de optimización de fragmentos de activos
<--- Últimos GC --->

191455 ms: barrido de marca 1296,7 (1433,7) -> 1291,4 (1434,7) MB,
1052,3 / 0,0 ms [error de asignación] [GC en solicitud de espacio antiguo
ed].
192605 ms: barrido de marcas 1291,4 (1434,7) -> 1291,4 (1434,7) MB,
1150,6 / 0,0 ms [error de asignación] [GC en solicitud de espacio antiguo
ed].
193711 ms: barrido de marca 1291,4 (1434,7) -> 1294,8 (1403,7) MB,
1105.0 / 0.0 ms [último recurso gc].
194808 ms: barrido de marcas 1294,8 (1403,7) -> 1298,3 (1403,7) MB,
1097,0 / 0,0 ms [último recurso gc].

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

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

Contexto de seguridad: 00000146E3DCF791
2: addMapping (también conocido como SourceMapGenerator_addMapping) [D: \ Users
\ andre.marcondes \ proyectos \ lender-platformnode_modules \ source-
map \ lib \ source-map-generator.js: ~ 94] [pc = 00000339B436339E] (th
es = 0000015776039641 AA599>, aArgs = 00000004C17F22D1 0DD9>)
3: / * anónimo * / [D: \ Users \ andre.marcondes \ projects \ lend
er-platformnode ...

ERROR GRAVE: CALL_AND_RETRY_LAST La asignación falló - JavaScrip
t se queda sin memoria
´

ERROR FATAL: CALL_AND_RETRY_LAST Error en la asignación: pila de JavaScript sin memoria
npm ERR! código ELIFECYCLE
npm ERR! errno 3
npm ERR! [email protected] compilación: prod : ng build --env=prod --prod --aot --stats-json --named-chunks=true --sourcemaps=false
npm ERR! Estado de salida 3

==== actualizar ======
El problema para mí es --stats-json. La compilación está bien después de eliminar esta bandera.

Las optimizaciones son bienvenidas, pero por otro lado la memoria es barata. Hasta que las optimizaciones estén aquí, ejecute la compilación usando

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

y agregue los interruptores que desee al final. Para que sea más fácil de ejecutar, edite su archivo package.json y agregue esta línea a "scripts":

"serve": "node --max-old-space-size=8192 ./node_modules/@angular/cli/bin/ng serve --aot"

Entonces puedes ejecutarlo usando

npm run serve

Soy un antiguo desarrollador de Java, por lo que esto me parece familiar de alguna manera :)

@swftvsn , la memoria es barata si tienes control sobre ella, pero la implementamos en un enjambre de Docker y los contenedores tienen memoria limitada. Este es un problema bastante serio para nosotros. Preferiría una compilación más lenta si eso significa almacenar cosas en caché en el disco y no quedarse sin memoria.

Recibo este problema después de actualizar a cli 1.5 y angular 5.0.

Quiero resaltar la pregunta anterior:

• ¿Angular está diseñado para el desarrollo empresarial?

Estoy tan confundido por qué cualquier compilador necesitaría 4 gigas de memoria para compilar una aplicación web ..... Para que compilara una actualización posterior, tuve que conectar la memoria hasta 4 gigas. Nuestra aplicación tiene 2 bibliotecas de módulos de funciones, cada una con aproximadamente 15 módulos, ~ 60 módulos en la aplicación principal y ~ 15 servicios. También nos queda mucho por construir.

Me imagino que tiene que ver con la cantidad obscena de dependencias + todos los aros que se hacen para analizar estadísticamente todas las dependencias y su código para sacudir los árboles. Eche un vistazo a node_modules si se atreve. (Y mapas de origen / depuración y cosas que ni siquiera conozco)

El consumo excesivo de memoria generalmente es causado por una gran cantidad de datos y / o abstracción sobre abstracción sobre abstracción sobre ... :) O un error.

Por ahora estoy feliz y solo alimento a la bestia. Sin embargo, espero que pierda algo de apetito en las próximas versiones ...

Estoy menos preocupado por "¿cómo es posible que esto ...?" que yo por la falta de comunicación.

La compilación en sí está haciendo un trabajo bastante pesado en este momento. De hecho, es realmente genial. Toda la CLI es. Empaqueta esto y lo sirve de manera bastante compacta. De hecho, este puede ser un testimonio de lo fácil que es Angular para crear aplicaciones web a gran escala ... su tamaño está superando la cadena de herramientas.

Solo estoy buscando que el equipo de Angular establezca expectativas aquí, eso es todo:

• ¿El equipo de Angular considera que esto es un problema? (se ha etiquetado como "obligatorio" desde marzo)
• ¿Se está tomando alguna medida para solucionarlo? (se ha etiquetado como "investigación" desde marzo)
• ¿Es este un problema que se puede solucionar en el próximo mes? ¿6 meses? ¿año?
• Si no es un problema solucionable, ¿hay otras configuraciones de compilación / cadenas de herramientas que recomendarían?
• ¿Siguen investigando las respuestas a las preguntas anteriores?

Cualquier respuesta a esas preguntas está bien ... pero es importante que esas respuestas (y su progreso) se comuniquen a la comunidad de manera iterativa. Mi equipo y muchos otros equipos necesitan tomar decisiones basadas en esas respuestas, y ahora mismo nos sentimos congelados.

Este es un proyecto de código abierto que todos obtenemos de forma gratuita. Ya ha añadido un valor tremendo incluso con este problema; por lo que algunas personas están siendo terriblemente críticas dado esto. Al mismo tiempo, la comunicación abierta es integral para el éxito de proyectos sólidos de código abierto: estamos buscando al equipo de Angular para ese liderazgo.

@filipesilva , @hansl?

¡Ese es un excelente resumen @dpxxdp !

Actualización reciente de nuestro proyecto a Angular 5 y Angular CLI 1.5.
Tenemos más de 100 componentes y más de 20 módulos. ¡La excepción build --prod está tardando una eternidad y finalmente arroja un montón de excepción de memoria, lo cual es muy frustrante!

Como mencioné aquí hace unos meses, tengo un proyecto muy grande con varios módulos también, +120 páginas, +500 componentes (las páginas están divididas en al menos 3 componentes como cuadrícula, formulario).

Para que ng build -prod funcionara, tuve que probar en una máquina con 32 Gb de RAM, nodeJS consumió 28 Gb para compilar el proyecto. Impresionante.

La solución fue poner 32 Gb como memoria virtual en la máquina (intercambio).
Además, del ya conocido "--max_old_space_size".

La etiqueta de este problema debe ser priority: 1 (urgent) lugar de priority: 2 (required)

@swftvsn Todavía no lo entiendo. Tal vez sea porque vengo de .NET, donde el compilador de c # atravesaría un proyecto con cantidades comparables de clases sin sudar.

@Tolitech Este es exactamente el punto principal. Si necesitamos máquinas con 32 GB de RAM para construir el proyecto, algunos agentes en la nube no podrán manejar esto / no son configurables para actualizar el hardware. Por lo tanto, necesitaríamos tomar decisiones arquitectónicas para comenzar a construir SPA segmentadas para mantener el tamaño de un proyecto bajo, atendiendo a las limitaciones del compilador.

@dpxxdp Si bien estoy de acuerdo en que es genial que sea gratuito y de código abierto (¡gracias también equipo!), No creo que sea una crítica informar un error importante / limitación funcional que requiere una actualización de hardware como solución alterna. No creo que nadie esté tratando de criticar el trabajo que se hizo, sino de aumentar la prioridad en este tema.

chicos 2 solución para el problema del montón

1. usar compilación personalizada con paquete web
   Actualmente, la compilación predeterminada usa varios pasos de optimización + minificación.
2. usar comando como
   ng build --app app -aot=true -e=prod -sm=false -ec=true --named-chunks=false -oh=all -pr=false
   esto generará paquetes sin minificación y el tamaño general del paquete del proveedor aumentará en mi caso en un 8%. El tiempo de construcción se redujo dos veces, pero el paso de minificación lleva mucho tiempo de 6 a 7 minutos en la máquina de CI (2 gb). Utilizo gulp para acciones posteriores a la compilación en mi caso, es uglify js y postcss.

Mi aplicación
~ 72 servicios (operación CRUD + alguna lógica general)
~ 10 tubos
~ 15 directiva
~ 170 componentes
~ 80 clase de modelo (datos de API)
~ 15 módulos

en cuanto a mí, quiero algunas banderas para establecer el recuento de pasos de optimización, agitación profunda del árbol (función, clase, variable)

Hola a todos,

Elegí la prioridad en este tema y estaré trabajando en ello. No lo considerábamos tan urgente antes porque la solución en ese momento era aumentar la memoria disponible para el nodo, que por defecto es de 1,7 GB. Por lo tanto, se esperaba que en algún momento los proyectos necesitaran más memoria que la predeterminada.

Sin embargo, con el lanzamiento de 1.5, los requisitos de memoria parecen haber aumentado drásticamente. Los proyectos que antes no tenían problemas de memoria ahora sí. 32 GB es definitivamente una cantidad ridícula de RAM y no debería ser necesario.

En este punto, no estoy seguro de qué causó el pico de memoria, pero tengo algunas hipótesis. Con CLI1.5 + Angular 5 usamos una nueva canalización que realiza una mejor verificación de tipos mediante el uso de un programa TS completo. Tal vez haya una caché defectuosa en algún lugar, o el programa TS está ocupando mucha memoria. Otra posibilidad es Uglify, que también tuvimos que actualizar. O podría ser algo en el propio compilador AOT. También configuramos el optimizador de compilación predeterminado como verdadero ahora y no está realmente optimizado ni para la velocidad ni para la memoria.

Si se encuentra con este problema y tiene tiempo, le agradecería que pudiera responder un par de preguntas:

• ¿En qué versión de CLI y Angular estás?
• ¿Esto solo sucede en ng build --prod ?
• ¿Sigue recibiendo el error de memoria con estos comandos de compilación:
  
  
  
  • ng build --prod --build-optimizer=false
  
  
  • ng build --aot
  
  
  • ng build --aot --build-optimizer
  
  
• Si tiene un proyecto que pueda ver, ¿puede vincularlo, por favor?

En respuesta al comentario anterior:
CLI 1.5.0, Angular 5.0.1

Proyecto:
Servicios: 9
Componentes: 43
Modelos: 28
Líneas de ts: 8200
Líneas de descaro: 5000

El error de pila ocurre con:
ng build --prod : sí
ng build --build-optimizer=false : no
ng build --aot : no
ng build --aot --build-optimizer : no

@filipesilva
Aproximadamente 20 módulos, 30 servicios, 80 componentes

• CLI 1.4.4, Angular 4.4.4
• Solo ocurre cuando se construye con --prod, --aot y --sourcemap (lo necesitamos en prod ...)
• Si configuramos la memoria en 8gb, en realidad podemos usar --prod, --aot, --sourcemap, Y --build-optimizer

Desafortunadamente, no se puede mostrar el repositorio

@filipesilva

¿En qué versión de CLI y Angular estás?
1.5.0 angular 5.0.1
¿Esto solo sucede en ng build --prod?
sí
¿Sigue recibiendo el error de memoria con estos comandos de compilación:
ng build --build-optimizer=false no
ng build --aot no
ng build --aot --build-optimizer no

@filipesilva
Windows 7 Pro de 64 bits
12 Gigas de ram
CLI 1.5.0, Angular 5.0.0

Detalles del proyecto:
~ 120 componentes
15 módulos

¿Sigue recibiendo el error de memoria con estos comandos de compilación:
ng build --prod: sí
ng build --build-optimizer = false: no
ng build --aot: no
ng build --aot --build-optimizer: sí

En Angular 4.3
con ~ 180 componentes
con ~ 30 servicios
con ~ 22 módulos

Con CLI 1.5
¿Esto solo sucede en ng build --prod? sí

ng build --build-optimizer = false menos de 2GB
ng build --aot --build-optimizer = false ~ 2.8GB
ng build: más de 3 GB

Con CLI 1.4.5
¿Esto solo sucede en ng build --prod? sí

ng build --build-optimizer = false menos de 2GB
ng build --aot --build-optimizer = false ~ 2.8GB
ng build --aot ~ 2.8 GB

Nuestro repositorio es privado lamentablemente

CLI 1.5.0, Angular 5.0.0

Módulos: ~ 50
Servicios: ~ 110
Componentes: ~ 290

ng build --prod : falla
ng build --prod --build-optimizer=false : falla
ng build --prod --build-optimizer=false --sourcemaps=false : falla
ng build --prod --aot=false : funciona
ng build : funciona
ng build --aot=true : funciona
ng build --aot=true --build-optimizer=true : falla

¿En qué versión de CLI y Angular estás?
@angular/[email protected] , <strong i="7">@angular</strong> 5.0

¿Esto solo sucede en ng build --prod?
sí

¿Sigue recibiendo el error de memoria con estos comandos de compilación:
ng build --build-optimizer=false : NO
ng build --aot : NO
ng build --aot --build-optimizer : NO

Bajo cli1.5 y angular5

Ng build —prod: SÍ
Ng serve —aot: primera vez NO pero después de editar el archivo SÍ arroja un error fuera de la memoria ... blockin al 0%

Ng serve: NO, todo está bien y es rápido (pero espere mucho para mostrar el resultado en el navegador debido al compilador JiT)

Cc @filipesilva

Las versiones que estoy usando
CLI - 1.2.0 y Angular 4.2.5
Módulos: ~ 130
Componentes: ~ 200
Servicios: ~ 70

obteniendo los problemas de compilación con las siguientes opciones.

ng build --prod: fail
ng build --aot = true: fail
ng build --aot = true --sourcemaps = false: funciona la mayoría de las veces y muy a menudo falla.
ng build --prod --aot = false: funciona

El sarcasmo de

Había experimentado el problema FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory con ng build --prod . He resuelto el problema usando
node --max_old_space_size = 8192 node_modules / @ angular / cli / bin / ng build --prod

También puede agregar en

package.json

como

"scripts": {
    "prod": "node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng  build --prod",
}
npm run prod

¿En qué versión de CLI y Angular estás?

Angular CLI: 1.5.0
Node: 8.5.0
OS: darwin x64
Angular: 5.0.0
... animations, common, compiler, core, forms, http
... platform-browser, platform-browser-dynamic, router

@angular/cdk: 5.0.0-rc0
@angular/cli: 1.5.0
@angular/compiler-cli: 5.0.1
@angular/flex-layout: 2.0.0-beta.10
@angular/language-service: 5.0.1
@angular/material: 5.0.0-rc0
@angular-devkit/build-optimizer: 0.0.32
@angular-devkit/core: 0.0.20
@angular-devkit/schematics: 0.0.35
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.0
@schematics/angular: 0.1.2
typescript: 2.4.2
webpack: 3.8.1

¿Esto solo sucede en ng build --prod? NO ESTOY SEGURO
¿Sigue recibiendo el error de memoria con estos comandos de compilación:

• ng build --build-optimizer = false OBRAS
• ng build --aot FALLA
• ng build --aot --build-optimizer FALLA

además:

• ng build --aot = true --sourcemaps = false OBRAS
• ng build --prod -sourcemaps = false FALLOS
• ng acumulación --prod FALLA
• ng build --prod --aot = flase --sourcemaps = false FALLAS

Si tiene un proyecto que pueda ver, ¿puede vincularlo, por favor?

• https://github.com/Alfresco/alfresco-ng2-components/tree/development

tenemos un canal de gitter si necesita ayuda para construir nuestro proyecto y eche un vistazo:

• https://gitter.im/Alfresco/alfresco-ng2-components

Mismo problema. Actualizado a A5. ng build --prod da como resultado un error de memoria insuficiente a continuación. El error no ocurre sin --prod. Aumentar --max_old_space_size no es realmente la respuesta, algo está fundamentalmente mal y ha impedido que nuestra actualización A5 vaya a ninguna parte.

¡Por favor, arregla!

<--- Últimos GC --->

243344 ms: Mark-sweep 1000,9 (1434,4) -> 1003,2 (1434,4) MB, 452,4 / 0,0 ms [error de asignación] [el barrido podría no tener éxito].
243760 ms: Mark-sweep 1003.2 (1434.4) -> 1003.2 (1434.4) MB, 416.3 / 0.0 ms [falla de asignación] [la eliminación puede no tener éxito].
244187 ms: Mark-sweep 1003.2 (1434.4) -> 1012.9 (1418.4) MB, 427.0 / 0.0 ms [último recurso gc].
244591 ms: Mark-sweep 1012.9 (1418.4) -> 1022.8 (1418.4) MB, 403.8 / 0.0 ms [último recurso gc].

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

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

Contexto de seguridad: 0x957966cfb39
1: DoJoin (también conocido como DoJoin) [native array.js: ~ 129] [pc = 0xbe4173aee59] (this = 0x95796604381, w = 0x1ca9328ff671, J = 0x957966ae4b9 2: Join (también conocido como Join) [native array.js: 180] [pc = 0xbe419f08ab2] (this = 0x95796604381, w = 0x1ca9328ff671

ERROR FATAL: CALL_AND_RETRY_LAST Error en la asignación: pila de JavaScript sin memoria
1: nodo :: Abort () [/ usr / local / bin / node]
2: node :: FatalException (v8 :: Isolate , v8 :: Local <: value i = "24">, v8 :: Local <: message i = "25">) [/ usr / local / bin / node]3: v8 :: internal :: V8 :: FatalProcessOutOfMemory (char const , bool) [/ usr / local / bin / node]
4: v8 :: internal :: Factory :: NewRawTwoByteString (int, v8 :: internal :: PretenureFlag) [/ usr / local / bin / node]
5: v8 :: internal :: Runtime_StringBuilderJoin (int, v8 :: internal :: Object *, v8 :: internal :: Isolate ) [/ usr / local / bin / node]
6: 0xbe4066092a7
Trampa de aborto: 6

¿En qué versión de CLI y Angular estás?

@angular/cli: 1.4.9
node: 6.11.0
os: win32 x64
@angular/animations: 4.4.6
@angular/cdk: 2.0.0-beta.12
@angular/common: 4.4.6
@angular/compiler: 4.4.6
@angular/core: 4.4.6
@angular/flex-layout: 2.0.0-beta.9
@angular/forms: 4.4.6
@angular/http: 4.4.6
@angular/material: 2.0.0-beta.12
@angular/platform-browser: 4.4.6
@angular/platform-browser-dynamic: 4.4.6
@angular/router: 4.4.6
@angular/cli: 1.4.9
@angular/compiler-cli: 4.4.6
typescript: 2.6.1

ng build --prod - Éxito
ng build --build-optimizer=false - Éxito
ng build --aot - Éxito
ng build --aot --build-optimizer - OOME

Una ejecución local de comprobación de cordura de ng serve --prod --aot me dio un error en un momento posterior

Date: 2017-11-12T22:52:55.879Z
Hash: 456f57f84be9de32704e
Time: 185523ms
chunk {0} polyfills.5dbd24b37bdff70c0320.bundle.js (polyfills) 66.1 kB {4} [initial] [rendered]
chunk {1} main.a2ba9af755957e20aa31.bundle.js (main) 1.98 MB {3} [initial] [rendered]
chunk {2} styles.2dfc00976daefa57d973.bundle.css (styles) 80.3 kB {4} [initial][rendered]
chunk {3} vendor.c5146d2ca93aff011cac.bundle.js (vendor) 1.51 MB [initial] [rendered]
chunk {4} inline.7e6f8c72074764ba2a48.bundle.js (inline) 1.45 kB [entry] [rendered]

webpack: Compiled successfully.

<--- Last few GCs --->

  277448 ms: Mark-sweep 1225.3 (1434.4) -> 1225.3 (1434.4) MB, 1086.6 / 0.1 ms [allocation failure] [scavenge might not succeed].
  278456 ms: Mark-sweep 1225.3 (1434.4) -> 1225.3 (1434.4) MB, 1008.4 / 0.1 ms [allocation failure] [scavenge might not succeed].
  279488 ms: Mark-sweep 1225.3 (1434.4) -> 1236.2 (1418.4) MB, 1030.8 / 0.1 ms [last resort gc].
  280607 ms: Mark-sweep 1236.2 (1418.4) -> 1247.1 (1418.4) MB, 1117.0 / 0.1 ms [last resort gc].

<--- JS stacktrace --->

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

Security context: 00000126BFCCFB49 <JS Object>
    1: DoJoin(aka DoJoin) [native array.js:~129] [pc=000003FAD779BBD7] (this=00000126BFC04381 <undefined>,w=0000033E0E885D01 <JS Array[334]>,x=334,N=00000126BFC043C1 <true>,J=00000126BFCAE4C9 <String[1]:  >,I=00000126BFCB46D9 <JS Function ConvertToString (SharedFunctionInfo 00000126BFC52DC9)>)
    2: Join(aka Join) [native array.js:180] [pc=000003FAD73F9FB2] (this=00000126BFC04381 <undefined>...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

En mi proyecto, todo funcionaba bien en el modo --prod --aot hasta hace un día cuando decidí migrar a HttpClient para prepararme para el conmutador Angular 5 / CLI 1.5. No hubo cambios de versión, no hubo cambios CLI involucrados.

Actualicé mis servicios y moví alguna lógica de error / autenticación a un par de interceptores. El paquete de desarrollo de mi proveedor pasó de 15 MB a 6 MB y quedé impresionado. Luego decidí verificar la cordura de mi prod aot build con ng serve --prod --aot y comencé a obtener el OOME.

Viendo el mismo problema después de actualizar a cli 1.5, Angular 1.5 y HttpClient

$ ng build --aot --prod
95% emisor
<--- Últimos GC --->

224719 ms: Mark-sweep 1304.7 (1434.7) -> 1304.7 (1434.7) MB, 485.6 / 0.0 ms [falla de asignación] [la eliminación puede no tener éxito].
225206 ms: Mark-sweep 1304.7 (1434.7) -> 1304.7 (1434.7) MB, 487.0 / 0.0 ms [falla de asignación] [la eliminación puede no tener éxito].
225685 ms: Mark-sweep 1304,7 (1434,7) -> 1304,7 (1418,7) MB, 479,3 / 0,0 ms [último recurso gc].
226180 ms: Mark-sweep 1304,7 (1418,7) -> 1304,7 (1418,7) MB, 494,5 / 0,0 ms [último recurso gc].

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

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

Contexto de seguridad: 0x3e4edad3fa99
1: DoJoin (también conocido como DoJoin) [native array.js: ~ 129] [pc = 0xd5adf91512e] (this = 0x3e4edad04241, w = 0x21eed50e5b41, J = 0x3e4edad4a369 2: Join (también conocido como Join) [native array.js: 180] [pc = 0xd5ac9783c52] (this = 0x3e4edad04241, w = 0x21eed50e5b41

ERROR FATAL: CALL_AND_RETRY_LAST Error en la asignación: pila de JavaScript sin memoria
1: nodo :: Abort () [/ usr / local / bin / node]
2: node :: FatalException (v8 :: Isolate , v8 :: Local <: value i = "25">, v8 :: Local <: message i = "26">) [/ usr / local / bin / node]3: v8 :: internal :: V8 :: FatalProcessOutOfMemory (char const , bool) [/ usr / local / bin / node]
4: v8 :: internal :: Factory :: NewRawTwoByteString (int, v8 :: internal :: PretenureFlag) [/ usr / local / bin / node]
5: v8 :: internal :: Runtime_StringBuilderJoin (int, v8 :: internal :: Object *, v8 :: internal :: Isolate ) [/ usr / local / bin / node]
6: 0xd5ac97060c7
7: 0xd5adf91512e
Trampa de aborto: 6
Jays-MacBook- Pro: ngx-dynamic-dashboard-framework jayhamilton $ ng build --aot --prod
95% emisor
<--- Últimos GC --->

224540 ms: Mark-sweep 1305,3 (1444,7) -> 1305,3 (1444,7) MB, 476,2 / 0,0 ms [error de asignación] [el barrido podría no tener éxito].
225007 ms: Mark-sweep 1305,3 (1444,7) -> 1305,3 (1444,7) MB, 466,7 / 0,0 ms [error de asignación] [el barrido podría no tener éxito].
225479 ms: Mark-sweep 1305,3 (1444,7) -> 1305,3 (1428,7) MB, 471,9 / 0,0 ms [último recurso gc].
225970 ms: Mark-sweep 1305,3 (1428,7) -> 1305,3 (1428,7) MB, 491,1 / 0,0 ms [último recurso gc].

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

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

Contexto de seguridad: 0x67c5bb3fa99
1: DoJoin (también conocido como DoJoin) [native array.js: ~ 129] [pc = 0x337898eca1ce] (this = 0x67c5bb04241, w = 0x3ba9f97f5a79, J = 0x67c5bb4a369 2: Join (también conocido como Join) [native array.js: 180] [pc = 0x33787d083c52] (this = 0x67c5bb04241, w = 0x3ba9f97f5a79

ERROR FATAL: CALL_AND_RETRY_LAST Error en la asignación: pila de JavaScript sin memoria
1: nodo :: Abort () [/ usr / local / bin / node]
2: node :: FatalException (v8 :: Isolate , v8 :: Local <: value i = "56">, v8 :: Local <: message i = "57">) [/ usr / local / bin / node]3: v8 :: internal :: V8 :: FatalProcessOutOfMemory (char const , bool) [/ usr / local / bin / node]
4: v8 :: internal :: Factory :: NewRawTwoByteString (int, v8 :: internal :: PretenureFlag) [/ usr / local / bin / node]
5: v8 :: internal :: Runtime_StringBuilderJoin (int, v8 :: internal :: Object *, v8 :: internal :: Isolate ) [/ usr / local / bin / node]
6: 0x33787d0060c7
7: 0x337898eca1ce
Trampa de aborto: 6

PAQUETE.JSON
"dependencias": {
"@ angular / animaciones": "^ 5.0.1",
"@ angular / cdk": "2.0.0-beta.12",
"@ angular / común": "^ 5.0.1",
"@ angular / compiler": "^ 5.0.1",
"@ angular / core": "^ 5.0.1",
"@ angular / forms": "^ 5.0.1",
"@ angular / http": "^ 5.0.1",
"@ angular / material": "2.0.0-beta.12",
"@ angular / platform-browser": "^ 5.0.1",
"@ angular / platform-browser-dynamic": "^ 5.0.1",
"@ angular / enrutador": "^ 5.0.1",
"@ swimlane / ngx-charts": "6.1.0",
"core-js": "^ 2.4.1",
"d3": "^ 4.4.0",
"jquery": "2.2.0",
"ng2-cookies": "1.0.3",
"ng2-dnd": "^ 2.1.1",
"reflect-metadata": "0.1.8",
"rxjs": "^ 5.5.2",
"ui-semántica": "2.2.2",
"socket.io-client": "^ 1.7.2",
"sockjs-client": "^ 1.1.4",
"stompjs": "^ 2.3.3",
"zone.js": "^ 0.8.4"
},
"devDependencies": {
"@ angular / cli": "1.5.0",
"@ angular / compiler-cli": "^ 5.0.1",
"@ tipos / jazmín": "2.5.38",
"@ tipos / nodo": "~ 6.0.60",
"codelyzer": "~ 2.0.0",
"núcleo de jazmín": "~ 2.5.2",
"jasmine-spec-reporter": "~ 3.2.0",
"karma": "~ 1.4.1",
"karma-chrome-launcher": "~ 2.0.0",
"karma-cli": "~ 1.0.1",
"karma -cover-istanbul-reporter": "^ 0.2.0",
"karma-jazmín": "~ 1.1.0",
"karma-jasmine-html-reporter": "^ 0.2.2",
"transportador": "~ 5.1.0",
"ts-node": "~ 2.0.0",
"tslint": "~ 4.5.0",
"mecanografiado": "~ 2.6.1"
}

EDITAR trabajando con la corrección --max_old_space_size=8192 anterior **

También obteniendo exactamente lo mismo. Tiempo de construcción de Angular 4, ¿2 minutos tal vez? El nuevo tiempo de construcción angular 5 es de 25 para fallar con:

ng build --prod --output-path = dist / cliente

92% de optimización de fragmentos de activos
<--- Últimos GC --->

1327460 ms: Mark-sweep 1306,9 (1405,9) -> 1306,9 (1414,9) MB, 1826,0 / 0,0 ms [error de asignación] [GC en el espacio antiguo solicitado].
1329363 ms: Mark-sweep 1306,9 (1414,9) -> 1306,9 (1414,9) MB, 1903,1 / 0,0 ms [error de asignación] [GC en el espacio antiguo solicitado].
1331374 ms: Mark-sweep 1306,9 (1414,9) -> 1313,4 (1405,9) MB, 2010,3 / 0,0 ms [último recurso gc].
1333333 ms: Mark-sweep 1313.4 (1405.9) -> 1319.9 (1405.9) MB, 1958.0 / 0.0 ms [último recurso gc].

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

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

Contexto de seguridad: 000002E7514CF791
2: con_padres [000002E751404381: ~ 5813] [pc = 000002F02F5400F6] (esto = 000001E1DBFE4699, cont = 000000E96E71C3A9 3: / * anónimo / (también conocido como / anónimo * /) [000002E751404381: 6817] [pc = 000002F02FE08F44] (esto = 000002E751404381, uno mismo = 00000314C2BB6571

ERROR FATAL: CALL_AND_RETRY_LAST Error en la asignación: pila de JavaScript sin memoria

¿Algún avance en esto? Este problema se planteó en marzo y ahora se manifiesta en las compilaciones de prod de Angular 5 (y 4). Parece de alguna manera estar relacionado con HttpClient.

¿Puede investigar como una prioridad, ya que no podemos pasar a producción utilizando Angular 5, que actualmente no es adecuado para su propósito?

@JonathanYates https://github.com/angular/angular-cli/issues/5618#issuecomment -343244854

Sí, lo sé, eso fue hace 5 días. Estoy solicitando una actualización.

Mismos problemas, debería crear la aplicación sin problemas con ng build --prod

@filipesilva : Estoy pidiendo una fecha de actualización.

@andremarcondesteixeira todos haremos lo que nos plazca. Este no es el lugar para tratar de convencer a nadie de que use otro marco.

@JonathanYates @MichalEmbiq @andremarcondesteixeira - ¿ @filipesilva en el # 5618 (comentario) ? Eso parece haber funcionado para la mayoría de la gente y también funcionó para mí. Parece una solución alternativa suficiente hasta que se resuelva el problema real.

@jmcclanahan @filipesilva

ng servir: ÉXITO
ng build: ÉXITO

ng build --prod: FAIL
ng build --prod --build-optimizer = false: FAIL
ng build --aot: FAIL
ng build --aot --build-optimizer: FAIL

salida según https://github.com/angular/angular-cli/issues/5618#issuecomment -343765822

También se necesitan varios 'minutos' colgados al 92% antes de producir un error.

¿Cómo sugieres que produzca una construcción de producción?

Hola @filipesilva

• ¿En qué versión de CLI y Angular estás?
  1,5

• ¿Esto solo sucede en ng build --prod?
  No, con --aot y --build-optimizer también falla (ver más abajo)

• ¿Sigue recibiendo el error de memoria con estos comandos de compilación:
  Para los comandos que fallan, puede ser intermitente, es decir. fallar 4/5 veces, pero pasar el quinto
  ng build --build-optimizer = false: Pasa
  ng build --aot: Pasa
  ng build --aot --build-optimizer: falla

Puedo hacer que estos pasen el 100% del tiempo aumentando la cantidad de memoria disponible (es decir: node --stack_size = 4048 node_modules / .bin / ng build --prod | O por --build-optimizer = false)

He creado un repositorio simple del problema aquí: https://github.com/seanlandsman/build-optimiser-issue

Pasos para reproducir:
npm install
npm run prod (nota: esto falla la mayor parte del tiempo, pero muy ocasionalmente pasará)

Gracias

No creo que aumentar el nodo --stack_size sea una buena idea. Todo lo que hará es enmascarar el problema real aquí. La construcción no debería devorar tanta memoria. Hay un problema fundamental que debe solucionarse.

Piense en CI, algunos entornos no tienen tanta memoria. ¿Cómo esta "función" pasa las pruebas? ¿Por qué el problema está cerrado?

1) El problema no está "cerrado". Es a la vez abierto y marcado como urgente.
2) Nadie sugiere que aumentar el tamaño de la pila sea una solución permanente
3) los desarrolladores de angular-cli han intervenido para indicar que se están tomando el problema en serio y solicitaron comentarios sobre qué compilaciones tenían problemas.

Si la gente quiere quejarse de los requisitos de memoria, puede hacerlo. Si la gente quiere decir que no es razonable que exista este error, pueden hacerlo. Si la gente quiere animar a la gente a que deje de utilizar Angular, puede hacerlo. Los desarrolladores ya están analizando esto, ninguna cantidad de vitriolo lo hará más rápido. Mientras tanto, agregue un volumen de intercambio, aumente el tamaño de la pila y suscríbase al problema para recibir actualizaciones, que desafortunadamente probablemente serán principalmente quejas por un tiempo.

No estoy seguro de si esta es solo mi experiencia o no, pero en los casos en que tuve errores de plantilla (usé una variable no pública en la plantilla, usé el tipo incorrecto para un @Input() , etc.), vería la memoria el uso sube muy alto y luego bloquea la construcción. Mi sugerencia es asegurarse de que no haya errores de plantilla. Esto se puede hacer invocando ngc directamente en el proyecto. No estoy seguro de si eso ayudará, solo comparto mi experiencia.

Oigan todos,

He estado ejecutando un montón de perfiles de memoria en proyectos para intentar averiguar cuál es la causa. Estoy comparando proyectos que usan CLI 1.5.0 + Angular 5.0.0 + TypeScript 2.4.2 con CLI 1.4.9 + Angular 4.4.6 + Typecript 2.3.2. Un agradecimiento especial a todos los que brindaron repros, eso ayuda mucho.

@magemello Tengo problemas para construir tu proyecto. Parece que faltan un par de variables de estilo (como $alfresco-typography ). Supongo que tengo que construirlos antes de la aplicación. ¿Puedes decirme cuáles son los pasos que faltan? Esto es lo que hice:

git clone https://github.com/Alfresco/alfresco-ng2-components
cd alfresco-ng2-components
cd demo-shell-ng2
git checkout development
npm install
npm run ng -- build --prod --build-optimizer # errors on Undefined variable: "$alfresco-typography".

@seanlandsman No pude reproducir con el repositorio que vinculó. Obtuve los mismos resultados con 1.4.9 que con 1.5.0. Las compilaciones parecían terminar aproximadamente en la misma cantidad de tiempo y consumían un máximo de 500 MB de memoria. Los tamaños de los paquetes también eran los mismos (más sobre eso en un segundo). ¿Puedes pensar en algo que pueda estar perdiendo? Estoy en Windows 10, nodo 8.9.1.

@teabagp usando su reproducción (https://github.com/angular/angular-cli/issues/8457#issuecomment-344325608) Vi un aumento en el tamaño del paquete (500kB a 4MB) en 1.5.0 y un aumento en el uso de memoria ( de 580 a 1080 MB). Esta es la única reproducción de la comunidad que realmente tengo en este momento, si alguien más tiene un proyecto que pueda ver, hágamelo saber.

La última reproducción es especialmente relevante porque muestra este problema incluso en un proyecto pequeño. Aquellos de ustedes que tuvieron problemas de memoria que desaparecieron después de aumentar el límite de memoria , ¿pueden decirme si sus paquetes también

Basado en la reproducción de

• esto parece estar relacionado con la biblioteca utilizada ( devextreme y devextreme-angular ),
• el uso de memoria parece normal hasta la fase de "optimización de recursos del 92%", luego aumenta drásticamente,
• desactivar el optimizador de compilación no cambia esto,
• cambiar al viejo uglify no cambia esto,
• No creo que esté directamente relacionado con el nuevo compilador de TS, ya que se ejecuta en la fase 10% building modules y el uso de memoria parece normal en ese momento.

Por el momento, no creo que el aumento de 1,5 en el uso de memoria esté directamente relacionado con Build Optimizer o Sourcemaps. Ambos aumentan el uso de la memoria en virtud de hacer más cosas. Por tanto, los proyectos más grandes deberían utilizar más memoria. Aún deberíamos mantener esto bajo control, pero para el problema específico de 1.5 no parece ser la causa principal.

@filipesilva

Aquellos de ustedes que tuvieron problemas de memoria que desaparecieron después de aumentar el límite de memoria, ¿pueden decirme si sus paquetes también aumentaron significativamente?

Sí, el paquete principal aumentó aproximadamente 4 MB. Lamentablemente, el proyecto no es de código abierto, pero es bastante complejo de todos modos, creo que el otro proyecto es un mejor ejemplo para tratar de diagnosticar.

Hola @filipesilva ,

perdón por no brindarle más información sobre cómo ejecutarlo correctamente:

cd scripts
./update-version.sh -v 2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432
cd ..
cd demo-shell-ng2
npm install
npm run ng -- build --prod --build-optimizer 


> [email protected] ng /Users/mromano/dev/alfresco-ng2-components/demo-shell-ng2
> ng "build" "--prod" "--build-optimizer"

 92% chunk asset optimization

@magemello Estoy en Windows y, desafortunadamente, ese script no parece ser muy compatible con Windows incluso con gitbash ...

kamik<strong i="7">@T460p</strong> MINGW64 /d/sandbox/memory/alfresco-1.4/scripts (development)
$ ./update-version.sh -v 2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432
====== New version 2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432 =====
====== UPDATE COMPONENTS ======
====== clean lock file ng2-alfresco-core ======
rm: cannot remove '/d/sandbox/memory/alfresco-1.4/scripts/../ng2-components/ng2-alfresco-core/package-lock.json': No such file or directory
====== UPDATE COMPONENT ng2-alfresco-core ======
====== UPDATE PACKAGE VERSION of  to 2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432 version in all the package.json ======
sed: can't read s/"version": "[0-9]\.[0-9]\.[0-9]"/"version": "2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432"/g: No such file or directory
====== UPDATE DEPENDENCY VERSION of ng2-alfresco-core to ~2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432 in ng2-alfresco-core======
sed: can't read s/"ng2-alfresco-core": "[0-9]\.[0-9]\.[0-9]"/"ng2-alfresco-core": "2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432"/g: No such file or directory
sed: can't read s/"ng2-alfresco-core": "~[0-9]\.[0-9]\.[0-9]"/"ng2-alfresco-core": "~2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432"/g: No such file or directory
====== UPDATE DEPENDENCY VERSION of ng2-alfresco-datatable to ~2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432 in ng2-alfresco-core======
sed: can't read s/"ng2-alfresco-datatable": "[0-9]\.[0-9]\.[0-9]"/"ng2-alfresco-datatable": "2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432"/g: No such file or directory
sed: can't read s/"ng2-alfresco-datatable": "~[0-9]\.[0-9]\.[0-9]"/"ng2-alfresco-datatable": "~2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432"/g: No such file or directory
====== UPDATE DEPENDENCY VERSION of ng2-alfresco-upload to ~2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432 in ng2-alfresco-core======
sed: can't read s/"ng2-alfresco-upload": "[0-9]\.[0-9]\.[0-9]"/"ng2-alfresco-upload": "2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432"/g: No such file or directory
sed: can't read s/"ng2-alfresco-upload": "~[0-9]\.[0-9]\.[0-9]"/"ng2-alfresco-upload": "~2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432"/g: No such file or directory
====== UPDATE DEPENDENCY VERSION of ng2-activiti-diagrams to ~2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432 in ng2-alfresco-core======
sed: can't read s/"ng2-activiti-diagrams": "[0-9]\.[0-9]\.[0-9]"/"ng2-activiti-diagrams": "2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432"/g: No such file or directory

¿Hay algo que pueda hacer, aunque sea un truco, para evitar la necesidad? Idealmente sin eliminar los estilos globales, ya que también estoy investigando si el procesamiento de estilos está usando mucha memoria.

@hanvyj ¡ gracias por confirmar eso!

@filipesilva
Comenzamos a experimentar esto de manera bastante significativa en CLI 1.3 y empeoró con 1.4, por lo que bajamos a 1.2.6 y no hemos tenido ningún problema desde entonces. todavía estamos ejecutando ng 4.4.6 con cli 1.2.6 y parece estar bien con la configuración predeterminada.

No tengo mucho tiempo para profundizar en esto en este momento, así que lamento que esto no sea _super_ útil, pero solo quería hacerle saber dónde fallaron los números de versión.

Estamos encerrados en las siguientes versiones específicas (junto con el material 2.0.0-beta.12 ). si cambiamos SOLO cli a 1.3 o 1.4 (y presumiblemente 1.5) vemos el problema:

  "dependencies": {
    "@angular/animations": "4.4.6",
    "@angular/cdk": "2.0.0-beta.12",
    "@angular/common": "4.4.6",
    "@angular/compiler": "4.4.6",
    "@angular/core": "4.4.6",
    "@angular/forms": "4.4.6",
    "@angular/http": "4.4.6",
    "@angular/material": "2.0.0-beta.12",
    "@angular/platform-browser": "4.4.6",
    "@angular/platform-browser-dynamic": "4.4.6",
    "@angular/router": "4.4.6",
    "@ngrx/store": "4.0.3",
    "@ngrx/store-devtools": "4.0.0",
    "core-js": "2.4.1",
    "dexie": "1.5.1",
    "font-awesome": "4.7.0",
    "fs-extra": "2.0.0",
    "hammerjs": "2.0.8",
    "lodash": "4.5.0",
    "lscache": "1.0.5",
    "moment": "2.17.1",
    "net": "1.0.2",
    "ng-diff-match-patch": "2.0.6",
    "ng2-file-upload": "1.2.0",
    "ng2-select": "1.2.0",
    "ngx-infinite-scroll": "0.5.1",
    "normalizr": "2.1.0",
    "primeng": "4.1.3",
    "rxjs": "5.4.3",
    "stompjs": "2.3.3",
    "zone.js": "0.8.14"
  },
  "devDependencies": {
    "@angular/cli": "1.2.6",
    "@angular/compiler-cli": "4.4.6",
    "@compodoc/compodoc": "1.0.3",
    "@types/jasmine": "2.5.53",
    "@types/jasminewd2": "2.0.2",
    "@types/lodash": "4.14.65",
    "@types/lscache": "1.0.27",
    "@types/node": "6.0.60",
    "@types/normalizr": "2.0.16",
    "agentkeepalive": "^3.3.0",
    "codelyzer": "3.1.2",
    "jasmine-core": "2.6.2",
    "jasmine-spec-reporter": "4.1.0",
    "karma": "1.7.0",
    "karma-chrome-launcher": "2.1.1",
    "karma-cli": "1.0.1",
    "karma-coverage-istanbul-reporter": "1.2.1",
    "karma-firefox-launcher": "1.0.0",
    "karma-jasmine": "1.1.0",
    "karma-jasmine-html-reporter": "0.2.2",
    "karma-phantomjs-launcher": "1.0.2",
    "node-sass": "4.5.3",
    "phantomjs-prebuilt": "2.1.7",
    "protractor": "5.1.2",
    "suitcss-components-grid": "3.0.3",
    "suitcss-utils-size": "1.1.0",
    "ts-node": "3.2.0",
    "tslint": "5.3.2",
    "typescript": "2.4.2"
  }

Esperábamos actualizar pronto, así que me alegra ver que se centre un poco en el problema. ¡Muchas gracias!

Lo he ejecutado para ti:

git checkout dev-filipesilva 
cd demo-shell-ng2
npm install
npm run ng -- build --prod --build-optimizer 

@filipesilva

Acabo de probar una instalación limpia y todavía me falla. Estoy en OSX Sierra y estoy ejecutando el nodo v7.7.3

También noto que si ejecuto ng build --prod --build-optimizer = false se ejecutará con éxito repetidamente, mientras que ejecutar solo ng build --prod fallará la mayor parte del tiempo.

No estoy seguro de lo que puedo agregar aquí: ¿hay algún tipo de perfil que pueda ejecutar de mi lado y proporcionar el resultado?

Gracias

esto también me está afectando, usando angular 5 y cli 1.5, tuve que apagar el optimizador de compilación para que mis compilaciones pasaran sin un error de memoria insuficiente :(

@seanlandsman, ¿los tamaños de los paquetes siguen siendo los mismos?

@filipesilva

Con "node --stack_size = 4048 node_modules / .bin / ng build --prod" obtengo:

1.4K 14 de noviembre 20:43 inline.aa760cefdeaeea9e038f.bundle.js
835K 14 de noviembre 20:43 main.05e5301d42766024fc03.bundle.js
60K 14 de noviembre 20:43 polyfills.e6475d2787bb3154d59c.bundle.js
48K 14 de noviembre 20:43 styles.9b2fb464224d0a79781d.bundle.css

Con "./node_modules/.bin/ng build --prod --build-optimizer = false" obtengo:

1.4K 14 de noviembre 20:45 en línea.d7125ae6ed51e3e3af81.bundle.js
4.9K 14 de noviembre 20:45 main.47d0056e07ee5cb9c483.bundle.js
60K 14 de noviembre 20:45 polyfills.ad37cd45a71cb38eee76.bundle.js
48K 14 de noviembre 20:45 styles.9b2fb464224d0a79781d.bundle.css
951K 14 de noviembre 20:45 proveedor.799da157f41ee457e4bd.bundle.js

Curiosamente, puede ver que main.xx.js se hizo mucho más grande en la primera ejecución, pero el archivo del proveedor desapareció. ¿Podría esperarse esto?

Un poco más de información: acabo de probar esto en una Mac más antigua que ejecuta El Capitan (versión de nodo v7.7.3) que no he usado por un tiempo. Cuando ejecuto "node_modules / .bin / ng build --prod" funciona bien, repetidamente y mucho más rápido que en mi máquina actual. Espero que esto sea útil.

Gracias

@filipesilva nuestra compilación también se incrementó en 3MB o 4MB como el último ejemplo que dijiste, tomando mucho tiempo después del 92%, y también usamos las bibliotecas devextreme. Desafortunadamente, no puedo compartir el repositorio del proyecto, pero podría proporcionar nuestro package.json si fuera necesario.

@filipesilva intenta reducir el stack_size para reproducir el caso de @seanlandsman .
node --stack_size=512 node_modules/.bin/ng build --prod me da ese error en mi mac.

@filipesilva
¿En qué versión de CLI y Angular estás?
1.5 y 5.0.0 respectivamente
¿Esto solo sucede en ng build --prod?
Solo cuando se usa la bandera --aot.
¿Sigue recibiendo el error de memoria con estos comandos de compilación:
ng build --build-optimizer = false
no
ng build --aot
sí
ng build --aot --build-optimizer
sí
Si tiene un proyecto que pueda ver, ¿puede vincularlo, por favor?
Lo sentimos, pero nuestra aplicación es privada según nuestros requisitos corporativos.

@jmcclanahan @filipesilva

ng servir: ÉXITO
ng build: ÉXITO

ng build --prod: FAIL
ng build --prod --build-optimizer = false: FAIL
ng build --aot: FAIL
ng build --aot --build-optimizer: FAIL

salida según # 5618 (comentario)

También se necesitan varios 'minutos' colgados al 92% antes de producir un error.

¿Hay alguna solución para evitarlo?
No funciona con --max_old_space_size = 8192

Tengo el mismo problema. También reconocí que el tamaño de mi aplicación con ng serve aumentó drásticamente después de la actualización a angular 5. Con angular 4, el vendor.bundle.js creado por ng serve solía ser de 10 MB y con angular 5 ahora es de 30 MB.

ng serve -> funciona
ng build -> funciona
ng build --prod -> falla
ng build --prod --build-optimizer = false -> falla
ng build --aot -> falla
ng build --aot --build-optimizer = false -> falla

@filipesilva también podríamos ayudar a depurar la compilación del paquete web, ¿qué herramienta estás usando para depurarlo?
Estaba intentando así, pero no estoy seguro de que sea la mejor manera:

node-nightly --inspect-brk ./node_modules/@angular/cli/bin/ng build --prod

Si me das más instrucciones aquí o en Gitter, estaré más que feliz de ayudarte.

Oye, usando los repros que todos proporcionaron, creo que encontré el problema principal con 1.5. Tiene que ver con cómo la nueva canalización movió la eliminación del decorador a Build Optimizer.

Para aquellos interesados ​​en una explicación más detallada, esto es lo que sucede:

• Cuando compila con --aot , usamos transformaciones de TypeScript en Build Optimizer para eliminar los decoradores angulares (cosas como @Component y @NgModule ) tanto de su aplicación como de sus bibliotecas (no lo son necesario después de AOT).
• En 1.4 no usamos Build Optimizer para eso, usamos la eliminación manual solo en su aplicación.
• Debido a un error, los decoradores se eliminan pero sus importaciones permanecen en el código.
• Estas importaciones hacen que algunas bibliotecas de terceros se incluyan en su totalidad, en lugar de solo parcialmente.
• Puede comprobarlo usted mismo comparando ng build --aot al usar CLI1.4.9 + NG4 versus CLI1.5.0 + NG5.
• En el caso de devextreme lib, se incluyeron casi 9 megas de código adicional.
• El código adicional significa mucho más trabajo para Uglify, lo que hace que consuma mucha más memoria.

Puede haber más factores que contribuyan al uso excesivo de memoria, pero actualmente este es el enfoque que estoy siguiendo, ya que es el más prometedor. Espero tener un PR con una solución pronto.

@filipesilva ¡noticias increíbles! Gracias por compartir tu progreso, ¡muy apreciado!

Algunos de nosotros estamos experimentando esto en configuraciones que no son de la última versión y otros en configuraciones cli 1.2 y 1.3. ¿Cree que esto es solo una limitación natural y un comportamiento esperado debido al tamaño de los proyectos / dependencias? ¿Es la asignación predeterminada de <2 GB de RAM, naturalmente, demasiado pequeña para compilar proyectos más grandes?

@radoslavpetranov He estado pensando en eso ( @randyaa dijo lo mismo que tú) y tratando de averiguar qué es un buen enfoque.

Algo que me viene a la mente es dividirse en múltiples procesos. Pero luego de un mayor escrutinio, ese enfoque realmente no ayuda en el problema del uso de la memoria, ya que varios procesos usarán al menos la misma memoria total, probablemente más debido a ineficiencias y duplicaciones.

El problema 1.5 destacó la cantidad de Build Optimizer que realmente ayuda a mantener bajo el uso de la memoria al recortar las importaciones (y por lo tanto el tamaño del proyecto). Entonces, tal vez ese sea un enfoque mejor en general. Sin embargo, sí implica que un proyecto debe poder usar Build Optimizer, y aún puede haber problemas con él (la manipulación del código es complicada).

Otro enfoque podría ser echar un vistazo al uso de memoria Uglify en paquetes grandes. Tal vez haya espacio para ajustes de configuración o algo así. Pero es difícil de decir ya que esas herramientas realmente se basan en una comprensión semántica de los paquetes de código para funcionar, por lo que se espera que se use mucha memoria en paquetes más grandes.

Otra cosa en la que he estado pensando es en tener una configuración de memoria baja, donde disco / cpu / tiempo total se intercambia por una huella de memoria más pequeña. Esta es solo una idea de muy alto nivel que no he explorado en absoluto. Sería útil en entornos limitados como CI, mientras que para entornos de desarrollo realmente desea las compensaciones que le brindan una mejor reconstrucción / velocidades.

Para proyectos realmente grandes, simplemente no puede evitar el hecho de que hay más lenguajes de rendimiento que JS y que las herramientas de compilación que pueden usarlos de manera efectiva (como Bazel) ofrecerán una mejor experiencia.

@filipesilva - Gracias por investigar esto. Aquí hay otro punto de datos, fwiw:

What version of the CLI and Angular are you on?
1.5.0 y 5.0.0
Does this only happen on ng build --prod?
Parece estar construyendo bien sin la marca --prod

Do you still get the memory error with these build commands:

ng build --build-optimizer=false
no
ng build --aot
no
ng build --aot --build-optimizer
no

If you have a project that I can look at, can you link it please?
Lo sentimos, repositorio privado y proyecto

@filipesilva Gracias por la actualización y la explicación, sin embargo, experimentamos esto con nuestros proyectos que utilizan cli 1.4.7 y angular 4.4.5 (y versiones anteriores también). Actualmente, para construir nuestra versión de producción utilizamos lo siguiente:

ng build --environment=prod --aot --sourcemaps=false --base-href=\"/ui/\" --preserve-symlinks --output-hashing=all --extract-css=true

Luego pasamos la salida a Uglify para minimizar y alterar el JS y CSS. Este proceso funciona correctamente y no tenemos problemas de memoria, pero cuando construimos con ng build --prod es cuando nos encontramos con problemas de memoria.

Tampoco tenemos el devextreme lib. No puedo compartir nuestro código, pero estoy feliz de instalar otras versiones de la CLI y publicar resultados de compilación de diferentes comandos. Nuestra aplicación es de aproximadamente 450 componentes y 290 módulos.

Hola @filipesilva
No sé exactamente si este mi comentario podría ser útil, pero reportaré algunas pruebas que hice.

Tengo un proyecto angular-cli (1.4.1), angular (4.4.4), mecanografiado (2.3.4).
Este proyecto contiene aproximadamente 200 servicios y más de 700 componentes, distribuidos en al menos 15 módulos.

Al ejecutar ng build --prod noté algunas cosas.
En este proyecto específico, se producen de 0 a 1,9 GB de memoria hasta el primer 10% de la compilación.
(Estoy usando los archivos saas de bootstrap).

Desde el 11% hasta el 89% de compilación, mi memoria sube a menos de 3 GB.

Del 90% al 92% la memoria se utiliza en 4,6 GB.

Y finalmente al 95% el consumo sube al límite máximo permitido.
En mi caso ahora, hasta los 6 GB de RAM que tengo ligados.

Para compilarlo, tuve que configurar la memoria virtual (intercambio).
Solo tengo 8 GB de RAM.

Aumenté a 12 GB, 16 GB, hasta que finalmente pude compilar el proyecto configurando 32 GB de RAM.

El consumo de NodeJS alcanzó los 28 GB con estas mismas emisiones del 95%.

Desafortunadamente, este proyecto es privado y no podría estar disponible.

Pruebas solicitadas:

ng build --build-optimizer=false funciona! 1,5 GB máx.

ng build --aot error!

Para intentar ayudar, creé un proyecto muy simple.
En él, se crean 10 módulos.
En cada módulo, se crean 50 componentes.
En cada componente solo hay un HTML con la salida "¡funciona!".

No hay CSS, no hay ningún componente npm de terceros.
Un proyecto simple como este consume 1.6 GB de RAM para la compilación AOT.

Creo que el consumo es un poco elevado porque no contiene absolutamente nada en el proyecto.
Si desea descargar el repositorio para probarlo, está comprimido en el enlace a continuación.
http://www.codegenerator.com.br/downloads/ng-heap-memory.zip

Gracias de antemano por tu ayuda.

He puesto un PR que debería abordar específicamente la regresión del uso de memoria cuando se usa 1.5 (https://github.com/angular/angular-cli/pull/8506). Una vez que se haya fusionado y lanzado, les haré ping a todos aquí para ver si ayudó en sus proyectos.

@Tolitech, su informe sobre cómo cambió el uso de la memoria con la etapa de compilación fue muy interesante y útil. Por debajo de la etapa del 92%, lo que sucede es la compilación de TypeScript y la carga de archivos en Webpack. Después de eso, es principalmente Uglify y Build-Optimizer.

Pero como está en 1.4.1 no debería tener Build Optimizer por defecto con --prod . Solo para verificarlo, ¿puede confirmar que no está usando --build-optimizer ?

En su informe menciona el uso de lo que considero un gran proyecto (200 servicios y 700 componentes). Definitivamente no es el más grande, pero sigue siendo grande. No me sorprende el uso de memoria de 3 GB para la compilación de TS y la carga de todos los archivos de la aplicación.

Pero cuando comienza a ponerse realmente malo es después de eso, cuando terminas necesitando al menos 28 GB en la fase del 92%. Esto me dice que el cuello de botella es Uglify, o tal vez alguna otra parte de nuestro proceso de compilación que no estoy viendo en este momento. Pero definitivamente vale la pena investigar, lo que haré.

Al ejecutar el pequeño proyecto ng-heap-memory tal como está, vi que se estaba utilizando un máximo de 1,4 GB de RAM. Usando el PR, esto se redujo a alrededor de 800 MB, por lo que parece estar ayudando allí. Estoy de acuerdo en que los 500 componentes están esencialmente vacíos, pero no me sorprende que el mero número de ellos provoque un alto consumo de memoria en una compilación. Por cierto, es un ejemplo valioso y gracias por hacerlo.

@mattem es un enfoque muy interesante, y doblemente interesante es que no sufres muchos problemas de memoria con él. ¿Puedo pedirle que me dé algunos números concretos para compararlos, por favor? Uso máximo de memoria en una compilación de producto CLI frente a CLI sin producto más Uglify manual. También me gustaría saber su versión y configuración de uglify, por favor.

Hola, @filipesilva
Sí, confirmo que estoy usando sin --build-optimizer.
Solo ng build --prod .

Y gracias por los comentarios.

@filipesilva utilicé la misma solución que la describí en mi comentario https://github.com/angular/angular-cli/issues/5618#issuecomment -343224021

mando
ng build --app homeapp -aot=true -e=prod -sm=false -ec=true --named-chunks=false -oh=all --build-optimizer=true -vc=true

mi uso de memoria:
0% -18% <= 828 mb
18% -89 <= 1140 mb
90-100 <1253 mb

diferencia entre --build-optimizer = true y false 90 mb

para uglify usado gulp-uglify ^ 3.0.0 configuración predeterminada 1058 mb
también utilicé gulp-postcss para uglify y autoprefixer en la última versión

@angular 5.0.1
@ angular / cli 1.5.0

@filipesilva El uso de ng build --prod dio el error OOM, sin embargo, al ejecutar la CLI con node --max_old_space_size=8192 se completó, con el siguiente uso de memoria (observado al mirar el Monitor de actividad en MacOS):

• ~ 14% 800 MB reales / 5,5 GB virtuales
• ~ 69% 1,5 GB reales / 6,4 GB virtuales
• ~ 90% 1,8 GB reales / 6,65 GB virtuales
• ~ 92% 2,3 GB reales / 7 GB virtuales
• ~ 94% 2,6 GB reales / 7,12 GB virtuales

Ejecutar con ng build --environment=prod --aot --sourcemaps=false --base-href="/ui/" --preserve-symlinks --output-hashing=all --extract-css=true (sin aumentar max_old_space ) alcanza un máximo de 1,49 gb reales / 6,23 gb virtuales. Esto se ejecuta con @angular/[email protected] y @angular/*@4.4.5

Usamos [email protected] , dándonos [email protected] , configurando compress y mangle en true .
La salida también se ejecuta a través de loose-envify , uglifycss y htmlmin
La tarea de trago alcanza un máximo de 868 MB reales / 5,57 GB virtuales.

Según el registro de cambios, la corrección mencionada anteriormente se incluye en 1.5.1+. Todavía falla por ng build --prod con 1.5.2 :(

95% emisor
<--- Últimos GC --->

[4980: 000001B75DBAB8D0] 268298 ms: Mark-sweep 1399.5 (1698.5) -> 1399.5 (1698.5) MB, 483.4 / 0.0 ms falla de asignación GC en el espacio anterior solicitado
[4980: 000001B75DBAB8D0] 268868 ms: Mark-sweep 1399.5 (1698.5) -> 1399.5 (1629.5) MB, 569.7 / 0.0 ms GC de último recurso en el espacio anterior solicitado
[4980: 000001B75DBAB8D0] 269387 ms: Mark-sweep 1399.5 (1629.5) -> 1399.5 (1600.0) MB, 518.8 / 0.0 ms GC de último recurso en el espacio anterior solicitado

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

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

Contexto de seguridad: 00000185B7C25EC1
1: DoJoin (también conocido como DoJoin) [native array.js: ~ 95] [pc = 0000002F55357679] (this = 00000075A3182311, p = 0000001FB1A5B831, A = 00000185B7C6EC69)
2: Join (también conocido como Join) [native array.js: ~ 120] [pc = 0000002F550C6489] (this = 00000075A3182311, p = 0000001FB1A5B831

ERROR FATAL: CALL_AND_RETRY_LAST Error en la asignación: pila de JavaScript sin memoria

Todavía encuentro este problema con angular cli 1.5.2

`ng build --aot --prod
95% emisor
<--- Últimos GC --->

209426 ms: Mark-sweep 1512.7 (1406.8) -> 1512.5 (1406.8) MB, 453.1 / 0.0 ms [falla de asignación] [GC en el espacio anterior solicitado].
209905 ms: Mark-sweep 1512.5 (1406.8) -> 1513.6 (1403.8) MB, 479.5 / 0.0 ms [último recurso gc].
210359 ms: Mark-sweep 1513.6 (1403.8) -> 1514.7 (1403.8) MB, 453.6 / 0.0 ms [último recurso gc].

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

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

Contexto de seguridad: 0x4353ac3fa99
1: SparseJoinWithSeparatorJS (también conocido como SparseJoinWithSeparatorJS) [matriz nativa.js: ~ 75] [pc = 0x1e05abc97c4a] (esto = 0x4353ac04241, w = 0x1a58c504381 2: DoJoin (también conocido como DoJoin) [native array.js: ~ 129] [pc = 0x1e05abb3c1b6] (thi ...

ERROR FATAL: CALL_AND_RETRY_LAST Error en la asignación: pila de JavaScript sin memoria
1: nodo :: Abort () [/ usr / local / bin / node]
2: node :: FatalException (v8 :: Isolate , v8 :: Local <: value i = "21">, v8 :: Local <: message i = "22">) [/ usr / local / bin / node]3: v8 :: internal :: V8 :: FatalProcessOutOfMemory (char const , bool) [/ usr / local / bin / node]
4: v8 :: internal :: Factory :: NewRawTwoByteString (int, v8 :: internal :: PretenureFlag) [/ usr / local / bin / node]
5: v8 :: internal :: Runtime_SparseJoinWithSeparator (int, v8 :: internal :: Object *, v8 :: internal :: Isolate ) [/ usr / local / bin / node]
6: 0x1e0596e060c7
Trampa de aborto: 6
Jays-MacBook- Pro: ngx-dynamic-dashboard-framework jayhamilton $ ng --version

_                      _                 ____ _     ___

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

CLI angular: 1.5.2
Nodo: 6.11.1
SO: darwin x64
Angular: 5.0.1
... animaciones, común, compilador, compilador-cli, núcleo, formularios
... http, navegador de plataforma, navegador de plataforma dinámico, enrutador

@ angular / cdk: 2.0.0-beta.12
@ angular / cli: 1.5.2
@ angular / material: 2.0.0-beta.12
@ angular-devkit / build-optimizer: 0.0.33
@ angular-devkit / core: 0.0.20
@ angular-devkit / schematics: 0.0.36
@ ngtools / json-schema: 1.1.0
@ ngtools / paquete web: 1.8.2
@ esquemas / angular: 0.1.5
mecanografiado: 2.6.1
paquete web: 3.8.1
'

@jayhamilton +1 https://github.com/swimlane/ngx-datatable/issues/1104#issuecomment -342528502

Hola a todos, 1.5.2 incluye la corrección para la regresión de uso de memoria 1.5. Esto debería ayudar a los usuarios que tenían proyectos que no tenían problemas de memoria en 1.4 pero que empezaron a tenerlos en 1.5 .

Los proyectos que ya tenían problemas de memoria en 1.4 no deberían ver cambios . Todavía estoy investigando los requisitos de memoria balooning para la fase 92% bundle optimizing .

@ PeS82 @jayhamilton @finalxcode informó que todavía tiene problemas de memoria con 1.5.2 . ¿Fue esto en proyectos que no tenían problemas de memoria en 1.4.x ?

@filipesilva Con angular cli 1.4.x solía funcionar, luego cuando actualizo angular / cli a 1.5.2, tengo problemas de memoria, tengo que usar el comando node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod --aot para construir

@filipesilva con cli 1.5.2 mi proyecto falla al 95%. Con angular cli 1.4.x solía funcionar.

@filipesilva @JackArlington lo mismo para mí. Nuestro proyecto solía construir (prod) en 1.4.xy desde 1.5.0 ya no lo hace. 1.5.2 no mejoró la situación. Cuando aumento el límite de memoria, se compila, pero usa aproximadamente 5GB al emitir.

Por un lado, el gran consumo de memoria se produce en "95% de emisión".

@filipesilva @Shadowlauch Acabo de reconocer que la máquina que probé antes tenía el nodo 6.x actualizándola a 8.9.1 resolvió el problema y ng build --prod --aot funciona ahora.
Gracias por la ayuda.

Para ser claros, no tengo conocimiento de ningún problema de memoria relacionado específicamente con el Nodo 6. Yo mismo he estado probando con el Nodo 8.9.1 porque no pude obtener las líneas de tiempo de la memoria usando Chrome Devtools con el Nodo 6.

Tal vez eso sea parte de la ecuación aquí ... Espero que los nodos más nuevos sean más rápidos y más eficientes en memoria, pero tal vez haya más.

Por ejemplo, no pude reproducir el problema en el proyecto de @seanlandsman . @seanlandsman ¿qué versión de nodo estabas usando?

También tenía el nodo 6.xy después de actualizar a 8.9.1 funciona ahora. @JackArlington ¡ gracias por el

@filipesilva Estoy en el nodo 7.7.3

Editar: Acabo de actualizar el repositorio de prueba a 1.5.2 y lo intenté; me temo que todavía falla.

¿Intentó ejecutar con "node --stack_size = 512 node_modules / .bin / ng build --prod" para ver si esto ayuda a reproducir lo que estoy viendo?

gracias de nuevo

@filipesilva
Ya no recibo el error heap out of memory con cli 1.5.2 . Mi versión de nodo es 7.5.0 .
Sin embargo, la compilación todavía tarda alrededor de 8 - 10 minutes en completarse.

@filipesilva He actualizado la versión y sigo teniendo el mismo problema :(

ng build --prod --aot

92% chunk asset optimization                                                             
<--- Last few GCs --->

[70119:0x103000800]   221253 ms: Mark-sweep 1412.4 (1539.6) -> 1412.4 (1527.1) MB, 2772.9 / 0.0 ms  (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 2773 ms) last resort 
[70119:0x103000800]   223828 ms: Mark-sweep 1412.4 (1527.1) -> 1412.4 (1527.1) MB, 2574.0 / 0.0 ms  last resort 


<--- JS stacktrace --->

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

Security context: 0x1174077a8799 <JSObject>
    2: add_parameter [0x35ed60282311 <undefined>:2953] [bytecode=0x2a011d5e84c1 offset=69](this=0x1dee67b6c479 <Object map = 0x13abb57fc8b1>,token=0x3e75c751c6b9 <AST_Token map = 0x2edf31c836a1>)
    4: binding_element(aka binding_element) [0x35ed60282311 <undefined>:3236] [bytecode=0x2a011d5e6669 offset=2234](this=0x35ed60282311 <undefined>,used_parameters=0x1dee67b6c479 <Object map = 0x13abb57...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

Aquí están las versiones que estoy usando:

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

Angular CLI: 1.5.2
Node: 8.5.0
OS: darwin x64
Angular: 5.0.2
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

@angular/cdk: 5.0.0-rc0
@angular/cli: 1.5.2
@angular/flex-layout: 2.0.0-beta.10
@angular/material: 5.0.0-rc0
@angular-devkit/build-optimizer: 0.0.33
@angular-devkit/core: 0.0.20
@angular-devkit/schematics: 0.0.36
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.2
@schematics/angular: 0.1.5
typescript: 2.4.2
webpack: 3.8.1

Si me da suficientes instrucciones sobre cómo depurar la compilación del paquete web, puedo ayudar a encontrar la fuente del problema ...

Puede confirmar que nos ha solucionado el problema. Usando 1.5.2 y Node 9.2.0 - ya no es necesario aumentar la memoria de Node.

Con la nueva versión 1.5.2, mi problema de memoria y el tamaño del paquete no se han solucionado, todavía lleva algo de tiempo atascado en el 92%, pero al final funciona.

@seanlandsman Probé sus repros nuevamente con --stack_size=512 y --stack-size=8048 y solo vi un consumo de memoria en el rango de 400-500MB. El valor predeterminado parece ser --stack_size=984 cierto.

Aunque vi algo más:

kamik<strong i="11">@T460p</strong> MINGW64 /d/sandbox/memory/aggrid-1.5 (master)
$ npm run prod

> [email protected] prod D:\sandbox\memory\aggrid-1.5
> node --stack_size=512 ./node_modules/@angular/cli/bin/ng build --prod

Date: 2017-11-17T10:46:12.052Z
Hash: db122ac832a501fd0cf8
Time: 31443ms
chunk {0} main.67d8219d9d4c87c59477.bundle.js (main) 830 kB [initial] [rendered]
chunk {1} polyfills.e6475d2787bb3154d59c.bundle.js (polyfills) 61.1 kB [initial] [rendered]
chunk {2} styles.9b2fb464224d0a79781d.bundle.css (styles) 49 kB [initial] [rendered]
chunk {3} inline.d67e755da47b31497a24.bundle.js (inline) 1.45 kB [entry] [rendered]

ERROR in ./node_modules/ag-grid/dist/lib/gridOptionsWrapper.js
Module build failed: RangeError: Maximum call stack size exceeded
    at getJSDocsWorker (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:8167:33)
    at getJSDocs (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:8163:13)
    at getJSDocTags (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:8148:27)
    at getJSDocParameterTags (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:8213:20)
    at Object.isRestParameter (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:8295:28)
    at symbolToParameterDeclaration (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:29262:41)
    at D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:29215:89
    at Array.map (<anonymous>)
    at signatureToSignatureDeclarationHelper (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:29215:55)
    at createTypeNodeFromObjectType (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:29024:49)
    at createAnonymousTypeNode (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:28988:42)
    at typeToTypeNodeHelper (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:28938:28)
    at createTypeNodesFromResolvedType (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:29177:67)
    at createTypeNodeFromObjectType (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:29035:35)
    at createAnonymousTypeNode (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:28988:42)
    at typeToTypeNodeHelper (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:28938:28)
 @ ./node_modules/ag-grid/dist/lib/columnController/columnUtils.js 11:27-59
 @ ./node_modules/ag-grid/main.js
 @ ./node_modules/ag-grid-angular/dist/ng2FrameworkFactory.js
 @ ./src/app/app.component.ngfactory.js
 @ ./src/app/app.module.ngfactory.js
 @ ./src/main.ts
 @ multi ./src/main.ts

Esto parece coherente con lo que realmente hace --stack-size (https://github.com/nodejs/node/issues/6360). No aumenta la memoria total disponible, sino el tamaño de cada región de pila que usa el nodo. Es que aumentarlo puede resolver problemas con mucha recursividad (pero ese código debería intentar no tener eso).

Los síntomas parecen ser diferentes en OSX (caída de la memoria) y Windows (se excedió el tamaño máximo de la pila de llamadas). No sé por qué es eso.

Creo que el problema que está experimentando está relacionado únicamente con el optimizador de compilación, como ha dicho, y es el que se rastrea en https://github.com/angular/devkit/issues/240. Sigue siendo relevante para este hilo, pero el problema específico es ese.

@changLiuUNSW fueron sus tiempos de compilación

@magemello Te enviaré un ping en el gitter que proporcionaste y veré qué podemos hacer en tu proyecto.

@filipesilva
No tengo la oportunidad de probar 1.4.x porque usamos CLI 1.3.0 en nuestro proyecto antes
Angular CLI 1.3.0 con Angular 4.2.4

ng build --prod
[14:08:02][Step 4/15] Time: 236558ms
[14:08:02][Step 4/15] chunk {0} polyfills.6bb91be4d06bd2c9e250.bundle.js (polyfills) 217 kB {4} [initial] [rendered]
[14:08:02][Step 4/15] chunk {1} main.71c6b1116dc39af75599.bundle.js (main) 1.59 MB {3} [initial] [rendered]
[14:08:02][Step 4/15] chunk {2} styles.21cad12ac9e3527f0f7d.bundle.css (styles) 166 kB {4} [initial] [rendered]
[14:08:02][Step 4/15] chunk {3} vendor.dfcfc494ca724bf884bf.bundle.js (vendor) 653 kB [initial] [rendered]
[14:08:02][Step 4/15] chunk {4} inline.f1134fc323101279dbaf.bundle.js (inline) 1.46 kB [entry] [rendered]

Angular CLI 1.5.2 con Angular 5.0.1

ng build --prod
[22:20:39][Step 4/15] Time: 530465ms
[22:20:39][Step 4/15] chunk {0} polyfills.953b2ea9f096cadfdccc.bundle.js (polyfills) 147 kB [initial] [rendered]
[22:20:39][Step 4/15] chunk {1} main.e2cfa60d1ec303d72a6a.bundle.js (main) 1.77 MB [initial] [rendered]
[22:20:39][Step 4/15] chunk {2} styles.b49f8f5ee25381105567.bundle.css (styles) 108 kB [initial] [rendered]
[22:20:39][Step 4/15] chunk {3} inline.2ae12ef65c8a9f6162ba.bundle.js (inline) 1.49 kB [entry] [rendered]

Entiendo que en 1.5, --build-optimize está habilitado de forma predeterminada para la compilación de producción, pero la diferencia de 5 minutos entre 1.5 y 1.3 no es buena.

@changLiuUNSW Estoy de acuerdo en que 5 minutos de diferencia es mucho tiempo. ¿Puedes probar --build-optimizer=false por ahora, por favor?

@filipesilva
Angular CLI 1.5.2 con Angular 5.0.1

ng build --prod --build-optimizer=false
Time: 163265ms
chunk {0} polyfills.cdff46cd9b1a8d656218.bundle.js (polyfills) 147 kB [initial] [rendered]
chunk {1} main.d1916123bd0e4aa2858f.bundle.js (main) 1.34 MB [initial] [rendered]
chunk {2} styles.d1f7c9f576103c62cb95.bundle.css (styles) 108 kB [initial] [rendered]
chunk {3} vendor.1fbdf23b6f274bb4005e.bundle.js (vendor) 639 kB [initial] [rendered]
chunk {4} inline.58b71d550a47f85197a5.bundle.js (inline) 1.5 kB [entry] [rendered]

6 minutos de diferencia con build-optimizer=true

Gracias @filipesilva por tu ayuda, hice lo siguiente:

• Establezca las dependencias angulares en 5.0.2
• Establezca Angular CLI en 1.5.2
• Eliminar node_modules y package-lock.json
• npm install

y ahora el resultado es el siguiente:

• npm run ng - la construcción funciona
• ng build --aot falla
• node --max_old_space_size = 30000 node_modules / .bin / ng build --aot funciona
• ng build --prod --build-optimizer = false falla
• node --max_old_space_size = 30000 node_modules / .bin / ng build --prod --build-optimizer = false funciona
• node --max_old_space_size = 30000 node_modules / .bin / ng build --prod falla

Entonces, en general, plantee max_old_space_size y solucione mi problema a excepción de "ng build --prod", en este caso, mi problema parece estar relacionado con esto: https://github.com/angular/angular/issues/20115.
En otras palabras, el problema parece ser la presencia de archivos ts en mis bibliotecas y no me enojo :), la solución para este punto parece ser poner el archivo ts en el .npmignore y excluirlo de los paquetes. (no lo he probado todavía)

Solo estoy informando el hallazgo, esperando que ayude a otros ... todo el mérito es para @filipesilva.

@changLiuUNSW @Tolitech, ¿puedo pedirle que haga una depuración más avanzada si tiene tiempo? No tengo acceso a sus proyectos pero parecen buenos ejemplos.

@changLiuUNSW Parece que su proyecto ya no tiene problemas de memoria, pero está tardando mucho en compilarse con Build Optimizer.

Creo que una de las transformaciones del optimizador de compilación está tardando mucho en su base de código, pero no puedo saber cuáles. Sin embargo, puedo decirte cómo deshabilitar cada uno individualmente.

Puede hacer esto en ./node_modules/@angular-devkit/build-optimizer/src/build-optimizer/build-optimizer.js . Desde la línea 63 a la línea 82, cada transformación se agrega individualmente a la matriz getTransforms . Puede comentar cada uno de los getTransforms.push( y esa transformación no se agregará.

Si puede hacer esto para cada uno y medirme cómo afecta el tiempo de construcción, podría averiguar cuál de las transformaciones está tardando demasiado.

@Tolitech su proyecto tiene problemas con el uso de memoria con 1.4.x, y ya ha confirmado que no usa el optimizador de compilación. Informó que el uso de memoria aumentó a 28 gigas durante una compilación de prod.

Me gustaría pedirte que hagas un par de cosas. Primero, ¿puede decirme el uso de memoria de solo ng build por favor?

Luego, me gustaría que intentara deshabilitar manualmente Uglify. Esto se puede hacer en ./node_modules/@angular/cli/models/webpack-configs/production.js , línea 111-117 (la llamada new webpack.optimize.UglifyJsPlugin({ ). Comente esas líneas e intente hacer una compilación de producción nuevamente (con límites de memoria aumentados). ¿Cuál fue la memoria máxima utilizada?

Entiendo que la depuración de estas cosas lleva tiempo y agradezco que se tome el tiempo para hacerlo. Estoy haciendo lo mismo en los proyectos a los que tengo acceso, pero cada proyecto es diferente, por lo que es muy difícil concentrarse en el problema exacto sin tener acceso al código. Pedirle que haga algunas pruebas es la mejor opción.

Ejecutar ng build --aot --prod produjo lo siguiente

Date: 2017-11-17T18:23:24.062Z
Hash: 7dff5d083d5a19785434
Time: 558874ms
chunk {0} polyfills.e8bddc586f67afdffd0d.bundle.js (polyfills) 65.6 kB [initial] [rendered]
chunk {1} main.ba0bc9f17d63868a89a3.bundle.js (main) 2.49 MB [initial] [rendered]
chunk {2} styles.cb450a88292b46f1511b.bundle.css (styles) 81 kB [initial] [rendered]
chunk {3} inline.0002f507274cf434cef2.bundle.js (inline) 1.45 kB [entry] [rendered]

tomó casi 10 minutos, pero la compilación se completó y no superó la marca de 1.3GB RAM ahora. Por lo que parece, el paquete también disminuyó de tamaño. Antes obtenía un paquete principal de 1,98 MB y un paquete de proveedor de 1,51 MB y ahora parece que solo tengo un paquete principal de 2,49 MB.

El paquete de desarrollo pasó de proveedor de 16 MB y principal de 4,61 MB a proveedor de 5,91 MB y principal de 1,87 MB y no superó la marca de 800 MB de RAM.

Esto se generó con la siguiente configuración

Angular CLI: 1.5.2
Node: 6.11.0
OS: win32 x64
Angular: 5.0.2
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

@angular/cdk: 5.0.0-rc0
@angular/cli: 1.5.2
@angular/flex-layout: 2.0.0-beta.10-4905443
@angular/material: 5.0.0-rc0
@angular-devkit/build-optimizer: 0.0.33
@angular-devkit/core: 0.0.20
@angular-devkit/schematics: 0.0.36
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.2
@schematics/angular: 0.1.5
typescript: 2.6.1
webpack: 3.8.1

Actualizaré mi nodo a la última versión 8. * y veré si esto cambia algo en términos de consumo de RAM.

@filipesilva Estaba mirando el package.json para Angular:
"engines": { "node": ">=6.9.5 <7.0.0", "npm": ">=3.10.7 <4.0.0", "yarn": ">=1.0.2 <2.0.0" },
Siempre he tomado la sección de motores en el sentido de que esos eran los motores compatibles. ¿Se admite oficialmente la ejecución del Nodo 8 o estoy leyendo todo mal?

Bueno, curiosamente, el nodo 8.9.1 completó el paquete casi dos veces más rápido (~ 5min 50 segundos) en comparación con el nodo 6.11 y usó alrededor de ~ 150-200MB menos de RAM durante las etapas finales (92% -95%) de la proceso.

Date: 2017-11-17T20:14:47.417Z
Hash: fd0232ebf712617a9dad
Time: 351019ms
chunk {0} polyfills.e8bddc586f67afdffd0d.bundle.js (polyfills) 65.6 kB [initial] [rendered]
chunk {1} main.ba0bc9f17d63868a89a3.bundle.js (main) 2.49 MB [initial] [rendered]
chunk {2} styles.cb450a88292b46f1511b.bundle.css (styles) 81 kB [initial] [rendered]
chunk {3} inline.0002f507274cf434cef2.bundle.js (inline) 1.45 kB [entry] [rendered]

Angular CLI: 1.5.2
Node: 8.9.1
OS: win32 x64
Angular: 5.0.2
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Entonces, aunque la reducción del tiempo de compilación fue muy buena, la versión del nodo no parece jugar un papel importante en el problema del consumo de RAM (al menos en mi máquina / proyecto).

EDITAR:

La ejecución de ng build --aot --prod --build-optimizer=false terminó 3 veces más rápido que ng build --aot --prod pero usó aproximadamente 150-200 MB más de RAM.

Date: 2017-11-17T20:29:38.921Z
Hash: 94cb3178b3be74bd0397
Time: 126625ms
chunk {0} polyfills.e8bddc586f67afdffd0d.bundle.js (polyfills) 65.9 kB [initial] [rendered]
chunk {1} styles.cb450a88292b46f1511b.bundle.css (styles) 81 kB [initial] [rendered]
chunk {2} main.55c058ed7857dda94b2e.bundle.js (main) 1.8 MB [initial] [rendered]
chunk {3} vendor.ba5bb536a884f0ae6767.bundle.js (vendor) 1.33 MB [initial] [rendered]
chunk {4} inline.39aa19fa644263353f85.bundle.js (inline) 1.45 kB [entry] [rendered]

Entonces, en general, el optimizador de compilación parece ayudar al consumo de RAM a expensas del tiempo.

Hola @filipesilva
Hice algunas pruebas más y me gustaría compartirlas con ustedes.

Para ser una prueba justa, reinicié mi computadora portátil en todo momento cuando cambié una línea en el archivo production.js y después de ejecutar ng build -prod.

En todas las pruebas, la memoria virtual agregada fue de 32 GB.
La computadora portátil tiene 8 GB de RAM física.

En el archivo ng.cmd, el comando configurado fue --max_old_space_size = 32768 en todos los casos.

Es importante recordar que en esta prueba, la memoria total asignada no es exactamente la memoria total requerida por Node.js, ya que sería el total utilizado por la computadora en todos sus procesos.

Sin embargo, no se estaba ejecutando ningún programa o proceso, y en todas las pruebas se reinició la computadora.

Vayamos a las pruebas:

Prueba 1
Configuración:

Memoria total asignada por la computadora: 36,5 GB

Tiempo de espera para completar: 26 min 24 seg.

Prueba 2
Configuración:

Memoria total asignada por la computadora: 34 GB

Tiempo de espera para completar: 20 min 52 seg.

Prueba 3
Configuración:

Memoria total asignada por la computadora: 7,9 GB

Tiempo de espera para completar: 10 min 03 seg.

Prueba 4
Configuración:

Memoria total asignada por la computadora: 8.8 GB

Tiempo de espera para completar: 13 min 59 seg.

Nodo v8.9.1
CLI angular 1.4.1

Según mis pruebas, tengo que concluir que en mi caso específico, es la línea de comando new webpack.optimize.ModuleConcatenationPlugin() que está aumentando drásticamente mi necesidad de memoria.

Con esta línea habilitada, mi consumo pasa de 8.8 GB a 36.5 GB como lo indica el administrador de tareas de Windows.

Si necesitas más pruebas, solo dame instrucciones.
Trabajo más con .NET, pero con instrucciones creo que puedo probar.

Gracias.

@Tolitech ¡ muchas gracias por intentarlo! Creo que estás en algo.

La confirmación que introdujo ModuleConcatenationPlugin se publicó en 1.3.0-rc.0 (https://github.com/angular/angular-cli/commit/fe85750cb7db699505faf1cc63e3d35018d47ed2).

Esto coincide con lo que dijeron @amikitevich @randyaa y @radoslavpetranov : sus problemas de memoria comenzaron con 1.3.0.

Usar ModuleConcatenationPlugin es importante por dos razones:

• hace que la carga de JavaScript en el navegador sea más rápida (https://medium.com/webpack/webpack-3-official-release-15fd2dd8f07b)
• permite paquetes más pequeños cuando se usa con Uglify y Build Optimizer

Pero también parece estar provocando un uso excesivo de la memoria en algunos casos.

Estoy un poco perdido por lo que puedo hacer al respecto ahora. ModuleConcatenationPlugin podría usar mucha memoria por diseño o podría ser simplemente un error, pero es difícil saberlo sin poder probarlo yo mismo.

Para los usuarios que comenzaron a tener problemas de memoria después de la actualización 1.3x : ¿pueden intentar hacer una compilación deshabilitando ModuleConcatenationPlugin manualmente (las mismas instrucciones que le di a @Tolitech en https://github.com/angular/angular-cli/ issues / 5618 # issuecomment-345268174) y dime si te ayuda. Si ayuda y su proyecto es público, ¿puede decirme dónde puedo verlo?

@Tolitech, ¿puedes decirme qué bibliotecas usas en tu aplicación? Tal vez pueda intentar incluirlos en un proyecto y reproducirlo así.

ejecutando ng build --aot --prod con new webpack.optimize.ModuleConcatenationPlugin() comentado

Date: 2017-11-19T08:34:58.624Z
Hash: 9c0b60b77822f45ea9fd
Time: 158811ms
chunk {0} main.dc03843e6c0ae1671bc2.bundle.js (main) 2.61 MB [initial] [rendered]
chunk {1} polyfills.a0160642e7aef2ebb253.bundle.js (polyfills) 65.6 kB [initial] [rendered]
chunk {2} styles.cb450a88292b46f1511b.bundle.css (styles) 81 kB [initial] [rendered]
chunk {3} inline.4c5cd4d92e0d15ed3e92.bundle.js (inline) 1.45 kB [entry] [rendered]

ejecutando ng build --aot --prod con new webpack.optimize.ModuleConcatenationPlugin() activado

Date: 2017-11-19T08:42:05.090Z
Hash: 8e9b1a1739224a7ca0ad
Time: 336440ms
chunk {0} polyfills.e8bddc586f67afdffd0d.bundle.js (polyfills) 65.6 kB [initial] [rendered]
chunk {1} main.4f0ad6b15ea65c6ef0b0.bundle.js (main) 2.49 MB [initial] [rendered]
chunk {2} styles.cb450a88292b46f1511b.bundle.css (styles) 81 kB [initial] [rendered]
chunk {3} inline.9ebe9dea2365b402bb45.bundle.js (inline) 1.45 kB [entry] [rendered]

No hay diferencia en el consumo de RAM en mi proyecto.

@filipesilva Mi proyecto es público y me enfrento exactamente al mismo problema después de actualizar Angular-CLI hace unos días. Puede probar 'ng build -prod' a través de https://github.com/alvachien/achihui

@alvachien Probé su proyecto con 1.5.2 y ng build --prod construyó correctamente con un uso máximo de memoria de 1.2GB. ¿Intentaste 1.5.2 ? Hay una solución que no está en 1.5.0.

@markmaynard lo que está viendo es el package.json para el repositorio angular/angular : https://github.com/angular/angular/blob/master/package.json#L10 -L13 . Esa reproducción es lo que llamamos monorepo, donde varios paquetes están bajo el mismo repositorio. Los requisitos del motor que ve allí son para el propio monorepro: los requisitos para construir los paquetes Angular. Pero no los requisitos para usar los paquetes Angular. Si revisa package.json por @angular/core (en su node_modules por ejemplo), no habrá requisitos de motor.

@mattem @WandererInVoids Intenté ejecutar algunos experimentos en un proyecto con muchas bibliotecas, para comparar el uso de la memoria con y sin un proceso Uglify separado:

• ng build --prod : memoria máxima de 1,1 GB, paquete principal de 4,1 MB
• ng build --prod con Uglify comentado manualmente: memoria máxima de 0,8 GB, paquete principal de 10,5 MB
• Uglify se ejecutó manualmente en el paquete principal: memoria máxima de 0,7 GB, paquete principal uglified de 4,2 MB

La CLI utilizada fue 1.5.2 . Es importante tener en cuenta que usé el mismo Uglify que usamos en la CLI ( [email protected] , el incluido por [email protected] ), y que también usé las mismas banderas que usamos en la CLI: --compress pure_getters,passes=3 --mangle .

Las banderas aquí son realmente importantes porque afectan el uso de la memoria y el resultado final. Consulte https://github.com/mishoo/UglifyJS2/issues/2113 para ver una conversación sobre el uso de la memoria en Uglify.

Por los números que obtuve, no diría que hay un problema con la forma en que usamos Uglify. La diferencia (1,1 GB frente a 0,8 + 0,7) es mayor que cada proceso individualmente, pero es menor que ambos juntos. Espero que esto se deba a todos los archivos / mapas de origen cargados en la memoria.

Pero vale la pena mencionar que al no ejecutar --prod tampoco está ejecutando ModuleConcatenationPlugin . Quizás en sus proyectos ese es el problema real y no Uglify. ¿Puedes intentar desactivarlo también? (consulte https://github.com/angular/angular-cli/issues/5618#issuecomment-345465395 sobre cómo deshabilitarlo).

Hola @filipesilva
He intentado crear un modelo muy similar al que utilizo para que las pruebas se puedan realizar con mayor precisión.

En esta aplicación hay básicamente 5 páginas principales (categoría, estado, gravedad, proyecto y problema) que se replican 10 veces dentro del mismo módulo. Tenemos 50 páginas por módulo. Se crearon 10 módulos con un total de 500 páginas.

Para mí, una página se compone de 3 componentes, el punto de entrada, la cuadrícula y el formulario.
Entonces tenemos 1.500 componentes creados.

Hay varios otros componentes creados y utilizados por la aplicación, componentes base que se heredan a través de mecanografiado, paginación, menú, seguridad, módulo compartido, directivas, guardias, modelos, resolutores, entre otros elementos.

No todas las bibliotecas referenciadas a npm se utilizan en este ejemplo, pero creo que el modelo es bastante útil para realizar pruebas.

En este ejemplo, mi consumo máximo de memoria alcanzó los 23 GB.
Algo por debajo de mi caso real, porque aunque este ejemplo tiene muchos más componentes, los componentes creados en mi caso real son más complejos.

No sé si exageré la cantidad de elementos creados para la prueba.
Aunque se han creado cientos de servicios (uno para cada página), todos los módulos y réplicas de páginas llaman a las mismas cinco URL de API (categoría, estado, gravedad, proyecto y problema).

Tanto la API como el proyecto angular están publicados y trabajando en:
Api: http://clientes.tolitech.com.br/ngTestApi
Documentación de API: http://clientes.tolitech.com.br/ngTestApi/api-docs
Angular: http://clientes.tolitech.com.br/ngtest/

Para descargar el código fuente:
http://www.codegenerator.com.br/downloads/ng-test.zip

@Tolitech whoa esto es perfecto, ¡muchas gracias! Lo usaré para ejecutar algunos puntos de referencia y ver qué puedo encontrar. También intentaremos recortarlo para hacer un problema de paquete web por ModuleConcatenationPlugin para que podamos poner la bola en marcha allí. ¡Esto es genial!

@filipesilva debido a su comentario, comenté que el uso de memoria de las líneas disminuyó de 5.5 gb a 2.5 gb

@WandererInVoids ok, esa es una buena señal. Seguiré presionando en esta línea de investigación.

@Tolitech usando su repositorio (CLI 1.4.1 / Angular 4.4.6 / TS 2.3.3):

• ng build picos en 2,2 GB de RAM
• ng build --prod alcanza su punto máximo en 18,5 GB de RAM

El uso de memoria por progreso % ve así:

• 0-11% - pico de 3 gb (ngtools / paquete web)
• 11% -89% - pico de 5.2gb (cargando y analizando ~ 4.3k módulos en el paquete web)
• 90% -94% - pico de 8.0 gb (concatenación de módulos, uglify)
• 95-100% - pico de 18,5 GB (emisor)

También intenté actualizar la reproducción para usar CLI 1.5.2 / Angular 5.0.2 / TS 2.4.2.

• ng build picos en 2,3 GB de RAM
• ng build --prod picos en 22.0GB de RAM

El uso de memoria por progreso % ve así:

• 0-11% - pico de 3,3 gb (ngtools / webpack, optimizador de compilación)
• 11% -89% - pico de 4.0gb (cargando y analizando ~ 4.3k módulos en el paquete web)
• 90% -94% - pico de 8,6 gb (purificar, concatenación de módulos, uglificar)
• 95-100% - pico de 22,0 gb (emisor)

Nota: el uso de CLI 1.5 + Angular 5 tiene como valor predeterminado el uso de Build Optimizer en las compilaciones de prod. También noté que la fase del 92% tomó mucho más tiempo que antes, como informó @changLiuUNSW , mientras que el uso de la memoria se estancó un poco. Me hace pensar que PurifyPlugin (parte de Build Optimizer) es lo que lleva tanto tiempo aquí.

A modo de comparación, también intenté compilar el proyecto usando ngc y alcanzó un máximo de 3.3gb de memoria usada. Comparando eso con la fase 0-11%, parece que nuestro complemento del compilador no agrega una sobrecarga significativa. tsc alcanza un máximo de 830 MB de memoria utilizada.

El proyecto que usa Angular 5 se puede encontrar en https://github.com/filipesilva/angular-cli-test-repo.

Aquí hay un desglose de los archivos del proyecto por extensión:

1551 html
   1 ico
   8 jpg
   5 json
   5 png
  46 scss
2637 ts

Al observar los números de uso máximo de memoria, puedo decir un par de cosas:

• El uso de memoria de la compilación (fase 0-11%) parece razonable para el tamaño del proyecto.
• La fase 11% -89% tarda un tiempo en cargar todo, pero tampoco es muy sorprendente.
• Esperaba que la fase del 90% al 94% tomara la mayor parte del uso de la memoria, pero ese no fue el caso en absoluto.
• La fase del 95-100% es donde la memoria se está agotando masivamente.

Voy a hacer un seguimiento con la gente de Webpack para ver qué está sucediendo realmente en esa última fase.

@Tolitech , has sido de gran ayuda para llegar al fondo de esto, no puedo agradecerte lo suficiente: 100:

No entiendo cómo la memoria de 3.3 Gb para 1500 archivos HTML es razonable. Eso es 2 Mb por archivo. ¿Estos números contienen basura recolectable o es esto lo que realmente se reclama hasta el final de la compilación?

@filipesilva Mi configuración es así:
CLI 1.5.2 / Angular 5.0.2 / TS 2.4.2
Utilizo algunos paquetes de terceros.

ng build --prod: falla con el error del montón de JavaScript sin memoria
ng --env = build --aot: funciona

Me encontré con este problema. Pude obtener una compilación exitosa con
node --max_old_space_size=8192 node_modules/.bin/ng build --prod

Para agregar la respuesta de @ emilio-martinez, en Windows use:
node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod

''
ng build --aot --prod
95% emitiendo ERROR FATAL: MarkCompactCollector: copia de semi-espacio, reserva en la asignación de generación anterior falló - montón de JavaScript sin memoria

CLI angular: 1.5.2
Nodo: 8.9.1
SO: win32 x64
Angular: 5.0.2
... animaciones, común, compilador, compilador-cli, núcleo, formularios
... http, navegador de plataforma, navegador de plataforma dinámico
... plataforma-servidor, enrutador

@ angular / cdk: 5.0.0-rc0
@ angular / cli: 1.5.2
@ angular / material: 5.0.0-rc0
@ angular-devkit / build-optimizer: 0.0.33
@ angular-devkit / core: 0.0.20
@ angular-devkit / schematics: 0.0.36
@ ngtools / json-schema: 1.1.0
@ esquemas / angular: 0.1.5
mecanografiado: 2.4.2
paquete web: 3.8.1

@tolitech FYI Abrí un problema de paquete web para el uso de memoria ModuleConcatenationPlugin : https://github.com/webpack/webpack/issues/5992.

@Tragetaschen no son solo los archivos HTML, también son todas las transformaciones de código y TS. La cantidad de memoria utilizada por el complemento (que se desarrolla en este repositorio) es razonable en la medida en que no es una gran sobrecarga, 3 vs 3.3gb, sobre el compilador ngc sí (que se desarrolla en angular / angular ).

Gracias, @filipesilva

Aprovechando el momento, no sé si este sería el mejor momento, pero ¿hay alguna técnica para mejorar el desarrollo?

Ejemplo: en un proyecto grande como este, un simple cambio en HTML o TS termina tomando mucho tiempo para reflejar la configuración en pantalla. (ng serve -o corriendo).

@tolitech Me gustaría hablar sobre los diferentes factores que influyen en las reconstrucciones de desarrolladores en grandes proyectos, pero preferiría hacerlo en un número aparte. Es algo sobre lo que se pregunta con frecuencia y sería bueno tener una discusión al respecto.

¿Puede abrir un problema llamado "Tiempo total de reconstrucción en proyectos medianos y grandes", compartir su experiencia (tiempo de reconstrucción en la consola pero también tiempo hasta que la aplicación esté lista en el navegador) y enviarme un ping allí, por favor?

@filipesilva He intentado comentar el ModuleConcaternationPlugin y volver a ejecutar nuestras compilaciones. En resumen, nuestro proyecto todavía tiene problemas de memoria.

No sé si esto hace una diferencia, pero la forma en que nuestros proyectos están configurados actualmente, tenemos una serie de bibliotecas internas que, mientras están en desarrollo, usan npm link para vincular.

La memoria alcanza su punto máximo en 2.51gb real / 7.26 virtual cuando se ejecuta con ModuleConcaternationPlugin comentado.
Salida completa:

Matts-MacBook-Pro:mediator-ui matt$ node --max_old_space_size=8192 ./node_modules/.bin/ng build --prod --preserve-symlinks
 14% building modules 37/38 modules 1 active ...pace/html/mediator-ui/src/styles.scssTemplate parse warnings:
The <template> element is deprecated. Use <ng-template> instead ("      <span *ngIf="!itemTemplate">{{field ? option[field] : option}}</span>
                        [WARNING ->]<template *ngIf="itemTemplate" [pTemplateWrapper]="itemTemplate" [item]="option"></template>
        "): ng:///Users/matt/Documents/workspace/html/mediator-ui/node_modules/primeng/components/autocomplete/autocomplete.d.ts.AutoComplete.html<strong i="13">@22</strong>:24                           Date: 2017-11-21T13:58:28.746Z                                                       Hash: 683f2d7486502f8e507a
Time: 252811ms
chunk {0} 0.3a309735936ea414db80.chunk.js (common) 581 kB {20}  [rendered]
chunk {1} 1.8caff8c57661c1307d98.chunk.js () 2.55 kB {20}  [rendered]
chunk {2} 2.b3d1517bf29cec331f56.chunk.js () 179 kB {20}  [rendered]
chunk {3} 3.dd257d4e2f9e4640b2d4.chunk.js () 164 kB {20}  [rendered]
chunk {4} 4.e2edee33bd5ed8a53124.chunk.js () 116 kB {20}  [rendered]
chunk {5} 5.13f271efca121303c5fc.chunk.js () 83.2 kB {20}  [rendered]
chunk {6} 6.08af5ef8c2fe3e09267a.chunk.js () 36.8 kB {20}  [rendered]
chunk {7} 7.8ec810fd30855fef71f7.chunk.js () 30 kB {20}  [rendered]
chunk {8} 8.15f033cf28671ef4988a.chunk.js () 29.5 kB {20}  [rendered]
chunk {9} 9.151ee32b9cc676f2034e.chunk.js () 31.1 kB {20}  [rendered]
chunk {10} 10.cb4d037fcc697b055929.chunk.js () 42.7 kB {20}  [rendered]
chunk {11} 11.f2584b57685d1109a976.chunk.js () 37.5 kB {20}  [rendered]
chunk {12} 12.fe05dccec88da4ae948c.chunk.js () 29.4 kB {20}  [rendered]
chunk {13} 13.2028975a01820ba8496f.chunk.js () 6.1 kB {20}  [rendered]
chunk {14} 14.3be6220b9707e6312847.chunk.js () 3.12 kB {20}  [rendered]
chunk {15} 15.5113d2a9539e99c7ad7f.chunk.js () 6.15 kB {20}  [rendered]
chunk {16} 16.915b0b2f0ed403ce914b.chunk.js () 5.66 kB {20}  [rendered]
chunk {17} 17.485ba9c96f0e3aa081f0.chunk.js () 3.06 kB {20}  [rendered]
chunk {18} 18.db6e52da7740aeca6bb0.chunk.js () 13 kB {20}  [rendered]
chunk {19} polyfills.efb98b65fb45848a1cc3.bundle.js (polyfills) 170 kB {23} [initial] [rendered]
chunk {20} main.4a056bb640e0da824df3.bundle.js (main) 49 kB {22} [initial] [rendered]
chunk {21} styles.e50be95f68f4bf889ab4.bundle.css (styles) 263 kB {23} [initial] [rendered]
chunk {22} vendor.f23a5bbcd6f969d5bec4.bundle.js (vendor) 5.1 MB [initial] [rendered]
chunk {23} inline.35b8b1727b921c4ee6ae.bundle.js (inline) 1.94 kB [entry] [rendered]

Luego probé con el UglifyJsPlugin comentado:
La memoria alcanza un máximo de 1,54 GB reales / 6,35 virtuales.

Matts-MacBook-Pro:mediator-ui matt$ ng build --prod --preserve-symlinks
 14% building modules 37/38 modules 1 active ...pace/html/mediator-ui/src/styles.scssTemplate parse warnings:
The <template> element is deprecated. Use <ng-template> instead ("      <span *ngIf="!itemTemplate">{{field ? option[field] : option}}</span>
                        [WARNING ->]<template *ngIf="itemTemplate" [pTemplateWrapper]="itemTemplate" [item]="option"></template>
        "): ng:///Users/matt/Documents/workspace/html/mediator-ui/node_modules/primeng/components/autocomplete/Date: 2017-11-21T12:31:03.567Z                                                       Hash: a93f716c1a9cd5e34227
Time: 205392ms
chunk {0} 0.7f726b90dbfda77c6fd2.chunk.js (common) 1.78 MB {20}  [rendered]
chunk {1} 1.b2415c8c032817feee41.chunk.js () 9.49 kB {20}  [rendered]
chunk {2} 2.5dbd68c68fe419faaac6.chunk.js () 20.2 kB {20}  [rendered]
chunk {3} 3.f65ad52f00741668ecea.chunk.js () 325 kB {20}  [rendered]
chunk {4} 4.c60ce468892788b134f0.chunk.js () 11.2 kB {20}  [rendered]
chunk {5} 5.0e510c127917b57b977e.chunk.js () 112 kB {20}  [rendered]
chunk {6} 6.17a1081f0b32fa32114a.chunk.js () 116 kB {20}  [rendered]
chunk {7} 7.0db6a1bd5ef8cd7389e2.chunk.js () 145 kB {20}  [rendered]
chunk {8} 8.08dea29d9d56c08ac135.chunk.js () 133 kB {20}  [rendered]
chunk {9} 9.6c20abd2e257ccb42f3a.chunk.js () 112 kB {20}  [rendered]
chunk {10} 10.245dd4aebc6e15998e11.chunk.js () 455 kB {20}  [rendered]
chunk {11} 11.3a63d64df6659b591bc7.chunk.js () 91.8 kB {20}  [rendered]
chunk {12} 12.4bdb534a025025ab67c5.chunk.js () 28.8 kB {20}  [rendered]
chunk {13} 13.58f953974b1a1cab76cd.chunk.js () 27 kB {20}  [rendered]
chunk {14} 14.a295fb06cc46ee37d6dd.chunk.js () 18 kB {20}  [rendered]
chunk {15} 15.573a4c4817db899cbaa5.chunk.js () 522 kB {20}  [rendered]
chunk {16} 16.1bef7d4db5d387785c53.chunk.js () 209 kB {20}  [rendered]
chunk {17} 17.2892448d1217c3964316.chunk.js () 10.2 kB {20}  [rendered]
chunk {18} 18.8a52fcf63d5fb567be17.chunk.js () 80.8 kB {20}  [rendered]
chunk {19} polyfills.efb98b65fb45848a1cc3.bundle.js (polyfills) 497 kB {23} [initial] [rendered]
chunk {20} main.1b1138cc3dcdfe7392ca.bundle.js (main) 174 kB {22} [initial] [rendered]
chunk {21} styles.e50be95f68f4bf889ab4.bundle.css (styles) 263 kB {23} [initial] [rendered]
chunk {22} vendor.2bca18ae1189b0ecdba1.bundle.js (vendor) 14.4 MB [initial] [rendered]
chunk {23} inline.8e041fa7d36f79764f2f.bundle.js (inline) 6.41 kB [entry] [rendered]

La compilación se completó sin la necesidad de agregar memoria adicional a Node.

También intenté ejecutar con node --inspect y adjuntar el depurador de Chrome para capturar algunas instantáneas de pila y perfiles de memoria, pero en mis pruebas eso hizo que la CLI se bloqueara durante la etapa de compilación con 1 módulo restante.

La otra parte que nos está martillando es el tiempo que tarda la compilación para las pruebas, hemos tenido que aumentar continuamente los tiempos de espera en la configuración de Karma, y ​​el tiempo necesario para actualizar la página con las pruebas (durante el desarrollo) es bastante alto, principalmente debido a ese paquete de proveedor de ~ 15 MB.

@filipesilva Entiendo que hay "cosas" que se generan, por eso pregunté si estos son números limpios o si la basura restante del procesamiento real todavía está contenida en ese número.
Si ese es el número real de bytes reclamados, entonces todavía no lo entiendo: suponiendo que 2 Kb por archivo HTML en promedio (!) (Que aún es mucho más de lo que esperaría, tengo 1 kb en promedio) luego cada byte individual de esos archivos (espacios, corchetes angulares, caracteres de texto, etc.) generarán 1000 bytes de contenido transformado / generado. No puedo creer que ese sea el caso.

@Tragetaschen, los números que obtuve fueron solo mirar el administrador de tareas y realizar un seguimiento de cuál era la memoria máxima utilizada. Sin embargo, no estoy seguro de por qué se está enfocando en las plantillas HTML. ngc hace más que simplemente compilar plantillas.

@mattem si ya está alcanzando 1.54GB sin Uglify / ModuleConcaternationPlugin, entonces parece que su proyecto necesita más que la memoria máxima predeterminada del nodo. ¿En cuánta memoria alcanza su punto máximo su proyecto cuando hace solo ng build ?

@mattem ¿ puede abrir un problema llamado "Tiempo total de prueba de reconstrucción en proyectos medianos y grandes", similar al que le pedí a https://github.com/angular/angular-cli/issues/5618#issuecomment -346024634? También es un tema más amplio.

@Tragetaschen También tsc pico y son 830 MB. Sin embargo, tenga en cuenta que ngc compila plantillas, transforma código y genera nuevos archivos TS. Por lo tanto, el total de archivos TS procesados ​​sería aproximadamente el doble. Hice ping al equipo sobre la diferencia entre ngc y tsc .

@filipesilva Ejecutando ng build usa un pico real de 1.31gb / virtual de 5.99.

Aquí está el resultado completo del comando

Matts-MBP:mediator-ui matt$ ng build
Date: 2017-11-21T18:59:28.538Z                                                            
Hash: 5c68c24623b719d5f1b0
Time: 100214ms
chunk {brand-registration-task.module} brand-registration-task.module.chunk.js, brand-registration-task.module.chunk.js.map () 17.4 kB {main}  [rendered]
chunk {common} common.chunk.js, common.chunk.js.map (common) 562 kB {main}  [rendered]
chunk {custom-report-task-module} custom-report-task-module.chunk.js, custom-report-task-module.chunk.js.map () 7.4 kB {main}  [rendered]
chunk {episode-registration-task.module} episode-registration-task.module.chunk.js, episode-registration-task.module.chunk.js.map () 17.5 kB {main}  [rendered]
chunk {feature-not-available-view.module} feature-not-available-view.module.chunk.js, feature-not-available-view.module.chunk.js.map () 4.32 kB {main}  [rendered]
chunk {home-view.module} home-view.module.chunk.js, home-view.module.chunk.js.map () 5.46 kB {main}  [rendered]
chunk {inline} inline.bundle.js, inline.bundle.js.map (inline) 5.83 kB [entry] [rendered]
chunk {job-management-dashboard-task-module} job-management-dashboard-task-module.chunk.js, job-management-dashboard-task-module.chunk.js.map () 8.61 kB {main}  [rendered]
chunk {main} main.bundle.js, main.bundle.js.map (main) 17 MB {vendor} [initial] [rendered]
chunk {material-registration-task.module} material-registration-task.module.chunk.js, material-registration-task.module.chunk.js.map () 18.4 kB {main}  [rendered]
chunk {package-editor-task-module} package-editor-task-module.chunk.js, package-editor-task-module.chunk.js.map () 18.3 kB {main}  [rendered]
chunk {placing-registration-task.module} placing-registration-task.module.chunk.js, placing-registration-task.module.chunk.js.map () 18.5 kB {main}  [rendered]
chunk {playlist-task.module} playlist-task.module.chunk.js, playlist-task.module.chunk.js.map () 23.4 kB {main}  [rendered]
chunk {polyfills} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 534 kB {inline} [initial] [rendered]
chunk {series-registration-task.module} series-registration-task.module.chunk.js, series-registration-task.module.chunk.js.map () 17.5 kB {main}  [rendered]
chunk {session.module} session.module.chunk.js, session.module.chunk.js.map () 18.4 kB {main}  [rendered]
chunk {spot-check-task-module} spot-check-task-module.chunk.js, spot-check-task-module.chunk.js.map () 6.3 kB {main}  [rendered]
chunk {styles} styles.bundle.js, styles.bundle.js.map (styles) 318 kB {inline} [initial] [rendered]
chunk {tasks.module} tasks.module.chunk.js, tasks.module.chunk.js.map () 26.2 kB {main}  [rendered]
chunk {timeline-task-module} timeline-task-module.chunk.js, timeline-task-module.chunk.js.map () 52.3 kB {main}  [rendered]
chunk {user-settings-view.module} user-settings-view.module.chunk.js, user-settings-view.module.chunk.js.map () 31.8 kB {main}  [rendered]
chunk {vendor} vendor.bundle.js, vendor.bundle.js.map (vendor) 5.07 MB [initial] [rendered]
chunk {views.module} views.module.chunk.js, views.module.chunk.js.map () 91.1 kB {main}  [rendered]
chunk {workflow-dashboard-task-module} workflow-dashboard-task-module.chunk.js, workflow-dashboard-task-module.chunk.js.map () 1.76 MB {main}  [rendered]

No nos encontramos con problemas de memoria (todavía, supongo) cuando ejecutamos compilaciones de desarrollo, generalmente estamos experimentando lo mismo que

@filipesilva Solo para estar seguro: no es que me importe el paso de compilación HTML en sí, es que usted afirmó que el consumo de memoria de 3.3 GiB solo para el procesamiento de HTML y NgModule es "razonable para el tamaño del proyecto". Usar mil veces la memoria en comparación con el tamaño de los datos de entrada mientras el paquete resultante (incluso sin más optimizaciones) tiene un orden de magnitud más pequeño, simplemente no es razonable.

Claro, hay problemas más grandes en lo que respecta al consumo de memoria en este momento y me gustaría poder ser más (bueno, cualquier tipo de) constructivo, pero todo el proceso de compilación actualmente toma uno o dos órdenes de magnitud (!) Más memoria que yo. llamaría "razonable".

@tragetaschen Creo que Felipe está comentando tus matemáticas. Ese paso no solo involucra el archivo HTML, sino que también incluye los archivos CSS y mecanografiado. Con el fin de uglify correctamente, todo su proyecto se lleva a la memoria, por lo que no puede simplemente contar el HTML. Además, parte de su lógica puede causar la duplicación de subconjuntos de su Dom, haciendo explotar el tamaño. Esta es una tarea complicada que requerirá una buena cantidad de RAM. Deberíamos usar la menor cantidad posible, pero no podemos esperar milagros.

@filipesilva Abrió el número # 8579 para los tiempos de reconstrucción de prueba

También tengo el mismo problema. Puedo compartir mi código con @filipesilva

Mi compilación --prod funciona pero es lenta. Cuando agregué --stats-json, se quedó sin memoria. Lo hice funcionar haciendo esto:

"build:prod:myapp:stats": "node --max_old_space_size=4096 node_modules/@angular/cli/bin/ng build --prod --app=myapp --stats-json"

Estamos actualizando la versión de Webpack utilizada en la CLI en https://github.com/angular/angular-cli/pull/8689 para incluir la corrección por uso excesivo de memoria en ModuleConcatenationPlugin (https: // github .com / webpack / webpack / pull / 5997).

Esto estará disponible en la próxima versión de Angular CLI y debería abordar la mayoría de los informes de uso excesivo de memoria en 1.3.x y más.

Me gustaría reiterar que se espera que los proyectos alcancen el límite de memoria después de un cierto tamaño . Cuanto más grande sea su proyecto, más memoria necesitará construir, especialmente en --prod .

Para esos casos, la recomendación es que ejecute la CLI con un límite de memoria aumentado a través de un script npm :

    "ng-high-mem": "node --max_old_space_size=8192 ./node_modules/@angular/cli/bin/ng"

Entonces puedes hacer npm run ng-high-mem -- build --prod para hacer una construcción de producción. Tenga en cuenta el guión doble ( -- ), se usa en los scripts npm para separar argumentos.

En este script, el límite se incrementa a 8 gigas. Puede usar un número mayor si lo necesita.

Mientras tanto, seguiremos realizando mejoras para reducir la huella de memoria del sistema de compilación Angular CLI.

@changLiuUNSW Abrí un problema separado para rastrear el aumento excesivo del tiempo de compilación al usar --build-optimizer : https://github.com/angular/devkit/issues/305.

¡Gracias por tomarse el tiempo de analizar esto con tanto detalle @filipesilva! ¡Muy apreciado!

El problema es que este es mi paquete web.config:

`const ruta = require ('ruta');
const paquete web = require ('paquete web');
const AngularCompilerPlugin = require ('@ ngtools / webpack'). AngularCompilerPlugin;
const merge = require ('webpack-merge');
const CheckerPlugin = require ('impresionante-typecript-loader'). CheckerPlugin;

module.exports = (env) => {
// Configuración en común para los paquetes del lado del cliente y del lado del servidor
// const isDevBuild =! (env && env.prod);
const isDevBuild = true;
const sharedConfig = {
estadísticas: {módulos: falso},
contexto: __dirname,
resolver: {extensiones: ['.js', '.ts']},
producción: {
nombre de archivo: '[nombre] .js',
publicPath: 'dist /' // Webpack dev middleware, si está habilitado, maneja las solicitudes para este prefijo de URL
},
módulo: {
normas: [
{prueba: /.ts$/, incluye: / ClientApp /, usa: isDevBuild? ['awesome-typescript-loader? silent = true', 'angular2-template-loader']: '@ ngtools / webpack'},
{prueba: /.html$/, use: 'html-loader? Minimize = false'},
{prueba: /.css$/, use: ['to-string-loader', isDevBuild? 'css-loader': 'css-loader? minimizar']},
{prueba: /.(png|jpg|jpeg|gif|svg)$/, use: 'url-loader? limit = 25000'}
]
},
complementos: [new CheckerPlugin ()]
};

// Configuration for client-side bundle suitable for running in browsers
const clientBundleOutputDir = './wwwroot/dist';
const clientBundleConfig = merge(sharedConfig, {
    entry: { 'main-client': './ClientApp/boot.browser.ts' },
    output: { path: path.join(__dirname, clientBundleOutputDir) },
    plugins: [
        new webpack.DllReferencePlugin({
            context: __dirname,
            manifest: require('./wwwroot/dist/vendor-manifest.json')
        })
    ].concat(isDevBuild ? [
        // Plugins that apply in development builds only
        new webpack.SourceMapDevToolPlugin({
            filename: '[file].map', // Remove this line if you prefer inline source maps
            moduleFilenameTemplate: path.relative(clientBundleOutputDir, '[resourcePath]') // Point sourcemap entries to the original file locations on disk
        })
    ] : [
        // Plugins that apply in production builds only
        new webpack.optimize.UglifyJsPlugin(),
        new AngularCompilerPlugin({
            tsConfigPath: './tsconfig.json',
            entryModule: path.join(__dirname, 'ClientApp/app/app.module.browser#AppModule'),
            exclude: ['./**/*.server.ts']
        })
    ])
});

// Configuration for server-side (prerendering) bundle suitable for running in Node
const serverBundleConfig = merge(sharedConfig, {
    resolve: { mainFields: ['main'] },
    entry: { 'main-server': './ClientApp/boot.server.ts' },
    plugins: [
        new webpack.DllReferencePlugin({
            context: __dirname,
            manifest: require('./ClientApp/dist/vendor-manifest.json'),
            sourceType: 'commonjs2',
            name: './vendor'
        })
    ].concat(isDevBuild ? [] : [
        // Plugins that apply in production builds only
        new AngularCompilerPlugin({
            tsConfigPath: './tsconfig.json',
            entryModule: path.join(__dirname, 'ClientApp/app/app.module.server#AppModule'),
            exclude: ['./**/*.browser.ts']
        })
    ]),
    output: {
        libraryTarget: 'commonjs',
        path: path.join(__dirname, './ClientApp/dist')
    },
    target: 'node',
    devtool: 'inline-source-map'
});

return [clientBundleConfig, serverBundleConfig];

};
'

Entonces, no estoy usando ModuleConcatenationPlugin y sigo recibiendo el mismo error. Por eso ofrecí mi código

@dobrinsky ¿cuántos archivos TS tienes en tu proyecto? ¿Sabes qué es el uso máximo de memoria?

Tengo 240. Probablemente llegaré a 400 hasta que termine el proyecto.

No, no lo se. Soy principiante ... no se como averiguar eso

Por lo general, ejecuto el proceso de compilación y luego solo miro el administrador de tareas para ver cuánta memoria está usando el proceso. El uso máximo de memoria es solo el número más grande que vi para el uso de memoria mientras el proceso se estaba ejecutando.

:)))) No sabía que era tan simple. Pensé que necesitaba algún software o algo ...

De todos modos, sucedió lo más extraño:

Empecé con:

Luego, Visual Studio comenzó a usar memoria en el proceso de compilación:

Luego, por supuesto, Node comenzó a usar también:

Pero mi pico fue del 68%, con solo 1,67 GB de uso de memoria

Entonces, esto definitivamente es algo más

Actualizar a Angular-CLI 1.5.5, Node a 8.9.1 y Yarn a 1.3.2 Se solucionó ese problema para mí.
Y ejecutar Yarn solucionó mejor que npm.

No estoy usando Yarn. Tengo el nodo 9.2, pero Angular-CLI 1.5.4.

Lo intentaré con 1.5.5

Gracias @filipesilva por tu publicación anterior re: "ng-high-mem". Confirmé con mi proyecto que esto funciona y ya no me quedo sin memoria durante la compilación de prod con aot y build-optimizer activados. Sin esto, me quedé sin memoria.

Scripts package.json:
"ng-high-mem": "nodo --max_old_space_size = 8192 ./node_modules/@angular/cli/bin/ng"
Ahora esto funciona:
npm ejecutar ng-high-mem - build --prod --aot = true --build-optimizer = true

Tenga en cuenta que en su mensaje de arriba escribió:
"Entonces puede ejecutar npm ng-high-mem - --prod para hacer una compilación de producción".
Pero creo que te perdiste "construir" allí:
npm ejecuta ng-high-mem - build --prod

Hola @filipesilva ,

En nuestro proyecto, tenemos el problema de falta de memoria con la versión siguiente
@ angular / cli: 1.2.0
@angular : 4.2.5

Estamos cerca de la producción y esperamos una solución para esto. Debido a algunas limitaciones, no pudimos migrar a angular 5 por ahora.

¿Habrá alguna solución disponible para esto?

@dobrinsky, ¿ ha intentado ejecutar la configuración de su paquete web con node --max_old_space_size=8192 para aumentar el límite de memoria? ¿Cuál es el máximo que ves entonces? Si está justo por encima del máximo que vio antes, podría ser que necesite ese poco de memoria extra.

@JasonPaape gracias, ¡lo agregué ahora!

@ Jayaraj8905 en este punto, su mejor ng-high-mem ) o actualizar. 1.2.0 fue hace mucho tiempo y ya no publicamos correcciones.

El uso de la opción ng-high-mem con @ angular / cli 1.5.4 lo resolvió por mí.
Usando @ angular / cli 1.5.5, vi un 30-40% menos de uso de memoria, pero aún así se interrumpió la memoria, por lo que aún se requiere ng-high-mem para mi compilación.

Ahora usando ng-high-mem (con 8192) está usando mucha más memoria. ¿Está usando más cuando tiene más memoria disponible?

Tenga en cuenta que la actualización del paquete web aún no está disponible. Estará en 1.5.6 o 1.6.0 .

Con suerte, eso también acelerará mucho la construcción de producción. Acabo de migrar del antiguo Angular 2 way (ngc aot + rollup) a angular / cli y el tiempo de construcción aumentó de 4 ma aproximadamente 12 m. :-(

Veo esto desde la migración a angular 5 + angular-cli 1.5.5 en mi máquina de compilación CI.
Gracias por la ayuda del equipo de appveyor, pude usar --max_old_space_size en el archivo cmd del nodo.
Se puede encontrar información relevante en la siguiente discusión (que enlaza aquí):
https://help.appveyor.com/discussions/problems/10192-out-of-memory-when-using-angular-cli-15-angular-5
Y en este número en mi repositorio.
https://github.com/IsraelHikingMap/Site/pull/567

Tengo el mismo problema con @ angular / [email protected]

ng build -prod
 95% emitting                                                                             
<--- Last few GCs --->

  113209 ms: Mark-sweep 853.8 (1439.3) -> 857.6 (1439.3) MB, 271.2 / 0.0 ms [allocation failure] [scavenge might not succeed].
  113472 ms: Mark-sweep 857.6 (1439.3) -> 861.5 (1439.3) MB, 263.2 / 0.0 ms [allocation failure] [scavenge might not succeed].
  113756 ms: Mark-sweep 861.5 (1439.3) -> 876.5 (1423.3) MB, 284.4 / 0.0 ms [last resort gc].
  114039 ms: Mark-sweep 876.5 (1423.3) -> 891.6 (1423.3) MB, 282.5 / 0.0 ms [last resort gc].


<--- JS stacktrace --->

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

Security context: 0x31d99d6cfb51 <JS Object>
    1: DoJoin(aka DoJoin) [native array.js:~129] [pc=0xc7b98c68639] (this=0x31d99d604381 <undefined>,w=0x23bc0f2ffd31 <JS Array[590]>,x=590,N=0x31d99d6043c1 <true>,J=0x31d99d6ae4d1 <String[1]:  >,I=0x31d99d6b46e1 <JS Function ConvertToString (SharedFunctionInfo 0x31d99d652dc9)>)
    2: Join(aka Join) [native array.js:180] [pc=0xc7b9864f2b2] (this=0x31d99d604381 <undefined>,w=0x23bc0f2ffd31 <JS ...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [ng]
 2: 0x10983ec [ng]
 3: v8::Utils::ReportApiFailure(char const*, char const*) [ng]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [ng]
 5: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [ng]
 6: v8::internal::Runtime_StringBuilderJoin(int, v8::internal::Object**, v8::internal::Isolate*) [ng]
 7: 0xc7b939092a7
Aborted (core dumped)

agregando a esta línea
"build-prod": "node --max_old_space_size=8192 ./node_modules/@angular/cli/bin/ng build --prod",
a package.json me ayudó.

@filipesilva Vi que se

@alvachien En la próxima versión de Angular CLI, 1.5.6 o 1.6.0, es lo que dijo un poco más arriba en este hilo.

A juzgar por los últimos lanzamientos, supongo que esto podría suceder esta semana a menos que haya algo en particular que lo bloquee.

La solución / solución alternativa de @kisdaniel parece funcionar bien. ha resuelto mis problemas

Aumentar --max_old_space_size funciona para mí, pero después de una hora más o menos, mi uso de RAM (32 Gb) alcanza el 70% o el 80%, las compilaciones incrementales se ralentizan y el nodo o el servidor se bloquean.

@wolfhoundjesse, ¿estás usando AOT en reconstrucciones?

¿Hay alguna ETA en el lanzamiento con la actualización de los departamentos antes mencionada? Luchando con este problema en nuestro CI que no tiene mucha RAM por ahora, por lo que esta solución se requiere con urgencia (sé que puedo piratear package.json para apuntar directamente al maestro, pero este es un truco que quiero evitar).

Debería ser en el lanzamiento de esta semana, ya que generalmente lanzamos una vez por semana.

@krassx por ahora, prueba la solución de

@ mast3rd3mon , no ayuda mucho ya que tenemos 4 GB de RAM en nuestra máquina de compilación. Intentaré jugar con el límite para que funcione.

@krassx tal vez intente el mismo comando pero para 4gb de ram? entonces 4096 no 8192

Probé eso. Y saqué ese error de memoria. Funciona en mi máquina local (macOS, 8GM RAM) pero falla en la máquina de compilación (Linux, 4GB).

@krassx intente deshabilitar el optimizador de compilación y el mapa de origen, ¿puede compartir el suyo comando de compilación?

node --max_old_space_size=8192 ./node_modules/@angular/cli/bin/ng build --target=production --aot --output-hashing=bundles --build-optimizer=true

Esto es lo que uso localmente sin errores. Pero falla en la máquina CI como señalé antes.

@krassx prueba esto para la producción, solo puedes usar prod
node --max_old_space_size=4096 --stack_size=512 ./node_modules/@angular/cli/bin/ng build --prod -vc --build-optimizer=false
consulte esta página para obtener más opciones https://github.com/angular/angular-cli/wiki/build

Ok, lo intentaré. Gracias.

@WandererInVoids , deshabilitar el optimizador de compilación funcionó. Gracias por el consejo.

@krassx de tu bienvenida

@angular/[email protected] ahora está disponible e incluye la corrección de memoria en el lado de Webpack.

@filipesilva Estoy usando node --max_old_space_size=16384 node_modules/.bin/ng serve --aot . Actualizaré a rc.2 ahora.

@filipesilva Lo siento, estoy de viaje y me perdí tu pregunta. Para responder, sí, mis problemas comenzaron después de actualizar a 1.5.0 y el simple ng build --prod falló con cualquier 1.5.x. Tuve que construir, como muchos otros, con memoria elevada node --max-old-space-size=8192 node_modules\@angular\cli\bin\ng build --prod .

Habiendo dicho eso, al mismo tiempo que actualicé a 1.5, incluí una biblioteca de terceros que probablemente envió el proceso de compilación al límite.

Y ahora las buenas noticias. Acabo de actualizar a 1.6 y la compilación termina bien con ng build --prod .

Gracias.

Puedo confirmar este problema, parece serio.

Ocurre solo cuando AOT está habilitado.

Entonces funcionará bien si desactivo AOT y ejecuto : ng build --prod --aot false

CLI angular: 1.5.5
Nodo: 8.9.1
SO: linux x64
Angular: 5.0.5
... animaciones, común, compilador, compilador-cli, núcleo, formularios
... http, servicio de idioma, navegador de plataforma
... plataforma-navegador-dinámico, enrutador

@ angular / cli: 1.5.5
@ angular-devkit / build-optimizer: 0.0.34
@ angular-devkit / core: 0.0.22
@ angular-devkit / schematics: 0.0.39
@ ngtools / json-schema: 1.1.0
@ ngtools / paquete web: 1.8.5
@ esquemas / angular: 0.1.9
mecanografiado: 2.4.2
paquete web: 3.8.1

1.6.0 parece habernos solucionado. Nuestra aplicación se compiló _sin_ ampliar la memoria.

@elclanrs no está aquí, (1.6.0)

aparentemente, la actualización a la última cli (1.6) / angular (5.1) / mecanografiado (2.5) resolvió el problema

Actualicé a cli 1.6 y angular 5.1 y ahora nuestra aplicación podría construir menos de 1.7 gigas

@filipesilva un poco tarde, pero finalmente pude probar ag-Grid con 1.6.0 y ahora todo funciona bien.

Gracias por tu arduo trabajo en esto

@filipesilva Probé la 1.6.0, parece que mi proyecto funciona bien, gracias.

@filipesilva no funciona para mí, pero el tiempo de construcción y el uso de memoria disminuyeron

Ahora es el momento de cambiar a Bazel / Rollup

Actualicé a cli 1.6 y angular 5.1.
La memoria máxima que usa ahora la compilación de producción es de alrededor de 1,3 GB. Así que ya no hay errores de montón.

Lo extraño es que el proceso está 'suspendido' en '92% de optimización de activos de fragmentos' durante 7 minutos del total de 9 minutos de tiempo de construcción.
¿Lo que está sucediendo allí?

@Ristaaf muchas gracias, tu solución funciona a la perfección

Todavía tenemos este problema. Tuvimos este problema desde angular@2 cuando usé CLI angular por primera vez. Luego cambié al motor de arranque angular y todo funcionó. Ahora estoy tratando de usar angular cli nuevamente en el mismo proyecto (actualizar desde angular 4) y ahora todavía tengo el mismo problema con angular 5.1 y cli 1.6.2 .

Tenemos un proyecto realmente enorme y estamos usando angular en este proyecto desde las primeras versiones de angular desde 2013.

Cuando simplemente uso ng build build dura 1 hora. Aquí hay un registro .

Cuando uso ng build siempre tengo un error (después de unos minutos de compilación):

ng build
 10% building modules 3/3 modules 0 active                                         
<--- Last few GCs --->

[30628:0x102804600]   151498 ms: Mark-sweep 1405.8 (1664.5) -> 1405.8 (1664.5) MB, 1634.9 / 0.0 ms  allocation failure GC in old space requested
[30628:0x102804600]   152767 ms: Mark-sweep 1405.8 (1664.5) -> 1405.7 (1616.5) MB, 1268.5 / 0.0 ms  last resort 
[30628:0x102804600]   154066 ms: Mark-sweep 1405.7 (1616.5) -> 1405.7 (1601.0) MB, 1298.4 / 0.0 ms  last resort 


<--- JS stacktrace --->

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

Security context: 0x14c9d8b1cef1 <JSObject>
    1: set [native collection.js:~247] [pc=0x2fa4affd9607](this=0x166929284d21 <Map map = 0x20d66a1183b9>,p=0xb60e511a3c9 <NodeObject map = 0x78bae661b01>,x=0x3ce8d86d6ce9 <Object map = 0x3647e82a689>)
    3: record [/Users/pleerock/www/yakdu/ng5.yakdu.dev/node_modules/@angular/compiler-cli/src/transformers/node_emitter.js:135] [bytecode=0x214b10b7f429 offset=37](this=0x166929284ce9 <_NodeEmitte...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/usr/local/bin/node]
 2: node::FatalException(v8::Isolate*, v8::Local<v8::Value>, v8::Local<v8::Message>) [/usr/local/bin/node]
 3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/usr/local/bin/node]
 4: v8::internal::Factory::NewFixedArray(int, v8::internal::PretenureFlag) [/usr/local/bin/node]
 5: v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, 2>::Rehash(v8::internal::Handle<v8::internal::OrderedHashMap>, int) [/usr/local/bin/node]
 6: v8::internal::Runtime_MapGrow(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/bin/node]
 7: 0x2fa4afe040dd
Abort trap: 6

Si quieres saber cuántos códigos y archivos tenemos:

cloc ./src/
    2705 text files.
    2680 unique files.                                          
https://github.com/AlDanial/cloc v 1.66  T=12.20 s (219.4 files/s, 17125.4 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
TypeScript                    2662          21207          15921         143472
CSS                              4           4084            203          18682
SASS                             6            772            305           4144
JSON                             3              0              0             68
HTML                             1              8              5             25
-------------------------------------------------------------------------------
SUM:                          2676          26071          16434         166391
-------------------------------------------------------------------------------

@pleerock, ¿ ha intentado usar el comando para aumentar la memoria máxima, tanto en compilaciones prod como dev?

Si su proyecto está cerca de la memoria máxima, necesitará mucha GC y eso ralentiza las cosas. Aumentar la memoria máxima incluso cuando no lo está utilizando (como en dev) debería ayudar.

@filipesilva gracias, funciona. Tanto prod como dev builds. Y el tiempo de construcción sigue siendo de 1 hora. Me alegro de que funcione de esta manera, sin embargo, tener que esperar 1 hora cada vez es un problema. Además, es un gran problema ejecutar ng serve . Cuando lo ejecutamos, tarda la misma 1 hora en comenzar a servir, lo que hace que el proceso de desarrollo sea completamente imposible.

@pleerock sí 1h por ng serve es realmente extraño. Nunca había visto un tiempo de construcción tan grande en ningún proyecto que haya manejado.

Tengo informes de compilaciones de producción lentas de esa longitud (https://github.com/angular/angular-cli/issues/6795) pero no he oído hablar de nada como eso solo por ng serve ... use https://github.com/filipesilva/angular-cli-test-repo como punto de referencia para proyectos más grandes y tiene alrededor de 2400 archivos TS, pero solo toma unos minutos.

¿Tu réplica es pública o hay alguna forma de que yo pueda verla?

Otra opción sería tomar un perfil de CPU (hay algunas instrucciones aquí https://github.com/angular/angular-cli/issues/8259). Pero no me sorprendería que las herramientas de desarrollo se bloqueen, por lo general lo hacen en trabajos enormes. ¿Quizás un perfil de CPU de solo unos minutos sería factible?

¿Tu réplica es pública o hay alguna forma de que yo pueda verla?

no, no es público. Si puedes, podemos hacer una llamada y te puedo mostrar y tal vez podamos usar TeamViewer o cosas similares.

Por cierto, el paso de 76% basic chunk optimization toma la mayor parte del tiempo (99%). Si ejecuto ng serve y cambio un archivo, me lleva la misma 1 hora reconstruir todo.

Perfil de CPU de los primeros 10 minutos del proceso 76% basic chunk optimization (ng serve):

CPU-20180103T195000.cpuprofile.zip

Gracias por conseguirme ese perfil de CPU. Entonces, la mayor parte del tiempo se dedica a algunas operaciones de matriz. Parece que esto está sucediendo como parte de la detección del módulo de paquete web. Todas las operaciones que toman mucho tiempo ocurren en webpack/lib/optimizer/RemoveParentModulesPlugin.js .

@TheLarkInn, ¿esto te suena? Me pregunto si es algún tipo de problema de importación circular.

@pleerock ¿qué versión de paquete web aparece cuando haces npm ls webpack cierto?

paquete web npm ls

└─┬ @angular/[email protected]
  └── [email protected] 

Prueba —stacksize 2048

Cordialidad,
Amina BIZID

Le 3 janv. 2018 à 10:58, Umed Khudoiberdiev [email protected] a écrit:

Todavía tenemos este problema. Tuvimos este problema desde angular @ 2 cuando usé CLI angular por primera vez. Luego cambié al motor de arranque angular y todo funcionó. Ahora estoy tratando de usar angular cli nuevamente en el mismo proyecto (actualizar desde angular 4) y ahora todavía tengo el mismo problema con angular 5.1 y cli 1.6.2.

Tenemos un proyecto realmente enorme y estamos usando angular en este proyecto desde las primeras versiones de angular desde 2013.

Cuando simplemente uso ng build build, dura 1 hora. Aquí hay un registro.

Cuando uso ng build -prod o ng build -prod -aot, siempre tengo un error (después de unos minutos de compilación):

ng build -prod -aot
10% módulos de construcción 3/3 módulos 0 activos
<--- Últimos GC --->

[30628: 0x102804600] 151498 ms: Mark-sweep 1405.8 (1664.5) -> 1405.8 (1664.5) MB, 1634.9 / 0.0 ms falla de asignación GC en el espacio anterior solicitado
[30628: 0x102804600] 152767 ms: barrido de marca 1405,8 (1664,5) -> 1405,7 (1616,5) MB, 1268,5 / 0,0 ms último recurso
[30628: 0x102804600] 154066 ms: barrido de marca 1405,7 (1616,5) -> 1405,7 (1601,0) MB, 1298,4 / 0,0 ms último recurso

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

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

Contexto de seguridad: 0x14c9d8b1cef1
1: establezca [colección nativa.js: ~ 247] [pc = 0x2fa4affd9607] (esto = 0x166929284d21

ERROR FATAL: CALL_AND_RETRY_LAST Error en la asignación: pila de JavaScript sin memoria
1: nodo :: Abort () [/ usr / local / bin / node]
2: node :: FatalException (v8 :: Isolate , v8 :: Local <: value i = "33">, v8 :: Local <: message i = "34">) [/ usr / local / bin / node]3: v8 :: internal :: V8 :: FatalProcessOutOfMemory (char const , bool) [/ usr / local / bin / node]
4: v8 :: internal :: Factory :: NewFixedArray (int, v8 :: internal :: PretenureFlag) [/ usr / local / bin / node]
5: v8 :: internal :: OrderedHashTable <: internal :: orderhashmap i = "38"> :: Rehash (v8 :: internal :: Handle <: internal :: orderhashmap i = "39">, int) [/ usr / local / bin / node]
6: v8 :: internal :: Runtime_MapGrow (int, v8 :: internal :: Object *, v8 :: internal :: Isolate ) [/ usr / local / bin / node]
7: 0x2fa4afe040dd
Trampa de aborto: 6
Si quieres saber cuántos códigos y archivos tenemos:

cloc ./src/
2705 ​​archivos de texto.
2680 archivos únicos.

https://github.com/AlDanial/cloc v 1.66 T = 12.20 s (219.4 archivos / s, 17125.4 líneas / s)

Código de comentario en blanco de archivos de idioma

TypeScript 2662 21207 15921 143472
CSS 4 4084203 18682
SASS 6772305 4144
JSON 3 0 0 68

HTML 1 8 5 25

SUMA: 2676 26071 16434 166391

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o silencie el hilo.

¿Qué versión de NodeJs estás ejecutando aquí? Si es <8,9, ¿le importaría probar y volver a perfilar? Se ha realizado un trabajo significativo en V8 con la recolección de basura que surgió en esa versión del nodo en el que colaboramos con el equipo de V8.

@TheLarkInn actualizado de v8.4.0 a v9.3.0 .
Perfilado de los primeros 12 minutos de RemoveParentModulesPlugin ejecución:

CPU-20180105T160658.cpuprofile.zip

@JaapMosselman, el chunk asset optimization en las compilaciones de prod es cuando ocurren las concatenaciones de módulos y Uglification. Estas son las optimizaciones que reducen el tamaño de su paquete al analizar el código y eliminar el que no se usa.

Es lento por su propia naturaleza, pero https://github.com/angular/angular-cli/pull/8668 (combinado pero esperando que se publique 1.7) ayudará al ejecutar Uglify en paralelo.

@pleerock He estado mirando Webpack 4 y pensé que tal vez podría ayudar, ya que hay muchas mejoras de rendimiento allí. El complemento en cuestión ha sufrido algunos cambios:

• en [email protected] : https://github.com/webpack/webpack/blob/b545b519b2024e3f8be3041385bd326bf5d24449/lib/optimize/RemoveParentModulesPlugin.js
• en [email protected] : https://github.com/webpack/webpack/blob/9334fd8547831ded7f11e05319616a72ea0b4698/lib/optimize/RemoveParentModulesPlugin.js

Parece que hay algunos cambios de optimización allí. Pero no estoy seguro de si el cuello de botella ha cambiado.

Hay dos lugares donde se dedica tiempo a su perfil de CPU:

• una llamada has dentro de la función hasModule :
  
• una llamada filter dentro de la función hasModule :
  

Sin embargo, esta función no ha cambiado, así que no creo que acelere su caso. Voy a abrir un problema en el paquete web sobre esto.

EDITAR: abierto como https://github.com/webpack/webpack/issues/6248

Comencé a tener este problema el mes pasado, probé muchas soluciones y lo hizo funcionar después de actualizar a angular-cli 1.6.2. Pero la compilación comenzó a tardar unos 45 minutos, lo que dificultó el impulso de nuevas compilaciones. Pero al menos estaba funcionando. Ahora aparece el problema nuevamente, y esta vez, solo funciona ocasionalmente. Y cuando funciona, todavía tarda aproximadamente una hora. Supongo que el problema comenzó a ocurrir después de que la base de código creciera por encima de un umbral, antes de esto, la compilación solía tomar ~ 10 minutos.
¿Hay alguna manera de superar los frecuentes errores de compilación? Este es el resultado que obtengo:

92% chunk asset optimization<--- Last few GCs --->

[34132:0000025213C0DB90]  2282774 ms: Mark-sweep 1401.9 (1713.9) -> 1401.9 (1699.9) MB, 1637.6 / 0.0 ms  last resort GC in old space requested


<--- JS stacktrace --->

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

Security context: 0000037423C25EE1 <JSObject>
    2: visit [0000033FF8602311 <undefined>:7667] [bytecode=0000002651BE0769 offset=620](this=0000038789453039 <TreeWalker map = 0000020B4AB1BD21>,node=000001D6E5AAD121 <AST_VarDef map = 000002C8A2BBA649>,descend=0000001D6E073821 <JSFunction (sfi = 000003D9CF111AF9)>)
    4: _visit [0000033FF8602311 <undefined>:1512] [bytecode=000003D9CF10CF99 offset=57](this=0000038789453039 <TreeWalker map = ...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

Versión angular: 4.2.4
Versión de Angular-cli: 1.6.2
Versión de TypeScript: 2.3.4
Versión de nodo: 8.9.3
npm Versión: 5.5.1

Este es el número de archivos individuales:

      2 gif
      1 gitkeep
    252 html
      1 ico
      5 jpg
      1 js
      6 json
    110 png
    390 scss
    509 ts

Cualquier orientación será muy apreciada. Atascado en esta situación de no construcción durante las últimas 24 horas 😕

@sabeersulaiman, ¿ ha intentado configurar un script npm para aumentar la memoria disponible? Lo mencioné en https://github.com/angular/angular-cli/issues/5618#issuecomment -348225508.

Si todavía tienes compilaciones muy largas (más de 10 minutos) y tienes una reproducción disponible, me encantaría investigarla.

@filipesilva que hizo el truco. Lo probé, pero creo que por error probé --max-old-space-size lugar de --max_old_space_size . Funciona bien ahora y solo toma ~ 4 minutos. Y alrededor de ~ 8 min en el servidor CI. Gracias.

He investigado un poco y, de acuerdo con esto, la sintaxis --max-old-space-size y --max_old_space_size son válidas. Aquí hay un enlace en la documentación de Nodel sobre primer enfoque no funciona , pero sin darse cuenta, ambos deberían funcionar.

@filipesilva Puedo hacer build usando webpack3, el último angularcli y toma 1 hora con el nodo 8 como discutimos.

Ahora, estoy tratando de construir una versión de producción usando build --prod y tengo un error de memoria en el 92%:

node --max_old_space_size=16384 ./node_modules/@angular/cli/bin/ng "build" "--prod"

 10% building modules 5/6 modules 1 active ...du.dev/src/assets/css/styles-prod.cssNode#mo  92% chunk asset optimization                                                      <--- Last few GCs --->

[633:0x102804600]  6440993 ms: Scavenge 3626.0 (4651.3) -> 3611.8 (4651.3) MB, 28.9 / 0.0 ms  allocation failure 
[633:0x102804600]  6441072 ms: Scavenge 3627.1 (4651.3) -> 3612.5 (4651.3) MB, 26.6 / 0.0 ms  allocation failure 
[633:0x102804600]  6452624 ms: Mark-sweep 4189.7 (4899.4) -> 3245.2 (4747.3) MB, 344.1 / 0.0 ms  (+ 3081.6 ms in 990 steps since start of marking, biggest step 6.3 ms, walltime since start of marking 4825 ms) finalize incremental marking via stack guard G

<--- JS stacktrace --->

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

Security context: 0x27d30fb25ee1 <JSObject>
    1: flatten_args(aka flatten_args) [0x27d3efb02311 <undefined>:~11681] [pc=0x372b5a5bba0e](this=0x27d3efb02311 <undefined>,fn=0x27d3b7e0fe01 <AST_Function map = 0x27d444b33ab1>,scope=0x27d3b7e0f631 <AST_Function map = 0x27d411240269>)
    3: /* anonymous */(aka /* anonymous */) [0x27d3efb02311 <undefined>:11627] [bytecode=0x27d350f41949 offset=5456](this=0x27d3efb02311 <undefined>,self=0x27d4...

FATAL ERROR: invalid table size Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/usr/local/bin/node]
 2: node::FatalException(v8::Isolate*, v8::Local<v8::Value>, v8::Local<v8::Message>) [/usr/local/bin/node]
 3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/usr/local/bin/node]
 4: v8::internal::HashTable<v8::internal::StringTable, v8::internal::StringTableShape>::EnsureCapacity(v8::internal::Handle<v8::internal::StringTable>, int, v8::internal::PretenureFlag) [/usr/local/bin/node]
 5: v8::internal::StringTable::LookupKey(v8::internal::Isolate*, v8::internal::StringTableKey*) [/usr/local/bin/node]
 6: v8::internal::StringTable::LookupString(v8::internal::Isolate*, v8::internal::Handle<v8::internal::String>) [/usr/local/bin/node]
 7: v8::internal::LookupIterator::LookupIterator(v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Name>, v8::internal::LookupIterator::Configuration) [/usr/local/bin/node]
 8: v8::internal::LookupIterator::PropertyOrElement(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, bool*, v8::internal::LookupIterator::Configuration) [/usr/local/bin/node]
 9: v8::internal::Runtime_KeyedGetProperty(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/bin/node]
10: 0x372b54a8463d
11: 0x372b5a5bba0e

Si tiene tiempo, ¿puede probar con CLI 1.7.0-beta.0?

Parece que algo mejoró, los tiempos de compilación se redujeron en un 50% en mi proyecto + el consumo de memoria también (para el proceso de un solo nodo), aunque creo que veo que se generan más procesos de nodo. @clydin : ¿que se arregló?

@pleerock sobre --max-old-space-size y --max_old_space_size . El nodo 8.9.3 en Windows me da el siguiente error al usar --max-old-space-size

 $ npm run start

> [email protected] start C:\Projects\test
> node --max-old-space-size=8192 ./node_modules/.bin/ng serve

C:\Projects\test\node_modules\.bin\ng:2
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
          ^^^^^^^

SyntaxError: missing ) after argument list
    at createScript (vm.js:80:10)
    at Object.runInThisContext (vm.js:139:10)
    at Module._compile (module.js:599:28)
    at Object.Module._extensions..js (module.js:646:10)
    at Module.load (module.js:554:32)
    at tryModuleLoad (module.js:497:12)
    at Function.Module._load (module.js:489:3)
    at Function.Module.runMain (module.js:676:10)
    at startup (bootstrap_node.js:187:16)
    at bootstrap_node.js:608:3
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] start: `node --max-old-space-size=8192 ./node_modules/.bin/ng serve`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\sabee\AppData\Roaming\npm-cache\_logs\2018-01-13T04_47_40_099Z-debug.log

¿Se supone que esto debe suceder o es un problema con la forma en que lo configuré?

@filipesilva Pude construir un sitio usando webpack4 (con correcciones aplicadas por el equipo de webpack) + aot usando su sucursal en 40 minutos. Pero por alguna razón index.html no se emite (incluso con la compilación de desarrollo regular)

Este error ocurre con cli 1.6.2

node --max_old_space_size=12288 ./node_modules/.bin/ng build --prod

usar este comando funciona para mí

actualizado a @ angular / [email protected]
pero sigue siendo el mismo error 'FATAL ERROR: CALL_AND_RETRY_LAST Allocation fall - JavaScript heap out of memory'

Esto empezó a pasarnos. ¿Cómo puede suceder esto cuando he bloqueado todas mis versiones angulares? ¿La CLI no sigue las versiones adecuadas? ¿Hay algún arreglo para esto?

@Sarfarazsajjad y @sabeersulaiman, ¿está intentando con un nodo de 64 bits o un nodo de 32 bits?

El nodo de 64 bits con --max_old_space_size debería compilarse bien para aplicaciones grandes en modo --prod.

Probé lo que dijo
Gracias al equipo de angular-cli.

También hice una prueba con 1.7.0-beta.0. El tiempo de construcción se redujo de 13 minutos a 6,5 ​​minutos (en mi máquina de construcción no rápida). En mi máquina de desarrollo, se compila ahora en 3.6 minutos (con 1.6.0 fueron 7.8 minutos).
El tamaño del paquete principal aumentó un poco de 2653 a 2664 KB.
Necesitaba agregar @ angular-devkit / core como una dependencia de desarrollo a mi paquete, de lo contrario no se instalaría automáticamente.

Probado siguiendo con cli 1.6.5

$ node --max_old_space_size=8192 node_modules/.bin/ng build --prod
Date: 2018-01-26T07:31:27.619Z
Hash: 50238294b6564c10ffb7
Time: 130002ms
chunk {0} polyfills.63eb1df6d53730045032.bundle.js (polyfills) 97.8 kB [initial] [rendered]
chunk {1} main.401dee7547b2af51d287.bundle.js (main) 1.57 MB [initial] [rendered]
chunk {2} styles.3f5700be7447a96e8808.bundle.css (styles) 50.2 kB [initial] [rendered]
chunk {3} inline.82501ecadee5847574b3.bundle.js (inline) 1.45 kB [entry] [rendered]

$ ng build --prod
Date: 2018-01-26T07:35:55.320Z
Hash: 50238294b6564c10ffb7
Time: 136006ms
chunk {0} polyfills.63eb1df6d53730045032.bundle.js (polyfills) 97.8 kB [initial] [rendered]
chunk {1} main.401dee7547b2af51d287.bundle.js (main) 1.57 MB [initial] [rendered]
chunk {2} styles.3f5700be7447a96e8808.bundle.css (styles) 50.2 kB [initial] [rendered]
chunk {3} inline.82501ecadee5847574b3.bundle.js (inline) 1.45 kB [entry] [rendered]

Así que 6 segundos ... no vale la pena ...

tuve que pasar de angular-cli 1.5.0 a 1.6.7 para resolver mi error de memoria de compilación (sin configurar --max_old_space_size)

Probé lo que dijo
Gracias al equipo de angular-cli.

Para mí, 1.7.0-beta.3 no funciona. Todavía obtengo:

Security context: 0x3926bacfb39 <JS Object>
    2: write [/node_modules/typescript/lib/typescript.js:~9597] [pc=0x93487866c7f] (this=0x10feca1f0819 <an Object with map 0x98bc5b8c929>,s=0x39beab773a79 <String[2]: i4>)
    3: pipelineEmitExpression(aka pipelineEmitExpression) [/node_modules/typescript/lib/typescript.js:~69005] [pc=0x93487876ff7] (this=0x3926ba04381 <undef...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

Angular CLI: 1.7.0-beta.3
Node: 6.10.1
OS: darwin x64
Angular: 5.2.4
... common, compiler, compiler-cli, core, forms, http
... platform-browser, platform-browser-dynamic, router

@angular/cli: 1.7.0-beta.3
@angular-devkit/build-optimizer: 0.2.0
@angular-devkit/core: 0.2.0
@angular-devkit/schematics: 0.2.0
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.10.0-beta.3
@schematics/angular: 0.2.0
@schematics/package-update: 0.2.0
typescript: 2.6.2
webpack: 3.10.0

actualizar Angular Cli global y local a 1.7.0-rc.0 funciona para mí

actualizar Cli angular global

npm uninstall -g @angular/cli
npm cache clean --force
npm install -g @angular/[email protected]

actualizar Angular Cli local
npm install @angular/[email protected]

Tendría cuidado con rc.0 - corrompe algunos activos en aot compilaciones, por ejemplo, fuentes. Creo que se ha solucionado, pero aún no ha habido un lanzamiento.

El uso de @angular/[email protected] NO solucionó el problema.

Solución alternativa: se tuvo que usar "ng-high-mem": "node --max_old_space_size=8192 ./node_modules/@angular/cli/bin/ng", como se mencionó.

Esto es algo que necesita ser arreglado, chicos.

Solo dale más memoria. Es inevitable que el proceso consuma cada vez más memoria a medida que aumenta el tamaño del proyecto. No hay forma de evitar eso. Lo único que (probablemente) solucionará esto es https://bazel.build , pero aún queda bastante lejos en el futuro.

Entonces, la solución en mi humilde opinión es que ng solo agrega algunas banderas de nodo de forma predeterminada y vamos a dejarlo todo.

No es inevitable. Señala una falla fundamental en la arquitectura de construcción. Si usamos por defecto la bandera --max_old_space_size=8192 , ¿qué tamaño de proyecto se construirá hasta que ese valor sea demasiado pequeño?

Solo estoy siendo práctico, la compilación usa mucho webpack, nodo, etc. y muchas otras dependencias que pueden no ser triviales para reescribir. Se acerca el cambio a bazel, entonces, ¿cuántos años hombre se deben poner en esta vieja tubería de construcción?

Siempre que el requisito de memoria no sea escandaloso, me gustaría votar el esfuerzo de dedicarme a otra cosa, ya que hay muchas cosas que necesitan atención. Es 2018, así que no creo que 4 u 8 gigas de memoria sean tanto.

Tampoco creo que muchos usuarios se hubieran dado cuenta de que la compilación usa 4 gigas de memoria si ese fuera el valor predeterminado.

Dicho esto, me callaré ahora;)

Creo que algo está mal con el procesamiento de SASS, lo que podría estar contribuyendo a estos problemas (definitivamente para las compilaciones de desarrolladores, pero no estoy 100% seguro de ello).

Esencialmente, parece estar sucediendo algo extraño con la deduplicación descarada. En mi proyecto, tenía un archivo sass común con un montón de inclusiones (bootstrap y demás). Esto se incluye generosamente en todos los archivos scss de componentes con la expectativa de que se eliminen los duplicados en la compilación.

Sin embargo, me di cuenta de que mi desarrollo de desarrollo era de hasta 150 MB para main.bundle.js y estaba golpeando mi estación de trabajo cuando se construyó. Al reestructurar el scss para que solo se incluyera, era necesario en cada componente que compré hasta unos 11 MB.

Para la compilación aot fue menos significativo (creo que la mayor parte del tamaño fue de mapas de origen) pero aún así pasó de:

Date: 2018-02-15T16:02:33.684Z
Hash: 41fbbec562aa54786309
Time: 208050ms
chunk {scripts} scripts.d12170c009efb4ef2dbb.bundle.js (scripts) 209 kB [initial] [rendered]
chunk {0} main.0cafaa559bb3700ad50f.bundle.js (main) 18.4 MB [initial] [rendered]
chunk {1} polyfills.700d53c47d7964ae8cad.bundle.js (polyfills) 169 kB [initial] [rendered]
chunk {2} styles.c77032e78777d8b73cfb.bundle.css (styles) 282 kB [initial] [rendered]
chunk {3} inline.27eae89520a68a8b4864.bundle.js (inline) 1.45 kB [entry] [rendered]

para

Date: 2018-02-15T15:56:45.830Z
Hash: 147dec00b5e7c81037ed
Time: 155488ms
chunk {scripts} scripts.d12170c009efb4ef2dbb.bundle.js (scripts) 209 kB [initial] [rendered]
chunk {0} main.9b030cbd40e05afd9bf7.bundle.js (main) 3.17 MB [initial] [rendered]
chunk {1} polyfills.700d53c47d7964ae8cad.bundle.js (polyfills) 169 kB [initial] [rendered]
chunk {2} styles.c77032e78777d8b73cfb.bundle.css (styles) 282 kB [initial] [rendered]
chunk {3} inline.5c3035ae831e1473f3d7.bundle.js (inline) 1.45 kB [entry] [rendered]

También intenté rastrear el uso de la memoria. Parecía que con el scss mejorado se alcanzaba un máximo de aproximadamente 1300 MB de memoria para realizar la compilación aot. Con la configuración anterior de scss, era similar, pero aumentó brevemente a más de 2.5GB al final del proceso. Por lo tanto, podría ser que el uso de la memoria también se vea afectado por el scss duplicado.

(Estoy usando cli v1.7.0-beta.0 por cierto. Rc.0 rompe mis fuentes en aot).

editar: lectura un poco más científica del uso de la memoria:

SCSS ineficaz incluye:

SCSS más eficiente:

No hay mucho en él realmente.

también mejoró scss con cli v1.7.0-rc.0 en lugar de beta.0:

y v1.6.8:

Instalé el aumento de límite de memoria y después de ejecutarlo, aunque se ejecutó correctamente y cambió los archivos en la carpeta del proyecto local (verifiqué los archivos), el uso de la memoria RAM todavía era de 1400 megabytes y no más.

Lo que hice después de eso fue. Fui a la carpeta donde está instalado npm que en mi caso era

C: \ Users \ USER \ AppData \ Roamingnpm

y abrí ng.cmd y lo edité y agregué --max-old-space-size = 10240 en ambos lugares (en la cláusula if y else)

Solo después de que hice eso y probé ng build --prod, comenzó a usar más ram.

Aquí, en la foto, puede ver que estoy ejecutando dos indicaciones de comando. El primero es después de ejecutar el aumento de límite de memoria, y el segundo es después de que edité el archivo ng.cmd manualmente. Puede ver que comenzó a usar 3000 megabytes.

Antes de hacer esta edición, las raras veces que funcionó (para construir el proyecto) me tomó 660 segundos y ahora lo hizo durante 295 segundos.

Espero que te ayude.

@ZgjimDida está funcionando para mí para @ angular / [email protected] después de agregar --max-old-space-size = 10240 en ambos lugares

Actualizar la versión de mecanografiado en package.json a la última versión 2.4.xa 2.7.x, solucionó el problema para mí

¿Agregar SWAP ayudará a resolver este error?

@ kanji-keraliya Me alegro de haber podido ayudar.

@FOSSKolkata
Pero recibo la advertencia de> @ angular / compiler-cli @ 5.2.5 requiere un par de mecanografiado @> = 2.4.2 <2.7 pero ninguno está instalado. Debe instalar las dependencias de pares usted mismo.

mi proyecto se compila en máquinas locales pero no en el CI debido a errores de memoria insuficiente (8 gb de ram, 2 gb de intercambio).
establecer max-old-space-size no es una opción viable para nuestras canalizaciones de CI.

se resolvió la actualización de mecanografiado a 2.7.x, pero aparece una advertencia desagradable acerca de que el compilador ng no admite esa versión de mecanografiado.

esto también es un problema para nosotros;
estamos utilizando un entorno de compilación de VSTS alojado;

nodo: v 8.x
npm: 5.6.0
@ angular / cli: 1.7.2

Intenté ejecutar npm install -g increase-memory-limit && increase-memory-limit antes de ejecutar el comando de compilación ( node ./node_modules/@angular/cli/bin/ng build --prod --e=beta --sourcemaps=true ), pero no ayudó. Sigo recibiendo el error OOM como se indica arriba.

EDITAR: al actualizar el comando de compilación a lo siguiente, parece haber 'solucionado' el problema.
node --max_old_space_size=10240 ./node_modules/@angular/cli/bin/ng build --prod --e=beta --sourcemaps=true

Enfrentando el mismo problema ... Intenté aumentar la asignación de memoria que resolvió esto por un tiempo, pero después de un par de días, las cosas comenzaron a fallar de nuevo continuamente.

Aumentar el límite de memoria podría ser solo un parche y nunca resolver lo que está causando esto. ¿Alguna idea?

parece que a ellos no les importa esto.

@ roymj88 En gran parte, los problemas de rendimiento se han derivado de las optimizaciones de compilación introducidas en el paquete web que eran increíblemente caras en términos de uso de RAM para la compilación. Al menos dos de estos problemas se encontraron y resolvieron en el propio paquete web, en parte con la ayuda de miembros del equipo de angular-cli.

Por lo tanto, piense que es realmente importante indicar qué versión está utilizando, ya que es posible que se haya solucionado para usted, y aproximadamente qué tan grande es su proyecto. Como dependiendo de su tamaño, eventualmente golpeará esa pared. Donde el tiempo total de construcción y creo que el uso de RAM se escala al menos linealmente con el número de archivos.

Entonces, una solución rápida es simplemente aumentar aún más el uso de RAM. Alternativas a eso:

1. Aísle el problema en un repositorio público o simplemente comparta su código si es posible. Les ayudará mucho a tratar de clasificar el problema.
2. Desactive el optimizador de compilación (está activado de forma predeterminada para la producción). Si no le preocupa el tamaño de la carga útil de su aplicación, desactivar esta marca probablemente acelerará significativamente la construcción de su producción.
3. Actualice a Angular 6 beta y angular-cli 6 beta. La última versión usa Webpack 4 junto con algunas otras optimizaciones que supuestamente deberían hacer que las compilaciones sean más rápidas.

parece que a ellos no les importa esto.

@aindigo Creo que eso es incorrecto. Hay mejoras de rendimiento constantes tanto en el cli como, lo que es más importante, en Webpack, que a veces contribuyen ellos mismos los angulares-cli. Es muy probable que Bazel, como alternativa a Webpack, se convierta en una alternativa mucho más eficaz, mientras que la versión 6 parece venir con una buena cantidad de mejoras en la velocidad de compilación en general.

Podría abogar por una priorización diferente, con el gran inconveniente de retrasar otras mejoras y características como los trabajadores de servicio y los esquemas.

Independientemente, piense que el equipo está haciendo un trabajo increíble y espero seguir viendo mejoras en la versión 6 y posteriores.

@Koslun
Las versiones son las siguientes:

• angular-cli: 1.2.4
• angular: 4.1.3
• npm: 3.10.8
• nodo: v6.9.1

El límite de memoria se ha ampliado a la friolera de 2 GB (2097152) y las compilaciones siguen fallando con el problema de la memoria del montón después del 92%.

Por cierto, ¿por qué está cerrado?

Saludos
Roy

@ roymj88 prueba la última versión. Obtuviste 1.2.4 mientras que 1.7.3 está disponible con las mejoras discutidas en el hilo anterior.

@DenisVuyka ¿Está seguro de que el problema anterior se ha resuelto con la última versión, es decir, 1.7.0? La actualización a la última versión puede tener problemas de dependencia y la actualización instantánea puede no ser una opción que podamos hacer de inmediato.

@ roymj88 puede requerir aumentar la RAM a 4 u 8, tal vez confíe en el intercambio si no tiene suficiente RAM. El uso razonable de RAM depende en parte del tamaño de su proyecto. Proporcione el tamaño aproximado de su proyecto. ¿Cuántos miles de líneas de código?

Sin embargo de acuerdo con @DenisVuyka . Si desea alguna optimización, tendrá que actualizar a la última versión de angular-cli. Lo que probablemente debería incluir la actualización a Angular 5 y al nodo 8.x. Si no está utilizando angular universal / ssr, service-workers o bibliotecas específicas vinculadas a versiones anteriores, no debería ser demasiado esfuerzo.

Si no lo está usando, también debe usar yarn o archivos de bloqueo npm si desea evitar que las dependencias se rompan inesperadamente debajo de usted.

En mi experiencia, dejar la bandera --sourcemaps soluciona este problema durante la compilación AOT de proyectos más grandes y, sinceramente, ¿para qué necesitamos mapas de origen en producción?

@Flexicon Gracias por la sugerencia. Nos gusta incluir --sourcemaps en nuestro entorno beta / de prueba, pero compilamos con la bandera --prod para que los bits sean los mismos que en el entorno de producción. Estoy de acuerdo, no hay necesidad de mapas fuente en producción.

pudimos solucionar esto actualizando angular-cli en el archivo package.json a 1.6.7 y dejando mecanografiado en 2.3.4 para que el compilador no advierta sobre versiones no compatibles

Este problema sigue presente incluso al actualizar CLI y TS a las últimas versiones. Vamos chicos...

Con respecto al aumento de la memoria disponible:

gulp maneja los indicadores de nodo. ng podría hacer lo mismo, con la ayuda de https://www.npmjs.com/package/flagged-respawn. Este módulo reaparece el proceso del nodo si están presentes los indicadores v8.

Hasta entonces, la solución alternativa para las máquinas Linux y Windows se ejecuta ng como node --max_old_space_size=4096 node_modules/@angular/cli/bin/ng build ...

protuberancia.

Angular 5 y Node 8.9.1, pero tengo la dependencia circular en la aplicación, ¿quizás hay algún problema?

<--- JS stacktrace --->

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

Security context: 0x19dcc2825ec1 <JSObject>
    1: _walk [0x19dcad702311 <undefined>:~1071] [pc=0x12ea75770373](this=0x19dc87984ec9 <AST_Call map = 0x19dcfb2fecc9>,visitor=0x19dcdb7e1571 <TreeWalker map = 0x19dc6a53c489>)
    2: /* anonymous */ [0x19dcad702311 <undefined>:~1226] [pc=0x12ea7547d7f7](this=0x19dc87984f01 <AST_ObjectKeyVal map = 0x19dcfb2fd359>)
    3: _walk [0x19dcad702311 <undefined>:~1225] [pc=0x12ea756e0c33](this=0x19dc87...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/usr/local/bin/node]
 2: node::FatalException(v8::Isolate*, v8::Local<v8::Value>, v8::Local<v8::Message>) [/usr/local/bin/node]
 3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/usr/local/bin/node]
 4: v8::internal::Factory::NewByteArray(int, v8::internal::PretenureFlag) [/usr/local/bin/node]
 5: v8::internal::TranslationBuffer::CreateByteArray(v8::internal::Factory*) [/usr/local/bin/node]
 6: v8::internal::compiler::CodeGenerator::PopulateDeoptimizationData(v8::internal::Handle<v8::internal::Code>) [/usr/local/bin/node]
 7: v8::internal::compiler::CodeGenerator::FinalizeCode() [/usr/local/bin/node]
 8: v8::internal::compiler::PipelineImpl::FinalizeCode() [/usr/local/bin/node]
 9: v8::internal::compiler::PipelineCompilationJob::FinalizeJobImpl() [/usr/local/bin/node]
10: v8::internal::Compiler::FinalizeCompilationJob(v8::internal::CompilationJob*) [/usr/local/bin/node]
11: v8::internal::OptimizingCompileDispatcher::InstallOptimizedFunctions() [/usr/local/bin/node]
12: v8::internal::StackGuard::HandleInterrupts() [/usr/local/bin/node]
13: v8::internal::Runtime_StackGuard(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/bin/node]
14: 0x12ea7490463d
15: 0x12ea75770373
16: 0x12ea7547d7f7
Abort trap: 6

@ ar53n : tengo dependencias circulares definidas en mi aplicación entre mis modelos, pero esas dan una advertencia en el tiempo de compilación, ya que solo darán un error en el tiempo de ejecución y usted realmente crea sus modelos con las dependencias circulares implementadas (que no deberían sea ​​el caso).

Obtuve mi compilación AOT funcionando con la solución proporcionada por

node --max_old_space_size=4096 node_modules/@angular/cli/bin/ng build ...

Mi comando de compilación exacto basado en mis preferencias:

node --max_old_space_size=4096 node_modules/@angular/cli/bin/ng b -op aot -sm -v -aot

Mis versiones:
Angular CLI: 1.7.2
Node: 6.9.5
Angular: 5.2.7

¿Cómo es que la gente sigue teniendo problemas con esto? El uso de la construcción 1.7.2 de @angular/cli funciona perfectamente sin cambiar el indicador de memoria. Esto es tanto en una computadora con un antiguo i3 y 8gb de ram como en un amd fx6350 con 32gb de ram.

@ mast3rd3mon : bueno, de mis comentarios anteriores, puede ver que estoy usando la misma versión de angular-cli, descartando eso.

Estoy ejecutando un i7 4810MQ con 16GB de ram, lo cual es irrelevante ya que si modifico las marcas de memoria puedo hacer que funcione una compilación AOT

@jarodsmk luego explique cómo funciona bien la computadora de muy baja especificación i3 / 8gb ram en 1.7.2? es evidentemente una especificación mucho más baja que su máquina y tiene solo la mitad del ariete, pero funciona bien? Basado en el hecho de que algunas personas necesitan la bandera y otras no, sospecho que es más un problema de computadora que un problema de cli.

@ mast3rd3mon Depende de qué tan grande sea su proyecto.

Solo un recordatorio de que el consumo de memoria crece cuanto más archivos mecanografiados / html tiene que analizar. En algún momento, su proyecto crecerá por encima del límite y necesitará la bandera. No se trata de la máquina.

El cli se ha optimizado, por lo que los más nuevos pueden hacer frente a más archivos, pero aún así, al final se quedará sin memoria en proyectos más grandes.

El consumo de memoria está determinado (principalmente) por dos factores: la versión cli y el tamaño y la complejidad de su proyecto.

@ mast3rd3mon , con respecto a lo que mencionó @swftvsn :

Tengo un proyecto de nivel empresarial bastante complejo en el que estoy trabajando, con muchos componentes y módulos.

En realidad, podría hacer que mis dos grandes proyectos se compilaran con ng build --prod --base-href ./ --aot si agrego --sm entonces ambos construyen fallan. Esto es con el último cli angular (tanto global como del proyecto) y el último mecanografiado (tanto global como del proyecto).

@jarodsmk yo también, actualmente está en alrededor de 20 módulos, 3 componentes normales
(para usar con el selector html), alrededor de 10 archivos de servicio y alrededor de 15
interfaces, se construye bien en la compilación de RAM i3 / 8gb sin el indicador de memoria.
Yo diria que es muy complejo

>

@makdeniss : sí, agregar el parámetro del mapa de origen es un problema común porque los requisitos de memoria al generarlos en proyectos más grandes pueden ser enormes.

Pero en una compilación de depuración / qa, agregar mapas de origen podría ser beneficioso

@ mast3rd3mon

Tengo 8 módulos con aproximadamente 89 componentes, 20 servicios, varias interfaces y creo que alrededor de 52 clases de modelos, fallando con o sin mapas de origen.

@jarodsmk mis dos proyectos son más grandes y eliminar eso --sm y también actualizar a los últimos deps para ts y cli (y por supuesto ng) resolvió el error de memoria js.

Mmm, tenemos 60 componentes, 5 módulos propios, 47 módulos de terceros importados y alrededor de 50 servicios. Considero que esta es una aplicación realmente simple en comparación con algunas de las cosas empresariales con las que he trabajado.

¿Qué hace la bandera --sm @makdeniss ?

@swftvsn mapas de origen. mejores posibilidades de depuración, pero para prod esto no es necesario de todos modos.

@makdeniss hmm interesante, intenté actualizar mi ts & cli (local en una rama diferente y global) pero no cambié nada

@jarodsmk ¿cómo estás construyendo el proyecto? No cambié ningún indicador de memoria npm por cierto. Todo está por defecto.

@makdeniss
Entonces estos fallan:
ng b -op aot -aot -sm -v
ng b -op aot -aot -v

Pero recurrí a:
node --max_old_space_size=4096 node_modules/@angular/cli/bin/ng b -op aot -aot -sm -v

Que funcionó. Es interesante que establecer max_old_space_size en 4gb ayudó

@jarodsmk debería ayudar, porque le está dando más memoria. Esta es una solución alternativa, pero hacky.

Me encontré con este problema hoy, pero lo vi al intentar realizar un ng build regular. Se detendría al 10% y se colgaría hasta que ocurriera el error. Asignar más memoria le permitió construir. Encontré este problema en mecanografiado (_https: //github.com/Microsoft/TypeScript/issues/14628_) y uno de los comentarios me llevó a cambiar el archivo tsconfig.app.json.

tsconfig.app.json

"include": [
    "src",
    "typedefs"
],

Esto parece haber solucionado el problema. Sin embargo, las pruebas aún no funcionarán y no he podido agregar nada al tsconfig.spec.json para que funcionen.

Medio ambiente:

angular-cli: 1.3.1
node: 8.10.0
os: macOS 10.12.6

He estado siguiendo este hilo durante un tiempo, pero no estoy seguro de si se ha mencionado antes.

En mi caso, estoy haciendo las cosas de reconstrucción automática. Entonces, cuando haga una modificación en mi fuente, reconstruirá y volverá a cargar la página del navegador. La compilación de inicio inicial siempre funciona, pero después de hacer aproximadamente 20 o más modificaciones y, por lo tanto, reconstruir, termino obteniendo el error de memoria insuficiente.

Tengo un proyecto bastante pequeño, por lo que no es el problema que el proyecto en sí construya y alcance un límite de memoria. Me encontré con el problema de la memoria después de que se ejecutaran 10 o más compilaciones repetidas en TeamCity. Al reiniciar el agente / servidor de compilación, las cosas volvieron a la normalidad, por lo que parece que la memoria no se borra después de cada compilación y, finalmente, se agrega hacia el límite.

@Ericdowney angular-cli 1.3.1 es bastante antiguo en este contexto. Han pasado muchas cosas desde entonces hasta 1.7.x. Y mucho más está a punto de suceder cuando lancen 6.x. Es posible que desee cambiar a 1.7.x ahora y luego usar ng update para actualizar a 6.x cuando se publique y también desee migrar a Angular 6.

No esperaría ninguna corrección o ayuda con la versión 1.3.1 de angular cli. Tal vez la versión 6 tenga un soporte LTS similar, pero siempre asumirá la última versión para brindar la mejor experiencia.

Anteriormente tuve este error en Angular 5 con la bandera --aot y luego desapareció con las actualizaciones de @ angular / cli. Ahora me he actualizado a Angular 6 y el problema ha vuelto: /. Estoy usando:

ng serve myapp --prod

 "serve": {
          "builder": "@angular-devkit/build-angular:dev-server",
          "configurations": {
            "production": {
              "optimization": true,
              "aot": true,
              "vendorChunk": false
            }
          }

Y falla con:

** Angular Live Development Server is listening on localhost: 4200, open your browser on http://localhost:4200/ **
 90% chunk assets processing
<--- Last few GCs --->

[19772:000001E2123ECE00]    95613 ms: Mark-sweep 1404.0 (1506.8) -> 1404.0 (1503.8) MB, 1021.6 / 0.0 ms  (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 1130 ms) last resort GC in old space requested
[19772:000001E2123ECE00]    96624 ms: Mark-sweep 1404.0 (1503.8) -> 1404.0 (1503.8) MB, 1010.8 / 0.0 ms  last resort GC in old space requested


<--- JS stacktrace --->

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

Security context: 000000B751F25EE1 <JSObject>
    2: declareVarName [c:\dev\FitRockApp\node_modules\acorn\dist\acorn.js:2831] [bytecode=0000036F39CCD189 offset=32](this=0000016629E387F9 <Parser map = 0000000C4C3050C1>,name=0000016629E37629 <String[33]: styles_DietTemplatesPageComponent>)
    4: checkLVal [c:\dev\FitRockApp\node_modules\acorn\dist\acorn.js:1749] [bytecode=0000036F39CCC539 offset=325](this=0000016629E387F9 <Parser map = 000...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node_module_register
 2: v8::internal::FatalProcessOutOfMemory
 3: v8::internal::FatalProcessOutOfMemory
 4: v8::internal::Factory::NewTransitionArray
 5: v8::internal::EhFrameIterator::DecodeSLeb128
 6: v8::internal::JSReceiver::GetOwnPropertyDescriptor
 7: v8::internal::JSReceiver::GetOwnPropertyDescriptor
 8: v8::internal::JSReceiver::GetOwnPropertyDescriptor
 9: v8::internal::JSReceiver::class_name
10: v8::internal::JSReceiver::GetOwnPropertyDescriptor
11: v8::internal::LookupIterator::PrepareTransitionToDataProperty
12: v8::internal::JSReceiver::class_name
13: v8::internal::ParserBase<v8::internal::Parser>::MarkLoopVariableAsAssigned
14: v8::internal::ParserBase<v8::internal::Parser>::MarkLoopVariableAsAssigned
15: 000000DA23D847A1

¿Alguna idea de cómo solucionarlos? Funciona bien cuando aot está deshabilitado.

@Enngage
Puede reemplazar esta línea:
''
ng serve myapp --prod
`` ``
con una de las siguientes alternativas

Alternativa 1:
Cree esta entrada de script npm:

"ng-high-mem": "node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng",

A continuación, puede escribir en su consola:

npm run ng-high-mem -- serve myapp --prod

Alternativa 2:
Ejecuta esto en la consola:

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

Gracias @Koslun por este ejemplo completo. ¡Fui con el primer enfoque y funciona bien! Tengo curiosidad por saber por qué esto no se menciona en ninguna parte de los documentos. Esto parece que cualquier proyecto de tamaño razonable tendría que funcionar de todos modos.

@Enngage cree que es porque el objetivo es que esto nunca se suponga que suceda realmente. Donde tener que usar esto a menudo también puede ser el resultado de alguna regresión en angular-cli, Webpack o incluso Node, como esta regresión fija pero inédita en Node: https://github.com/nodejs/node/issues/19769 .

Dado que este problema en sí tiene la etiqueta de preguntas frecuentes y el tráfico que se obtiene, estoy de acuerdo en que podría valer la pena agregarlo a algunas preguntas frecuentes en la documentación.

Tengo el mismo problema y sudo node --max-old-space-size=4096 /usr/local/bin/ionic cordova build android --prod no ayudó. Estoy usando MacOs. Algún consejo ?

Estoy siguiendo de esta manera: inspeccione los paquetes y tengo el mismo error:
"devDependencies": { "@angular/cli": "^1.7.2", "@angular/compiler-cli": "^5.2.9",

ng build --prod --sourcemaps
92% de optimización de fragmentos de activos
<--- Últimos GC --->
[6360: 0000000000398AE0] 1741315 ms: Mark-sweep 1399.2 (1647.1) -> 1398.3 (1648.6) MB, 1257.4 / 0.0 ms falla de asignación GC en el espacio antiguo solicitado
[6360: 0000000000398AE0] 1742847 ms: Mark-sweep 1398.3 (1648.6) -> 1398.1 (1603.1) MB, 1530.9 / 0.0 ms GC de último recurso en el espacio anterior solicitado
[6360: 0000000000398AE0] 1744175 ms: Mark-sweep 1398.1 (1603.1) -> 1398.1 (1595.1) MB, 1328.2 / 0.0 ms GC de último recurso en el espacio anterior solicitado
<--- Seguimiento de pila JS --->
==== Seguimiento de pila JS =========================================
Contexto de seguridad: 0000018821D25EE1
1: ejecutivo (esto = 00000156D3AF9AA9 >, 000003A248D4D541 3: getMatches (también conocido como getMatches) [C: \ Users \ Utente \ Desktop \ Workspace \ rebus5node_modules @ angular-devkitbuild-optimizer \ src \ purify \ purify.js: 48] [bytecode = 000003F790876209 offset = 16] (this = 000000FCE1C02311 ined>, str = 000003A248D4D54 ...
ERROR FATAL: CALL_AND_RETRY_LAST Error en la asignación: pila de JavaScript sin memoria
1: registro_módulo_nodo
2: v8 :: interno :: FatalProcessOutOfMemory
3: v8 :: interno :: FatalProcessOutOfMemory
4: v8 :: interno :: Fábrica :: NewRawTwoByteString
5: v8 :: interno :: Smi :: SmiPrint
6: v8 :: internal :: AllocationSpaceName
7: v8 :: interno :: RegExpImpl :: Exec
8: v8 :: interno :: RegExpImpl :: Exec
9: v8 :: internal :: ParserBase <: internal :: parser i = "32"> :: MarkLoopVariableAsAssigned
10: 00000231754047A1

@lippomano Prueba esto . Resolvió el problema.

Mi versión angular es 5.1.1
Versión de nodo: 8
Versión Npm: 5

He probado estos comandos para la compilación AOT aunque obtengo este montón de ERROR

1. ng build --prod
2. ng build --aot
3. "build": "node --max_old_space_size = 5048 ./node_modules/@angular/cli/bin/ng build --prod", [también he jugado alrededor del tamaño]

¿Puede alguien que sepa cómo solucionar este error?

Tuve el mismo problema y la única forma en que lo resolví es usar esta bandera: --build-optimizer=false

@Marudhuraj Además de desactivar el optimizador de compilación, desactivar los mapas de origen también puede ayudar. De lo contrario, también recomendaría en general actualizar a la última versión angular-cli para obtener el mejor rendimiento y asegurarse de que está en la versión de Nodo 8.11.2 o superior, ya que hay una regresión de rendimiento que afecta las compilaciones de Webpack de algunas versiones por debajo de la 8.x serie.

@joshuwhi @Koslun Mi experiencia personal fue que me encontré con este problema después de 5 o más compilaciones consecutivas de la misma aplicación en un agente de Team City. Tengo la oportunidad de configurar mi CI en los últimos Node, NPM y Angular, y encontraré algo de tiempo durante la próxima semana para configurar solo la creación de nuevas aplicaciones repetitivas periódicamente a lo largo del día para ver si el entorno de desarrollo sugerido las versiones mencionadas aquí ya no reproducen el problema.

@Marudhuraj
Resolví este problema realizando el siguiente paso:

1. Usé el comando "npm run build" que internamente usa "ng build"

2. Actualizo mi archivo "ng.cmd" en la siguiente ubicación "\ UInode_modules.bin" (la interfaz de usuario es la carpeta del proyecto) mediante este código

@IF EXISTE "% ~ dp0node.exe" (
"% ~ dp0node.exe" --max_old_space_size = 8192 "% ~ dp0 .. @ angular \ cli \ binng"% *
) DEMÁS (
@SETLOCAL
@SET PATHEXT =% PATHEXT:;. JS; =;%
nodo --max_old_space_size = 8192 "% ~ dp0 .. @ angular \ cli \ binng"% *

)

esto es básicamente agregar más memoria para que el nodo se ejecute

1. Actualice el archivo package.json siguiendo los siguientes pasos:
   reemplazar
   "build": "ng build",
   por esto:
   "build": "ng build --prod --build-optimizer",

Gracias
Vijay

Hola @aryavijay ,
Ahora recibo este error, cómo resolver el error de fábrica del módulo de la aplicación

ERROR en ./src/app/app.module.ngfactory.js
Módulo no encontrado: Error: No se puede resolver 'ngx-store / dist / src / service / local-storage.service' en 'C: \ Users \ a811891 \ taskmanagementv2ui \ src \ app' resolve 'ngx-store / dist / src / service / local-storage.service 'en' C: \ Users \ a811891 \ taskmanagementv2ui \ src \ app 'La solicitud analizada es un módulo que usa el archivo de descripción: C: \ Users \ a811891 \ taskmanagementv2uipackage.json (ruta relativa: ./ src / app) El campo 'navegador' no contiene una configuración de alias válida después de usar el archivo de descripción: C: \ Users \ a811891 \ taskmanagementv2uipackage.json (ruta relativa: ./src/app) se resuelve como módulo C: \ Users \ a811891 \ taskmanagementv2ui \ src \ appnode_modules no existe o no es un directorio C: \ Users \ a811891 \ taskmanagementv2ui \ srcnode_modules no existe o no es un directorio C: \ Users \ a811891node_modules no existe o no es un directorio C : \ Usersnode_modules no existe o no es un directorio C: node_modules no existe o no es un directorio que busca módulos en C: \ Users \ a811891 \ taskmanagementv2uinode_modules usando la descripción fi le: C: \ Users \ a811891 \ taskmanagementv2uipackage.json (ruta relativa: ./node_modules) El campo 'navegador' no contiene una configuración de alias válida después de usar el archivo de descripción: C: \ Users \ a811891 \ taskmanagementv2uipackage.json (ruta relativa : ./node_modules) usando el archivo de descripción: C: \ Users \ a811891 \ taskmanagementv2uinode_modulesngx-storepackage.json (ruta relativa: ./dist/src/service/local-storage.service) sin extensión El campo 'navegador' no contiene una configuración de alias válida C: \ Users \ a811891 \ taskmanagementv2uinode_modulesngx-store \ dist \ src \ service \ local-storage.service no existe .ts

Soy un novato, pero esto resolvió mi problema

En lugar de:
ng build --prod

Escribí:
ng build --env prod

Y funcionó...

Por favor, infórmeme si esta respuesta no es buena y por qué para que pueda ampliar mis conocimientos :)
Gracias.

@yaadm Creo que --env solo establece el archivo environment.ts, no establece todas las demás configuraciones del modo de producción que --prod establece.

Con Angular 6, el tiempo de construcción aumentó de 600 segundos a 900: decepcionado:

Tengo el mismo problema.

ng build --configuration=production

con una configuración de producción que se ve así

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

falla con

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

Pero poner la bandera: --max_old_space_size = 8192 lo hace funcionar.

node --max_old_space_size=8192 ./node_modules/@angular/cli/bin/ng build --configuration=production

Versión de nodo: v8.11.3
Versión de Npm: 6.3.0

alguna solución a esto? ....

leer mi comentario o compartir la pantalla .....

@aryavijay Siento que configurar max_old_space_size en varios lugares no es realmente una solución, sino más bien una solución.
Esto no fue un problema antes de actualizar el proyecto y cli a angular 6.

Tengo el mismo problema, pero solo ocurre si tengo "sourceMap": true, en angular.json ; de lo contrario, se construye bien.

También me encontré con este problema después de actualizar a v6. Estaba funcionando bien antes. ):

¿Alguien más tiene problemas con la compilación en 79% ModuleConcatenationPlugin? Lleva mucho tiempo y mucha memoria.

Este problema nos impide actualizar @angular-devkit/build-angular de 0,6 a 0,7 o 0,8.

Lo que es aún peor, todas las soluciones alternativas mencionadas ( buildOptimizer: false , sourceMap: false , --max_old_space_size=8192 ) no funcionan para nuestro proyecto.

En "@angular-devkit/build-angular": "0.6.3" todo funciona bien.

Construyo y sirvo exitosamente con

node --max_old_space_size = 8192 node_modules / @ angular / cli / bin / ng serve --aot

pero cuando abro mi navegador me sale un error

ERROR Error: No detectado (en promesa): Error: No se puede encontrar el módulo 'app / pages / login / login.module'.
Error: no se puede encontrar el módulo 'app / pages / login / login.module'

con esta versión
CLI angular: 1.5.2
Nodo: 6.10.3
@ angular / .DS_Store: error
@ angular / cdk: 5.2.5
@ angular / cli: 1.5.2
@ angular-devkit / build-optimizer: 0.0.42
@ angular-devkit / core: 0.8.1
@ angular-devkit / schematics: 0.0.52
@ ngtools / json-schema: 1.1.0
@ ngtools / paquete web: 1.8.2
@ esquemas / angular: 0.1.17
mecanografiado: 2.4.2
paquete web: 3.8.1

Estoy cansado de cambiar la URL en los módulos y cambiar las versiones en las últimas 48 horas. por favor, ayúdame.

@iyashiyas, su problema parece no estar relacionado con problemas de memoria.

@iyashiyas, su problema parece no estar relacionado con problemas de memoria.

sin nodo --max_old_space_size = 8192 estoy obteniendo
error montón de JavaScript sin memoria

@iyashiyas sí, así que la solución funciona bien en su caso y el error "No se puede encontrar el módulo" no tiene nada que ver con esto.

Ejecute el comando a través de Node.js. Eso solucionó mi problema.

Para cualquiera que experimente un "montón de JavaScript sin memoria" al ejecutar una compilación:

Acabo de actualizar a Angular 6 desde 5 hoy y comencé a obtenerlos cuando construí mi servidor universal. Estaba en @ nagular-devkit / angular-build: 0.8.0-rc8 y seguía fallando. La degradación a 0.6.3 funcionó según: https://github.com/angular/angular-cli/issues/5618#issuecomment -419736226

@filipesilva ¿ Alguna forma de depuración para que averigüemos qué archivos grandes causan un gran uso de memoria?

Este problema se solucionó _- al menos para nuestro proyecto -_ en Angular 7.0.0-rc.0 . Supongo que la CLI consume menos memoria en esa versión ...

Si todavía está en Angular 6 y usa Docker:

RUN node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build -- configuration=${NG_CONFIGURATION};

Esto funcionó para el proyecto de mi equipo. Podemos considerar usar 4096 o incluso 2048 si eso funciona para nosotros.

@jiminikiz Puede verificar cuánta memoria toma el proceso de compilación para determinar cuánta memoria necesita asignarle.

Por ejemplo, si el proceso toma un máximo de 3 GB de RAM, puede asignar 4 GB en lugar de los 8 GB que está asignando ahora.

Hola tios,

Estoy trabajando en una aplicación que se está desarrollando con Visual Studio. ¿Cómo puedo configurar --max_old_space_size = 8192 y dónde?

Estoy publicando el proyecto con la opción de publicar, así que no sé dónde configurarlo.

¿Alguna ayuda por favor?

ps si comento

"aot": true

(y "buildOptimizer": verdadero porque depende de aot) Puedo publicar el proyecto.

antes de que me enfrente a un problema con el montón de Java sin memoria
y ejecuto código con memoria creciente pero fallé con el error del módulo.
y actualicé a angular 6 y construí con éxito con el modo --prod

node --max_old_space_size = 8192 'módulos_nodo / @ angular / cli / bin / ng' build --prod

De lo contrario, puede configurar su angular.json
"build-prod": "node --max_old_space_size = 8192 'node_modules / @ angular / cli / bin / ng' build --prod",

y llame a build-prod en su comando

ahora estoy usando --prod tiene más poder completo que no sea aot

Hola tios,

Estoy trabajando en una aplicación que se está desarrollando con Visual Studio. ¿Cómo puedo configurar --max_old_space_size = 8192 y dónde?

Estoy publicando el proyecto con la opción de publicar, así que no sé dónde configurarlo.

¿Alguna ayuda por favor?

ps si comento

"aot": true

(y "buildOptimizer": verdadero porque depende de aot) Puedo publicar el proyecto.

Quiero probar mi versión prod con

"serve-prod": "ng serve --prod --build-optimizer",

¿Dónde puedo agregar --max_old_space_size = 819 porque ahora mismo estoy obteniendo

The option '--max_old_space_size' is not registered with the serve command. Run `ng serve --help` for a list of supported options.

Realmente necesito ayuda

Gracias

¿No te funciona esto?
node --max_old_space_size = 8192 'node_modules / @ angular / cli / bin / ng' build --prod --build-optimizer

El argumento --max_old_space_size es para nodo, no ng

Solo quiero resaltar algo que dije en https://github.com/angular/angular-cli/issues/6795#issuecomment -416623841 porque felizmente aquí también:

Aumentar el límite de memoria no es un truco, y es algo que debe esperar hacer en algún momento. Los procesos de nodo tienen un límite de memoria predeterminado de aproximadamente 1,7 gigas. Cuando un proceso de nodo comienza a acercarse al límite de memoria, necesita dedicar más y más tiempo a la recolección de basura para liberar memoria, lo que a su vez hace que se ejecute más lentamente.

Los proyectos más grandes utilizarán más memoria que los proyectos más pequeños, por lo que en algún momento un proyecto alcanzará el límite de memoria. Yo personalmente uso un script npm para esto:

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

Es difícil actuar sobre muchos de estos informes, ya que no existe una reproducción objetiva que podamos seguir. No es que no creamos que las compilaciones pueden ser lentas. Pero las compilaciones pueden ser lentas por muchas razones. Es muy probable que los proyectos que están experimentando los tiempos de compilación más dramáticos estén sufriendo algún problema extraño en algún lugar de la tubería que no sea un problema general, y para aquellos que realmente necesitamos reproducirlo para solucionarlo.

Por supuesto, las mejoras generales en el rendimiento siempre son útiles y tratamos de hacerlas tanto como sea posible. Pero la mejor manera de conseguir que solucionemos los problemas, especialmente los difíciles de solucionar, es ofrecer repros concretos.

@filipesilva todo el mundo dice que tenemos que usar "hack" y soluciones, pero no dónde podemos poner eso en un archivo de publicación automatizado.

¿Podemos usar eso en angular.json y dónde?

este es mi angular.json ahora mismo:

{
  "$schema": "./node_modules/@angular/cli/lib/config/schema.json",
  "version": 1,
  "newProjectRoot": "projects",
  "projects": {
    "ClientApp": {
      "root": "",
      "sourceRoot": "src",
      "projectType": "application",
      "prefix": "app",
      "schematics": {},
      "targets": {
        "build": {
          "builder": "@angular-devkit/build-angular:browser",
          "options": {
            "outputPath": "dist",
            "index": "src/index.html",
            "main": "src/main.ts",
            "polyfills": "src/polyfills.ts",
            "tsConfig": "src/tsconfig.app.json",
            "assets": [
              "src/favicon.ico",
              "src/assets"
            ],
            "styles": [
              "src/styles.css"
            ],
            "scripts": []
          },
          "configurations": {
            "production": {
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.prod.ts"
                }
              ],
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "extractCss": true,
              "namedChunks": false,
              //"aot": true,
              "extractLicenses": true,
              "vendorChunk": false,
              //"buildOptimizer": true
            }
          }
        },
        "serve": {
          "builder": "@angular-devkit/build-angular:dev-server",
          "options": {
            "browserTarget": "ClientApp:build"
          },
          "configurations": {
            "production": {
              "browserTarget": "ClientApp:build:production"
            }
          }
        },
        "extract-i18n": {
          "builder": "@angular-devkit/build-angular:extract-i18n",
          "options": {
            "browserTarget": "ClientApp:build"
          }
        },
        "test": {
          "builder": "@angular-devkit/build-angular:karma",
          "options": {
            "main": "src/test.ts",
            "polyfills": "src/polyfills.ts",
            "tsConfig": "src/tsconfig.spec.json",
            "karmaConfig": "src/karma.conf.js",
            "styles": [
              "src/styles.css"
            ],
            "scripts": [],
            "assets": [
              "src/favicon.ico",
              "src/assets"
            ]
          }
        },
        "lint": {
          "builder": "@angular-devkit/build-angular:tslint",
          "options": {
            "tsConfig": [
              "src/tsconfig.app.json",
              "src/tsconfig.spec.json"
            ],
            "exclude": [
              "**/node_modules/**"
            ]
          }
        }
      }
    },
    "ClientApp-e2e": {
      "root": "e2e/",
      "projectType": "application",
      "targets": {
        "e2e": {
          "builder": "@angular-devkit/build-angular:protractor",
          "options": {
            "protractorConfig": "e2e/protractor.conf.js",
            "devServerTarget": "ClientApp:serve"
          },
          "configurations": {
            "production": {
              "devServerTarget": "ClientApp:serve:production"
            }
          }
        },
        "lint": {
          "builder": "@angular-devkit/build-angular:tslint",
          "options": {
            "tsConfig": "e2e/tsconfig.e2e.json",
            "exclude": [
              "**/node_modules/**"
            ]
          }
        }
      }
    }
  },
  "defaultProject": "ClientApp"
}

¿Dónde puedo poner eso para que se construya?

Muchísimas gracias.

@dobrinsky, el ejemplo de código que mostré fue un script npm . Esos scripts van al archivo package.json , debajo de la clave scripts :

{
  "name": "my-project",
  "version": "0.0.0",
  "scripts": {
    "ng-high-memory": "node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng",
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },

Cuando usa have ese script, puede usar npm run ng-high-memory -- seguido de los argumentos en lugar de ng dentro de ese proyecto. Utilice siempre el guión doble antes de los argumentos, de lo contrario, es posible que no se analicen correctamente.

Muchas gracias @filipesilva

Todavía no funcionará

0 info it worked if it ends with ok
1 verbose cli [ 'C:\\Program Files\\nodejs\\node.exe',
1 verbose cli   'C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js',
1 verbose cli   'run',
1 verbose cli   'build',
1 verbose cli   '--',
1 verbose cli   '--prod' ]
2 info using [email protected]
3 info using [email protected]
4 verbose run-script [ 'prebuild', 'build', 'postbuild' ]
5 info lifecycle [email protected]~prebuild: [email protected]
6 info lifecycle [email protected]~build: [email protected]
7 verbose lifecycle [email protected]~build: unsafe-perm in lifecycle true
8 verbose lifecycle [email protected]~build: PATH: C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin;C:\Users\Andrei\PROJECTS\Angular 6\SIGAD\SIGAD\ClientApp\node_modules\.bin;C:\Python34\;C:\Python34\Scripts;C:\Users\Andrei\algs4\java\bin;C:\ProgramData\Oracle\Java\javapath;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Users\Andrei\.dnx\bin;C:\Program Files\Microsoft DNX\Dnvm\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files (x86)\MiKTeX 2.9\miktex\bin\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\;C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files\MATLAB\R2016a\runtime\win64;C:\Program Files\MATLAB\R2016a\bin;C:\Program Files\MATLAB\R2016a\polyspace\bin;C:\Program Files (x86)\Microsoft Emulator Manager\1.0\;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files\Common Files\Autodesk Shared\;C:\Program Files\dotnet\;C:\Program Files (x86)\GtkSharp\2.12\bin;C:\Program Files (x86)\Skype\Phone\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\dotnet\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\nodejs\;C:\Program Files (x86)\Microsoft VS Code\bin;C:\Program Files\Git\cmd;C:\Users\Andrei\algs4\bin;C:\Users\Andrei\AppData\Local\Microsoft\WindowsApps;C:\Users\Andrei\AppData\Local\GitHubDesktop\bin;C:\Users\Andrei\AppData\Roaming\npm;C:\Users\Andrei\.dotnet\tools;%USERPROFILE%\AppData\Local\Microsoft\WindowsApps;C:\Users\Andrei\.nuget\packages\nuget.commandline\4.6.2\tools;C:\Users\Andrei\.nuget\packages\microsoft.codeanalysis.analyzers\1.1.0\tools;C:\Users\Andrei\.nuget\packages\microsoft.entityframeworkcore.tools\2.1.3\tools;C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.razor.design\2.1.1\tools;C:\Users\Andrei\.nuget\packages\microsoft.applicationinsights.windowsserver\2.7.2\tools
9 verbose lifecycle [email protected]~build: CWD: C:\Users\Andrei\PROJECTS\Angular 6\SIGAD\SIGAD\ClientApp
10 silly lifecycle [email protected]~build: Args: [ '/d /s /c', 'ng build "--prod"' ]
11 silly lifecycle [email protected]~build: Returned: code: 134  signal: null
12 info lifecycle [email protected]~build: Failed to exec build script
13 verbose stack Error: [email protected] build: `ng build "--prod"`
13 verbose stack Exit status 134
13 verbose stack     at EventEmitter.<anonymous> (C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\index.js:301:16)
13 verbose stack     at EventEmitter.emit (events.js:182:13)
13 verbose stack     at ChildProcess.<anonymous> (C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\lib\spawn.js:55:14)
13 verbose stack     at ChildProcess.emit (events.js:182:13)
13 verbose stack     at maybeClose (internal/child_process.js:962:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:251:5)
14 verbose pkgid [email protected]
15 verbose cwd C:\Users\Andrei\PROJECTS\Angular 6\SIGAD\SIGAD\ClientApp
16 verbose Windows_NT 10.0.17763
17 verbose argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "run" "build" "--" "--prod"
18 verbose node v10.10.0
19 verbose npm  v6.4.1
20 error code ELIFECYCLE
21 error errno 134
22 error [email protected] build: `ng build "--prod"`
22 error Exit status 134
23 error Failed at the [email protected] build script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 134, true ]

Comencé a ver esto en mi servidor Azure DevOps Build después de actualizar a Angular 7.

Agregar lo siguiente a package.json y luego llamarlo desde mi tarea de compilación lo solucionó.

"build-prod": "node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng build --prod

Si tiene este problema con la biblioteca quagga js, preste atención a que "@ angular / service-worker" esté instalado antes del paquete "quagga": "^ 0.12.1".

podría ejecutar optimizacionesjs usando node --max-old-space-size=8192 ./node_modules/@ionic/app-scripts/bin/ionic-app-scripts.js build --release --prod --minifyjs --minifycss --optimizejs

Para las personas que extrañaron a @dakotamurphyucf como lo hice yo:
usar el paquete increase-memory-limit después de ejecutar npm install reducirá toda la necesidad de saber dónde están los archivos binarios y lo hará para todos los archivos, lo que en mi caso es muy útil ya que estoy ejecutando tanto la compilación regular como la compilación cordova.
Lo estoy usando solo en mi script de compilación de CI, ya que localmente funciona bien.
básicamente: npm install increase-memory-limit -g
Y ejecute el comando increase-memory-limit .
¡El dolor se ha ido! No más sufrimiento (al menos para mí) ...

O simplemente use export NODE_OPTIONS=--max_old_space_size=4096 que también debería solucionarlo.

@marcj esta solución funcionó para mí.

Configuré NODE_OPTIONS para Windows con el siguiente comando:
set NODE_OPTIONS=--max_old_space_size=4096

La instalación de aumento de límite de memoria no funcionó para mí en Windows. No lo he probado en linux / ubuntu u otro sistema operativo.

@jatinderkumargupta Tenga en cuenta que no es suficiente instalar increase-memory-limit , debe ejecutarlo también después de que se haya completado la instalación de npm de todos los paquetes. Estoy usando Windows y funcionó para mí.

Gracias @HarelM , lo ejecuto como mencionaste, pero no funcionó para mí. Entonces puede haber algún otro problema.

En Azure Devops agregué una tarea de línea de comando que ejecuta el comando a continuación antes de la compilación ng:

nodo --max-antiguo-espacio-tamaño = 8192

Esto parece haber resuelto el problema por ahora.

"build-prod": "nodo --max_old_space_size = 8000 ./node_modules/@angular/cli/bin/ng build --prod

@ImranAhmed gracias por la sugerencia. Sin embargo, ¿dónde lo agrega en angular.json? Si lo agrego, obtengo un 'Producto de construcción de propiedad' no permitido.

@bkarv

Agréguelo a package.json en la sección 'scripts', no a angular.json.

Si tiene el problema con su compilación de Azure DevOps, puede llamar a este nuevo comando de secuencia de comandos que acaba de agregar desde su tarea de compilación de AzureDevops.

Probé scripts pero obtuve errores. Terminé siguiendo la sugerencia de exportar NODE_OPTIONS en OS y funcionó. Muchas gracias

Hola a todos,

Este hilo se abrió hace un tiempo y con el tiempo han surgido y resuelto nuevos problemas de memoria. Mientras tanto, muchos informes siguen apareciendo aquí como comentarios.

Tener todos los comentarios en un solo hilo hace que sea difícil obtener informes significativos o informar a las personas de qué versiones se corrigieron las regresiones que les afectan.

En el momento de escribir este artículo, hay 450 comentarios ocultos:

Tener tantos comentarios ocultos dificulta que las personas encuentren información en cualquier cosa que no sean los últimos comentarios. Pero, por otro lado, no creo que la mayoría de la gente lea todos los comentarios de todos modos. Los nuevos usuarios que ven este hilo en su mayoría leen los primeros y últimos comentarios y pierden lo que se dice en el medio.

Entonces, por las razones mencionadas anteriormente (gran volumen de comentarios, comentarios ocultos, difícil de informar e informar a las personas) también estoy bloqueando este problema para evitar que este comentario se pierda a medida que ingresan nuevos comentarios.

Gracias a todos los que informaron y ayudaron a diagnosticar estos problemas de memoria. Si encuentra alguno nuevo, abra un nuevo problema para que podamos prestar toda nuestra atención a esa regresión específica y brindarle una solución.

Así que me gustaría dejar el último comentario en este hilo como reiterando lo que dije en https://github.com/angular/angular-cli/issues/5618#issuecomment -431310735, ya que creo que eso es lo que más ayudará. personas que encuentran este problema:

Aumentar el límite de memoria no es un truco, y es algo que debe esperar hacer en algún momento. Los procesos de nodo tienen un límite de memoria predeterminado de aproximadamente 1,7 gigas. Cuando un proceso de nodo comienza a acercarse al límite de memoria, necesita dedicar más y más tiempo a la recolección de basura para liberar memoria, lo que a su vez hace que se ejecute más lentamente.

Los proyectos más grandes utilizarán más memoria que los proyectos más pequeños, por lo que en algún momento un proyecto alcanzará el límite de memoria. Yo personalmente uso un script npm para esto:

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

Los scripts npm van al archivo package.json , debajo de la clave scripts :

{
  "name": "my-project",
  "version": "0.0.0",
  "scripts": {
    "ng-high-memory": "node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng",
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },

Cuando usa have ese script, puede usar npm run ng-high-memory -- seguido de los argumentos en lugar de ng dentro de ese proyecto. Utilice siempre el guión doble antes de los argumentos, de lo contrario, es posible que no se analicen correctamente.