从 3.2.0.beta3-dev 升级到 3.2.0.beta3 因内存不足而失败

[andreid (Andrei Dolanescu)]

你好，

尝试从 3.2.0.beta3-dev 升级到 3.2.0.beta3 时，由于 ember 构建资源时内存不足，导致我的 Discourse 实例崩溃。尝试运行 ./launcher rebuild app 结果相同。

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb83f50 node::Abort() [ember]
 2: 0xa94834  [ember]
 3: 0xd647c0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [ember]
 4: 0xd64b67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [ember]
 5: 0xf42265  [ember]
 6: 0xf5474d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [ember]
 7: 0xf2ee4e v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [ember]
 8: 0xf30217 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [ember]
 9: 0xf113ea v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [ember]
10: 0x12d674f v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [ember]
11: 0x17035b9  [ember]
Aborted (core dumped)
error Command failed with exit code 134.
I, [2023-11-26T17:19:26.345389 #1]  INFO -- : yarn run v1.22.19
$ /var/www/discourse/app/assets/javascripts/node_modules/.bin/ember build
Environment: development
WARNING: ember-test-selectors: You are using an unsupported ember-cli-babel version. data-test properties are not automatically stripped from your JS code.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

我运行的是一个拥有 1GB 内存的 DigitalOcean 实例，用于一个非营利组织，所以我无法负担增加内存的费用。1GB 是 discourse 的最低配置，之前的版本运行都没有问题。有什么办法能让它重新运行吗？

[itsbhanusharma (Bhanu Sharma)]

您有 Swap 吗？

free -h 的输出是什么？

free -h

[andreid (Andrei Dolanescu)]

              总计       已用       可用      共享  缓冲/缓存  可用
内存：         952Mi       321Mi       414Mi       3.1Mi       374Mi       631Mi
交换空间：      2.0Gi        75Mi       1.9Gi

[RGJ (Richard - Communiteq)]

@andreid

所以我负担不起用更多内存来调整它的大小。

你只需要在重建期间调整它的大小。

[itsbhanusharma (Bhanu Sharma)]

您可能需要考虑迁移到 Hetzner，他们提供具有竞争力的价格和 2 GB RAM 的基础套餐。

[JammyDodger]

你好，欢迎你 @andreid

我最近的 1GB DO 测试站点在重建时也遇到了内存问题。我暂时升级到了 2GB，以使其能够完成。

[itsbhanusharma (Bhanu Sharma)]

也许现在值得将文档中的最低要求更新为 2GB RAM？

[JammyDodger]

我记得去年发生过类似的事情，并且做了一些调整 JavaScript heap out of memory due to Ember CLI - #4 by JammyDodger

[andreid (Andrei Dolanescu)]

谢谢 @RGJ 和 @JammyDodger，暂时调整大小解决了问题。

[Ed_S]

添加 1G 的交换空间在功能上应该与添加 1G 的内存相同，前提是您有足够的磁盘空间。 （升级运行可能需要更长时间，但这属于性能问题，而非功能问题。您希望避免的是内存不足的情况。）

[Troid92]

如果这有助于从 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 的解决方案。

[david (David Taylor)]

@Troid92

也许 1024 是一个我们正在达到的、Discourse 重建无法再包含的人工上限。

这确实是个好观点！目前我们在低内存机器上将其提高到 1024MB 在此处。我们当然可以尝试将其增加到 1500 或 2000，看看是否有帮助。

如果您有时间/意愿自己尝试，可以通过在 app.yml 文件的 env: 部分添加一个新变量来配置它：

编辑： 这现在是 Discourse 的默认设置。无需自行配置

  NODE_OPTIONS: "--max-old-space-size=2048"

[Troid92]

太好了！我已经尝试过了。

由于致命错误并非每次都会发生，而且最近重建大约需要 25 分钟（比之前的 5-10 分钟要长），所以我可能需要一些时间才能知道增加该数字是否能解决这些服务器规格的内存问题。

但是，我已经可以确认，重建日志中不再出现两个 Node.js heap_size_limit 警告，并且我的第一次重建成功了，这很有希望。

编辑：在 app.yml 中设置了上面的 NODE_OPTIONS 后，我现在已经可以成功重建几次了。太棒了！

编辑 2：这个解决方案可能应该通过增加那个神奇的数字（来自 David 的帖子链接）来集成到 Discourse 中，以便其他低内存机器能够继续运行。如果有人看到这个并且知道如何做到这一点，那就太好了。

[francislavoie]

我们也遇到了同样的问题，在 https://caddy.community 上。

我们运行了 ./launcher rebuild app 几次，但都因各种问题而失败。
首先，我们在 bundle install 时遇到了问题，它抱怨 rbtrace（最后显示 An error occurred while installing rbtrace (0.5.0), and Bundler cannot continue.）。

然后我们遇到了这个 OOM 问题：

I, [2023-12-12T07:50:59.497921 #1]  INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
Node.js heap_size_limit (1010.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (1010.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.

<--- Last few GCs --->

[3683:0x5dab130]   279104 ms: Scavenge 981.3 (1037.1) -> 974.5 (1037.1) MB, 8.3 / 0.0 ms  (average mu = 0.699, current mu = 0.681) allocation failure; 
[3683:0x5dab130]   279136 ms: Scavenge 981.8 (1037.1) -> 975.0 (1037.1) MB, 8.0 / 0.0 ms  (average mu = 0.699, current mu = 0.681) allocation failure; 
[3683:0x5dab130]   282606 ms: Mark-sweep 994.8 (1050.6) -> 987.7 (1048.9) MB, 3316.1 / 0.0 ms  (average mu = 0.593, current mu = 0.501) allocation failure; GC in old space requested


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb83f50 node::Abort() [ember]
 2: 0xa94834  [ember]
 3: 0xd647c0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [ember]
 4: 0xd64b67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [ember]
 5: 0xf42265  [ember]
 6: 0xf5474d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, [snip]
Aborted (core dumped)
error Command failed with exit code 134.

最后，通过运行 ./discourse_doctor 最终设法绕过了这个问题（但为什么呢？后续运行缓存中还有更多东西，导致内存使用更少？）

I, [2023-12-12T08:02:50.556442 #1]  INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
Node.js heap_size_limit (1010.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (1010.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.
110:M 12 Dec 2023 08:07:50.026 * 100 changes in 300 seconds. Saving...
110:M 12 Dec 2023 08:07:50.030 * Background saving started by pid 3706
3706:C 12 Dec 2023 08:07:51.292 * DB saved on disk
3706:C 12 Dec 2023 08:07:51.294 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 1 MB
110:M 12 Dec 2023 08:07:51.334 * Background saving terminated with success
Purging temp files
Bundling assets

但这是我们不应该遇到的摩擦。希望将来会有所改善。

供参考：

# free -h
              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       1.3Gi        87Mi       138Mi       593Mi       394Mi
Swap:         2.0Gi       337Mi       1.7Gi

[Falco]

@francislavoie

但这是我们本不该遇到的摩擦。

确实如此，这就是我们在此收集信息的原因。

看来，调整我们的 NODE_OPTIONS 环境变量就足够了，所以我猜想，应用程序的某个依赖项或 V8 的更改导致我们之前的值不再有效。

@david 看起来怎么样？

PERF: Update node_options during ember build for low end servers

[david (David Taylor)]

对我来说看起来不错！显然，30 分钟以上的重建仍然不理想，所以我希望我们能在不久的将来有所改进。但这似乎是止损的好办法。

[volanar]

值得注意的是，与 13 版本相比，Postgres 16 版本在空间占用更少且优化程度更高。这可以减少服务器消耗的总内存量。

Postgres versions 11, 12, 13, 14, 15, and 16 vs sysbench with a medium server

[nathank (Nathan Kershaw)]

我今天也遇到了类似的两容器重建问题（2GB + 2GB 交换空间设置），针对一个小型网站。

将其扩展到 2GB + 4GB 交换空间这次解决了问题。

[tophee (Christoph)]

FWIW，在我的例子中，添加

@david

NODE_OPTIONS: "--max-old-space-size=2048"

到 app.yml 没有帮助。有帮助的是简单地

sudo apt update
sudo apt upgrade