L'utilizzo della memoria di build di Ember-cli rischia il fallimento (OOM) sulla dimensione minima dell'istanza

Il motivo per cui abbiamo aggiunto quel flag è che l’OOM killer di Node stesso stava uccidendo la build - 500M non era abbastanza. Sono felice di provare a modificarlo a 1.5G - l’ho appena provato sul mio droplet e sembra funzionare bene. Infatti, sembra che anche 1.0G sia sufficiente.

Ho provato a tracciare l’utilizzo della memoria con diverse dimensioni di max_heap:

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

Mostra questo utilizzo durante la build:

C’è stata pochissima differenza nel tempo di build, ma i limiti di 1GB e 1.5GB producono chiaramente un minor utilizzo complessivo. Come previsto, l’output di time mostra significativamente meno “Major page faults” quando il limite di Node è inferiore.

È curioso che la differenza tra 1.5GB e 1GB sia così piccola… :face_with_monocle:

In ogni caso, sono d’accordo che diminuire il limite sia una buona idea. Per assicurarci che non influenzi le prestazioni di build su macchine con specifiche più elevate, penso che dovremmo sovrascrivere il limite solo quando sappiamo che è troppo basso. Altrimenti, possiamo lasciare che Node utilizzi il suo default.

Ecco una PR - cercheremo di farla unire presto. Grazie per averla sollevata @Ed_S!

4 Mi Piace