La razón por la que añadimos esa bandera fue que el propio asesino de OOM de Node estaba matando la compilación; 500M no era suficiente. Estaré encantado de intentar ajustarlo a 1.5G. Acabo de probarlo en mi droplet y parece que funciona bien. De hecho, parece que incluso 1.0G es suficiente.
Intenté rastrear el uso de memoria con diferentes tamaños de max_heap:
(while(true); do (free -m -t | grep Total | awk '{print $3}') && sleep 0.5; done) | tee 1000mb.csv
Muestra este uso durante la compilación:
Hubo muy poca diferencia en el tiempo de compilación, pero los límites de 1GB y 1.5GB claramente producen un menor uso general. Como se esperaba, la salida de time muestra significativamente menos “Fallos de página importantes” cuando el límite de Node es menor.
Es curioso que la diferencia entre 1.5GB y 1GB sea tan pequeña… ![]()
En cualquier caso, estoy de acuerdo en que disminuir el límite es una buena idea. Para asegurarnos de que no afecte el rendimiento de la compilación en máquinas con especificaciones más altas, creo que solo deberíamos anular el límite cuando sepamos que es demasiado bajo. De lo contrario, podemos dejar que Node use su valor predeterminado.
Aquí hay una PR: intentaremos fusionarla pronto. ¡Gracias por plantear esto @Ed_S!
