zoul
2024 年1 月 10 日 10:13
1
我在重建 Digital Ocean 实例上的镜像，但有些操作耗时太长：
I, [2024-01-10T09:47:14.854311 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
Node.js heap_size_limit (492.75) is less than 2048MB. Setting --max-old-space-size=2048.
[WARN] (broccoli-terser-sourcemap) Minifying "assets/admin.js" took: 25461ms (more than 20,000ms)
[WARN] (broccoli-terser-sourcemap) Minifying "assets/plugins/chat.js" took: 47818ms (more than 20,000ms)
Purging temp files
Bundling assets
I, [2024-01-10T10:06:07.644096 #3264] INFO -- : Writing /var/www/discourse/public/assets/break_string-cc617154cd957804f2f6a1f3bc68258c9cdca3d4b9a322bf777d145fed04790e.js
该实例有 1 GB RAM，并且 Discourse 运行正常。是我做错了什么吗？有什么办法可以加快重建速度吗？谢谢！
1 个赞
Tomáš Znamenáček:
该液滴有 1 GB RAM
我相信这会让你的内存非常紧张。
现在，我实际上建议 Discourse 实例至少需要 4GB（加上交换空间！） （即使有 2GB + 2GB 交换空间，我也觉得在线更新非常慢）。
3 个赞
zoul
2024 年1 月 10 日 10:33
3
谢谢！不幸的是，这大约是四倍的价格，而我可能只在更新时才能感受到这种改进。此外，云安装指南仍然说：
默认的1 GB RAM 对于小型 Discourse 社区来说效果很好。我们推荐大型社区使用 2 GB RAM。
我们知道这一步的内存压力来自哪里吗？也许可以牺牲更差的压缩率或其他东西来降低内存需求？
RGJ
2024 年1 月 10 日 11:44
4
这是来自 ember-cli 的。
你已经在经历时间与空间的权衡（内存空间不足导致进程花费更长时间）。
3 个赞
Ed_S
2024 年1 月 10 日 13:19
6
我认为，对于我下次更新我的两个服务器，我将利用托管提供商的灵活性，在更新前迁移到更大的内存，并在之后立即迁移回我目前的最低配置。这会增加一点额外的停机时间，但如果重建过程快得多，那么这可能是一个整体上的胜利。额外的费用应该在 1 美元以下，甚至可能只是 1 美分，因为一个小时的额外内存（在我的例子中，从每月 6 美元增加到每月 12 美元，在 Digital Ocean 上按小时收费，分别为 1 美分和 2 美分。）
如链接的帖子中所述，有时重启总是有帮助的，所以对我来说，这是一个更新操作系统软件包并重启的好时机。
我希望这也能减轻我自身的负担。
事实上，我可能会选择从 1G 增加到 8G，这将使每小时的费用增加 6 美分，以便我有自由暂时删除我的交换文件，并缓解磁盘空间紧张的问题。
所有东西都在更新时达到峰值——在此期间，目前的最低配置似乎仍然足够。
我当然负担得起每个升级周期的 6 美分。
4 个赞
Ed_S
2024 年1 月 10 日 13:27
8
Robert:
您的托管服务提供商是谁？
一种情况是 Digital Ocean（1G 内存），另一种是 Hetzner（2G 内存）。
RGJ
2024 年1 月 10 日 13:33
10
Robert:
它们都允许临时在线、就地增加内存吗？
不，
Ed S:
有少量额外的停机时间
这是关机 - 调整大小 - 启动 - 重建 - 关机 - 恢复大小 - 启动
4 个赞
好的，但仍然是就地升级。这是一个很棒的选项，但确实会带来额外的麻烦……以及停机时间。
考虑到 1GB 机器的重建时间很长，你最好还是这样做，因为它反正要停机 30 分钟！
当然，如果你准备好这样做，那么即使是 16GB 机器的临时升级在成本方面也可能还可以
我怀疑很多人会认为自己的时间更有价值，应该开始考虑永久使用 4GB+。
1 个赞
Ed_S
2024 年1 月 10 日 13:40
12
这当然是成本与时间权衡的一部分。就我个人而言，我已经承诺花一个小时来处理升级的“保姆工作”，并且我完全知道如何进行这种系统管理员的“舞蹈”，所以时间已经预订好了。我宁愿将每月的运行成本保持在尽可能低的水平，即使这需要我花费一些时间——其他人会有其他的权衡。
当然，如果花钱对你来说很容易，那就选择一个足够大的实例吧！
1 个赞
Ed_S
2024 年1 月 10 日 16:35
13
仅供参考，我刚刚更新了我的两个论坛，都在一小时内完成，在这两种情况下，我都暂时将内存调整为 8G RAM，然后再调回。这个特定的步骤大约花了 5 分钟，（暂时）使用了 4 个 CPU 和 8G RAM。
I, [2024-01-10T16:07:58.323464 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
110:M 10 Jan 2024 16:08:52.047 * 100 changes in 300 seconds. Saving...
110:M 10 Jan 2024 16:08:52.048 * Background saving started by pid 3276
3276:C 10 Jan 2024 16:08:52.384 * DB saved on disk
3276:C 10 Jan 2024 16:08:52.386 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 0 MB
110:M 10 Jan 2024 16:08:52.449 * Background saving terminated with success
Purging temp files
Bundling assets
MaxMind IP database updates require a license
Please set DISCOURSE_MAXMIND_LICENSE_KEY to one you generated at https://www.maxmind.com
MaxMind IP database updates require a license
Please set DISCOURSE_MAXMIND_LICENSE_KEY to one you generated at https://www.maxmind.com
I, [2024-01-10T16:12:14.362017 #3300] INFO -- : Writing /var/www/discourse/public/assets/break_string-cc617154cd957804f2f6a1f3bc68258c9cdca3d4b9a322bf777d145fed04790e.js
这里可以看到 ember（第 12 列）使用了 2.5G RAM（第 6 列）和多个 CPU（第 3 列）
# ps auxfc|egrep -A29 containerd
root 1097 0.2 0.5 1510892 44924 ? Ssl 16:00 0:01 containerd
root 4507 0.1 0.0 717892 7556 ? Sl 16:03 0:00 \_ containerd-shim
root 4530 0.1 0.3 312292 30512 ? Ssl 16:03 0:00 \_ pups
systemd+ 4609 0.0 0.3 213236 28608 ? S 16:03 0:00 \_ postmaster
systemd+ 4617 0.0 0.8 213340 67288 ? Ss 16:03 0:00 | \_ postmaster
systemd+ 4618 0.0 0.0 213236 5876 ? Ss 16:03 0:00 | \_ postmaster
systemd+ 4619 0.0 0.1 213236 10076 ? Ss 16:03 0:00 | \_ postmaster
systemd+ 4620 0.0 0.1 213904 8860 ? Ss 16:03 0:00 | \_ postmaster
systemd+ 4621 0.0 0.0 68004 5592 ? Ss 16:03 0:00 | \_ postmaster
systemd+ 4622 0.0 0.0 213796 7100 ? Ss 16:03 0:00 | \_ postmaster
message+ 4682 0.2 0.4 87976 35724 ? Sl 16:03 0:00 \_ redis-server
1000 7722 1.1 0.0 0 0 ? Z 16:07 0:01 \_ esbuild <defunct>
root 7736 0.0 0.0 2476 520 ? S 16:07 0:00 \_ sh
root 7737 0.0 0.0 9296 4156 ? S 16:07 0:00 | \_ su
1000 7738 8.3 0.0 2476 580 ? Ss 16:07 0:12 | \_ sh
1000 7835 0.4 0.9 929524 78416 ? Sl 16:08 0:00 | \_ node
1000 7857 0.0 0.0 2484 524 ? S 16:08 0:00 | \_ sh
1000 7858 156 30.5 67413228 2491796 ? Sl 16:08 3:37 | \_ ember
1000 7876 39.0 1.7 11486300 145476 ? Ssl 16:08 0:44 | \_ node
1000 7882 36.7 1.5 11466956 122648 ? Ssl 16:08 0:41 | \_ node
1000 7889 37.1 4.1 11647592 340908 ? Ssl 16:08 0:42 | \_ node
1000 7761 1.5 0.0 0 0 ? Z 16:08 0:02 \_ esbuild <defunct>
也许 4G RAM 对我来说就足够了，但正如所说，整个过程只花费了几美分。（我现在看到，我本可以选择更快的 CPU，只需额外花费一美分。）
编辑：我在开始之前和工作完成后都进行了备份，两次备份相隔 35 分钟。因此，用户看到的停机时间不超过这个时间。
编辑：请注意，Digital Ocean 控制面板显示调整大小操作可能需要长达 1 分钟/GB 的磁盘数据——对我来说只有 14G，而且实际上每次调整大小只用了 2 分钟。但是，如果您的实例上有大量数据，这个调整大小的过程可能会花费更长的时间。（话又说回来，如果您有大量数据，您可能不会尝试在少于 4G RAM 的情况下运行。）
3 个赞
Ed S:
也许4G内存对我来说就够了
在某些情况下，4GB 内存仍然不够。例如，我有一个拥有几乎没有流量的 8GB 内存沙盒，但它是一个多站点设置，允许拥有 5 个一次性沙盒。今天的重建因错误 137 (OOM) 而失败，并且我尝试了 @richard 上面建议的技巧。但是，为了避免每次都这样麻烦，我创建了一个更大的交换空间（4GB），这似乎暂时允许了重建的发生。看起来我们过去一年一直在升级服务器，因为某种原因 Discourse 的重建越来越消耗内存。
2 个赞
Ed_S
2024 年1 月 10 日 17:29
15
有意思。您是否拥有 MKJ 观点性 Discourse 部署配置 中概述的内核设置？
Michael K Johnson:
禁用透明大页，并且我允许内存过载
（拥有交换空间总是有益的，2G 或 4G 或任何可用的磁盘空间都可以。我的交换空间很少，因为我的磁盘空间也很少。）
仔细想想，这只有在完全重建时才真正有好处——我目前无法在2+2配置中使用在线升级
我个人觉得永久升级到至少4GB是唯一的方法……
注意：我并不是真的在抱怨要跟上时代……但我们或许应该在文档和给管理员的建议中开始反映现实？
但这确实不幸地使得 Discourse 对新人，尤其是年轻人来说，稍微不那么容易使用了
1 个赞
Ed_S
2024 年1 月 11 日 12:41
17
我实际上支持这个想法：将当前的最低推荐配置作为目标，并研究代码中的调整或上游的更改以控制它。如果最低配置的价格翻倍，这将是产品提供的重大变化。这就是为什么我在别处认为过高的内存需求是一个错误。
2 个赞
zoul
2024 年1 月 31 日 13:48
18
现在，当我尝试升级到最新版本时，我遇到了升级失败：
...[@embroider/webpack]
Killed
error Command failed with exit code 137.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Docker Manager: FAILED TO UPGRADE
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:210:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:111:in `upgrade'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19:in `block in <main>'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `fork'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `<main>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/commands/runner/runner_command.rb:43:in `load'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.2.2/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.2.2/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.2.2/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/command/base.rb:87:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/command.rb:48:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/commands.rb:18:in `<main>'
<internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
<internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/bootsnap-1.16.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
bin/rails:18:in `<main>'
Spinning up 1 Unicorn worker(s) that were stopped initially
我猜这是内存不足错误？这意味着 1GB 的机器已经过时了？
Ed_S
2024 年1 月 31 日 14:07
19
这确实是内存不足错误。如果你有足够的磁盘空间来添加交换空间，那将足够了，尽管这个过程会比添加内存（RAM）花费更长的时间。你的托管服务提供商可能提供临时升级内存的机会，然后再恢复，这可能会让你付出几次重启、一点点停机时间和几美分的额外费用。
编辑：为了说清楚，内存 = 内存（RAM）+ 交换空间。内存（RAM）速度快，交换空间便宜。
2 个赞
……而且我认为我不会为了更新，例如单个插件，而进行这种升级/降级操作……