Ho informazioni aggiuntive nel caso in cui aiutino a mitigare il problema dal lato di Discourse. La mia istanza (DigitalOcean ~1GB droplet con 2GB di swap) ha recentemente iniziato a impiegare molto più tempo per ricostruire e segnalare lo stesso errore fatale circa 3 volte su 4 (la fortuna sembra migliorare dopo aver eseguito ./launcher cleanup, ma non ho abbastanza campioni per confermarlo).
Poco prima dell’errore di heap out of memory, vengono registrate queste righe:
Node.js heap_size_limit (491.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (491.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.
Sono fuori dal mio campo, quindi mi scuso se sbaglio qualcosa. Alcune ricerche rapide indicano che ember-cli dipende da node.js, motivo per cui penso che questo sia rilevante. Il flag --max-old-space-size può potenzialmente essere impostato più in alto della RAM (andrebbe semplicemente nello spazio di swap, che come menzionato va bene in questo caso), quindi forse 1024 è un soffitto artificiale che stiamo colpendo e che le ricostruzioni di Discourse non possono più contenere.
Note a margine: apparentemente --optimize-for-size è un flag di node.js che aiuta a ridurre l’utilizzo della memoria (non sono sicuro se sia utilizzato da Discourse/ember, forse lo è già), e c’è un aneddoto in giro sul garbage collector che non viene attivato per certi usi di node.js, il che potrebbe essere un problema.
Se qualcosa di tutto ciò è rilevante e controllabile dal lato Discourse dell’utilizzo di ember/node.js, potrebbe valere la pena che qualcuno ci dia un’occhiata. Altrimenti, nessun problema, adotterò la soluzione temporanea di aggiornamento a 2GB proposta sopra. 