У меня есть дополнительная информация, которая может помочь смягчить проблему на стороне Discourse. Мой экземпляр (DigitalOcean ~1 ГБ droplet с 2 ГБ swap-памяти) недавно начал значительно дольше пересобираться и сообщать об одной и той же фатальной ошибке примерно в 3 случаях из 4 (удача, похоже, улучшается после запуска ./launcher cleanup, но у меня недостаточно данных для подтверждения этого).
Незадолго до ошибки исчерпания памяти в логах появляются следующие строки:
Node.js heap_size_limit (491.0) меньше 1024 МБ. Устанавливаем --max-old-space-size=1024.
Node.js heap_size_limit (491.0) меньше 2048 МБ. Отключаем параллелизацию Webpack с JOBS=0 для экономии памяти.
Я не эксперт в этой области, поэтому извините, если я что-то не так понял. Краткое исследование показывает, что ember-cli зависит от node.js, поэтому я считаю это важным. Флаг --max-old-space-size можно установить выше объёма оперативной памяти (в этом случае система просто будет использовать swap-память, что в данном случае приемлемо), поэтому, возможно, значение 1024 — это искусственное ограничение, которое больше не позволяет пересборкам Discourse укладываться в него.
Примечания: apparently --optimize-for-size — это флаг node.js, который помогает снизить потребление памяти (не уверен, используется ли он в Discourse/ember, возможно, уже используется), и существует anecdote о том, что сборщик мусора не включается для некоторых применений node.js, что может быть проблемой.
Если какая-либо из этих сведений актуальна и может быть управляема со стороны Discourse в части использования ember/node.js, возможно, стоит кому-то разобраться в этом. Если нет — без проблем, я воспользуюсь предложенным выше временным решением с обновлением до 2 ГБ. 