Esto parece menos un problema de pnpm o Ember y más que el host simplemente se está quedando sin memoria.
El detalle clave es la SIGKILL. Eso generalmente significa que el sistema operativo intervino y mató el proceso (a menudo a través del asesino OOM), no que ember build -prod falló por sí mismo.
En hosts pequeños, las compilaciones de producción de Ember pueden alcanzar fácilmente un par de GB de RAM. Incluso con el intercambio (swap) habilitado, una vez que el intercambio está mayormente utilizado, el kernel aún puede decidir matar un proceso node hambriento de memoria.
Algunas cosas que apuntan en esta dirección:
- El intercambio ya se está utilizando mucho cuando ocurre el fallo.
- El fallo es mucho más probable cuando otro contenedor se está ejecutando al mismo tiempo.
- Si detengo el otro contenedor antes de ejecutar el arranque, la misma compilación tiene éxito.
Así que el intercambio ayuda un poco, pero principalmente solo retrasa el problema. Detener otros contenedores reduce la presión de memoria lo suficiente para que la compilación finalice.
Lo que ayudó / podría ayudar:
- Evitar ejecutar múltiples arranques o compilaciones de activos en paralelo.
- Detener otros contenedores durante
ember build -prod. - Limitar el uso de memoria de Node (por ejemplo,
NODE_OPTIONS=--max_old_space_size=1024) para reducir el uso máximo. - Si es posible, aumentar la RAM del host (4GB+) hace que esto sea mucho más confiable.
Espero que esto ayude a explicar por qué se siente un poco aleatorio y por qué detener otro contenedor hace que funcione.