Uso de memória do build do Ember-cli arrisca falha (OOM) no tamanho mínimo da instância

O motivo pelo qual adicionamos essa flag foi que o próprio OOM killer do Node estava matando a compilação - 500M não era suficiente. Ficarei feliz em tentar ajustá-lo para 1.5G - acabei de tentar no meu droplet e parece funcionar bem. Na verdade, parece que até 1.0G é suficiente.

Tentei rastrear o uso de memória com diferentes tamanhos de max_heap:

(while(true); do (free -m -t | grep Total | awk '{print $3}') && sleep 0.5; done) | tee 1000mb.csv

Mostra este uso durante a compilação:

Houve muito pouca diferença no tempo de compilação, mas os limites de 1GB e 1.5GB claramente produzem menos uso geral. Como esperado, a saída do time mostra significativamente menos “Falhas de página principais” quando o limite do Node é menor.

É curioso que a diferença entre 1.5GB e 1GB seja tão pequena… :face_with_monocle:

De qualquer forma, concordo que diminuir o limite é uma boa ideia. Para garantir que isso não afete o desempenho da compilação em máquinas com especificações mais altas, acho que devemos substituir o limite apenas quando soubermos que ele é muito baixo. Caso contrário, podemos deixar o Node usar o padrão.

Aqui está um PR - tentaremos mesclá-lo em breve. Obrigado por levantar isso, @Ed_S!

4 curtidas