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

Parece que aumentamos explícitamente la memoria asignable de Node de 500M a 2G. Posiblemente, esto sea un paso demasiado grande y 1.5G sería mejor:

Vale la pena señalar que Ember no es lo único que se ejecuta en la máquina, y estamos al límite global de RAM + swap. Por lo tanto, el historial de la máquina y las necesidades de todos los demás procesos en ejecución entran en juego. Mi reinicio podría haber ayudado aquí a alcanzar una marca de agua más baja en comparación con ayer.

La solicitud de extracción anterior se mencionó en
No se pudo actualizar la instancia de Discourse al 15 de febrero de 2022
donde también notamos que alguien tuvo una escasez de memoria que se resolvió con un reinicio.

Es una lástima que el comando time no informe el uso máximo de memoria. Posiblemente, en una máquina con al menos 3G de RAM y sin swap, el recuento de RSS nos diría el uso máximo de Ember. O posiblemente podríamos usar otra táctica: varias se describen aquí y hay algunas ideas aquí también.

Lo que es incómodo es que realmente estamos interesados en el uso de memoria aquí, mientras que en muchos casos las personas están interesadas en el uso de RAM, que es una pregunta diferente.

3 Me gusta