El uso de memoria en la compilación de Ember-cli corre el riesgo de fallar (OOM) en el tamaño mínimo de instancia

Gracias @david, aprecio que Ember sea algo en sí mismo.

Acabo de ejecutar esos comandos.

# /var/discourse/launcher enter app
Se detectó la arquitectura x86_64.

ADVERTENCIA: Vamos a empezar a descargar la imagen base de Discourse
Este proceso puede tardar entre unos minutos y una hora, dependiendo de la velocidad de tu red

Por favor, ten paciencia

2.0.20220720-0049: Tirando de discourse/base
Digest: sha256:7ff397003c78b64c9131726756014710e2e67568fbc88daad846d2b368a02364
Estado: Imagen más nueva descargada para discourse/base:2.0.20220720-0049
docker.io/discourse/base:2.0.20220720-0049

Esta es una instalación de producción, por lo que, hasta ayer, estaba actualizada. Actualmente informa:

Instalado 2.9.0.beta12 (8f5936871c)

Es una instancia de un solo CPU, como la tuya, tiene 1 GB de RAM y 2 GB de swap.

El resultado del comando time fue

Hecho en 303.21s.

	Comando que se está cronometrando: "yarn ember build -prod"
	Tiempo de usuario (segundos): 222.71
	Tiempo de sistema (segundos): 17.17
	Porcentaje de CPU que obtuvo este trabajo: 78%
	Tiempo transcurrido (reloj de pared) (h:mm:ss o m:ss): 5:04.15
	Tamaño promedio de texto compartido (kbytes): 0
	Tamaño promedio de datos no compartidos (kbytes): 0
	Tamaño promedio de pila (kbytes): 0
	Tamaño total promedio (kbytes): 0
	Tamaño máximo del conjunto residente (kbytes): 702292
	Tamaño promedio del conjunto residente (kbytes): 0
	Fallos de página importantes (que requieren E/S): 348190
	Fallos de página menores (recuperando un marco): 1152689
	Cambios de contexto voluntarios: 617736
	Cambios de contexto involuntarios: 774189
	Swaps: 0
	Entradas del sistema de archivos: 5001936
	Salidas del sistema de archivos: 318280
	Mensajes de socket enviados: 0
	Mensajes de socket recibidos: 0
	Señales entregadas: 0
	Tamaño de página (bytes): 4096
	Estado de salida: 0

Inmediatamente antes, había actualizado el host y reiniciado, por lo que todo en el contenedor se habría reiniciado recientemente.

El peor uso de memoria, según lo informado por un vmstat ejecutándose en otra ventana:

# vmstat 1
procs  -----------memory----------    ---swap--  -----io----   -system-- ------cpu-----\n r  b    swpd   free   buff  cache    si     so    bi     bo    in    cs us sy id wa st\n 2  0  704000 136044  24136 158144  1517   3503  8256   4377   886  3564 43  8 43  6  0\n...\n 5  0 1451436  71604   1248  50196 55016 110236 73204 121060 13152 45971 29 60  0 10  1\n