如果这有助于从 Discourse 方面缓解问题，我还有一些额外信息。我的实例（DigitalOcean ~1GB 虚拟服务器，带 2GB 交换空间）最近开始重建花费的时间明显变长，并且大约有 3/4 的时间报告相同的致命错误（运行 ./launcher cleanup 后运气似乎有所改善，但我没有足够样本来确认这一点）。
在堆内存不足错误之前不久，会记录以下几行：
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.
我在这方面不太懂，所以如果我说错了什么，请原谅。一些快速研究表明 ember-cli 依赖于 node.js，这就是我认为这可能相关的原因。--max-old-space-size 标志可以设置为高于 RAM 的值（它只会进入交换空间，如前所述，在这种情况下是可以的），所以也许 1024 是我们正在遇到的一个人为上限，Discourse 重建无法再在此范围内进行。
附注：显然 --optimize-for-size 是一个 node.js 标志，有助于减少内存使用（不确定 Discourse/ember 是否已使用它，也许它已经在使用中），并且有一个说法是垃圾回收器在某些 node.js 用途中没有开启，这可能是一个问题。
如果这些信息中有任何与 Discourse 的 ember/node.js 使用方面相关且可控的，也许值得有人研究一下。如果不是，没关系，我将采用上面提出的临时升级到 2GB 的解决方案。