我很感激，但是_重建应用_需要大约3个小时！
而且这是在一个巨大的VPS上。
难道不能像添加和删除主题一样移除插件吗？
也许是未来可以考虑的功能？
谢谢！！
1 个赞
抱歉？！应该只需要大约 20 分钟？！
1 个赞
不在这里
最初的安装花了2个小时。
现在，./launcher rebuild app 已经卡在这里了：
Ensuring launcher is up to date
Fetching origin
Updating Launcher...
Updating eeefdde..30be122
Fast-forward
image/base/install-imagemagick | 5 ++++-
launcher | 2 +-
templates/web.letsencrypt.ssl.template.yml | 2 +-
templates/web.template.yml | 6 +++---
4 files changed, 9 insertions(+), 6 deletions(-)
Launcher updated, restarting...
Ensuring launcher is up to date
Fetching origin
Launcher is up-to-date
Stopping old container
+ /usr/bin/docker stop -t 60 app
app
Unable to find image 'discourse/base:2.0.20220818-0047' locally
2.0.20220818-0047: Pulling from discourse/base
1efc276f4ff9: Pulling fs layer
1b880e64942b: Pulling fs layer
794f6dc9a2ff: Pulling fs layer
1efc276f4ff9: Verifying Checksum
1efc276f4ff9: Download complete
1efc276f4ff9: Pull complete
794f6dc9a2ff: Verifying Checksum
794f6dc9a2ff: Download complete
1b880e64942b: Verifying Checksum
1b880e64942b: Download complete
1b880e64942b: Pull complete
794f6dc9a2ff: Pull complete
Digest: sha256:7734701087766821ffb2ddcef423754798bd345c2ac0d550131c6e6905c268e8
Status: Downloaded newer image for discourse/base:2.0.20220818-0047
在最后一行之后，它只是不停地闪烁（进程仍在进行中）。
这大约已经持续了30分钟。
上次我这样做时，花了整整160分钟。
服务器总内存：4.657GiB，内核版本：5.15.0-43-generic，操作系统：Ubuntu 22.04 LTS，50GB SSD 驱动器，2.5 核，5 线程 Intel® Xeon® CPU
…
不确定这可能有什么问题，除了它花费的时间_非常_长 
3小时听起来确实很不对。你需要调查这个问题并将其作为首要任务解决。
构建日志中存在“视觉暂停”，这是正常的，但这种延迟是不正常的。
我猜测你可能在构建过程中开始使用交换空间了，但我不是系统管理员。你在这台机器上运行其他东西了吗？
下载需要解压缩，这在计算上成本很高，但对每个人来说都是相同的镜像。
供参考，我刚才在 https://scaleway.com 上的一台 2GB 2vCPU 机器上重建了一个站点，耗时 13 分钟 46 秒。
4 个赞
不，这是一个仅用于此 discourse 实例的 VPS。我运行着许多同一家公司的其他 VPS，它们运行得都非常流畅（但它们不是 discourse 实例，而是其他应用程序，例如自定义 PHP 或 WP/CP CMS 实例等）。
我不知道有任何交换空间使用情况，也看不到任何可以证明的资源使用峰值。
现在它处于“building…”状态——似乎比上次快一点，但仍然明显超过 20 分钟。
我会询问服务器提供商，看他们是否能在他们的终端上发现任何异常，不过，我记得他们亲自告诉我，他们自己的 Discourse 实例也花了大约 2 小时来构建。（PS：这些 VPS 是在 Hetzner 机器上通过第三方租用的，我怀疑我能获得更好的东西。）
无论如何，我的建议仍然是，能够像添加和删除主题一样添加和删除插件将是惊人的。也许可以考虑一下？
我真的什么都不知道，但据我所知，这是不可能的，因为 Discourse 是由许多编译过的 JavaScript 组成的。当需要添加或删除某些会改变核心功能和工作方式的内容时，就必须进行重建。
这和 Varnish 的情况非常相似。
1 个赞
好的……
顺便说一句，我与服务器人员确认过，确实达到了 100% 内存占用。
5GB？？？5GB 内存对于任何东西来说都太多了。
Discourse 的要求是需要 1GB 内存！
现在卡在下面这个状态：
104:M 04 Oct 2022 07:19:27.251 # Redis 现已准备退出，再见……
sha256:662695076506add39a630c2169b8b618f0121386951e93c6ffd2a6473107ae55
f4a95a1e69d5375e6ea30dfb22576209d249e5bc67b04a6fa09df289b1441888
正在移除旧容器
+ /usr/bin/docker rm app
app
因此，我甚至无法升级服务器，因为该过程会被中断。
真的，我一点也不认为这是服务器问题。如果我们只需要 1GB，那么 5GB 应该绰绰有余了。
这有问题，大有问题。
我明白其他人可能（看看 @merefield 说在 2GB 上升级……）有更好的体验，但对我们来说，它并没有像预期的那样工作。
总之，这大概是这个帖子的题外话了。
1 个赞
我又重建了一个站点，4GB，3vCPU，又花了不到15分钟（也就是说，额外的内存/CPU在我的案例中并没有太大帮助，但仍然远远好于几个小时！）。
我唯一注意到的是我的 VPS 使用 vfs 而不是建议的 aufs 或 overlay。
然而，根据这个 https://meta.discourse.org/t/cant-run-launcher-rebuild-app-docker-storage-driver-is-unsupported/56927/45，这应该不是什么重要的事情，因此我们使用 --skip-prereqs 运行启动器，否则我们甚至无法运行 Discourse。
我确实想知道这个存储驱动程序要求是否还有更多内容。
1 个赞
这有点……过于乐观了。用于测试目的可能够用，但即使那样也会有点紧张。2GB 更接近实际情况。
不过，4GB 对于更大的实例来说足够了。但核心的数量和性能也起着重要作用。
而且……如果你有 5GB 内存，重建仍然需要这么长的时间，那一定有什么问题。
我使用的是 DigitalOcean/4GB/2 个 Intel vCPU，重建大约需要 25 分钟。
你的系统具体是什么配置，加上 app.yml 文件——有什么自定义的地方吗？
您好，唯一的自定义是之前提到的（使用 vfs 而不是 aufs/overlay）。
其余均为原生。
服务器：
服务器总内存：4.657GiB，内核版本：5.15.0-43-generic，操作系统：Ubuntu 22.04 LTS，50GB SSD 驱动器，2.5 核，5 线程 Intel® Xeon® CPU
yaml 文件是原始的，除了这些附加插件：
discourse-assign
discourse-chat
discourse-checklist
discourse-docs
discourse-reactions
discourse-solved
discourse-surveys
discourse-voting
docker_manager
styleguide
我不明白从那些数据中为什么重建会花费这么长的时间。
我会在别处启动一个相同大小的 Ubuntu VPS。只是为了找出问题是否来自托管公司。这只需要你花费几美元和一两个小时的工作。
预编译 JavaScript 需要大量内存。尝试添加交换空间。
覆盖层
我认为该测试可能是有原因的。这可能是您的问题。
1 个赞
为什么 5 GB RAM 的原生 Discourse 需要更多交换空间，而更小的空间却能满足它们自动获得的空间？
因为它比做你真正需要做的事情更容易。
添加交换空间可能会有帮助，但这并不是你最大的问题。
3 个赞
我猜我应该在部署 discourse 容器 之前 就尝试过这个：How to change the Docker storage driver – Webdock
Apparently it is possible to change the storage driver - contrary to what the host instructed me back when we deployed the container (which was to either edit the loader file or ignore the check)
好吧，现在太晚了，我猜。
不管怎样，谢谢，如果这是问题的原因，我想这是用户错误。我的错 
我不这么认为。
另外，双容器设置减少了停机时间，因为您在旧容器继续运行时重建了新的 Web 容器。
1 个赞
您的网站有多大？我建议添加交换空间来解决内存问题。
一个带有 1GB 交换空间的空白 1GB 实例对于小型测试社区来说运行良好，但随着其增长，这将不足以应对。交换空间绝对会产生影响。
如果在“巨大的”VPS 上重建，该 VPS 位于拥有极快网络连接的数据中心，需要 3 小时，而我在 https://discourse-on-a-pi.falco.dev 上运行的安装程序，该程序运行在放在我桌子上的信用卡大小的板子上，通过第三世界国家的标准家庭网络连接到互联网，重建只需要 14 分钟（当有新的容器镜像时需要额外 4 分钟），那么他们卖给你的产品就有问题……
15 个赞
服务器上的内存使用情况如何？ 如果在开始重建之前就已经接近满负荷，那么将会产生大量的交换操作，这肯定会让所有操作耗费过长的时间。
如果确实如此，我建议您在可能的情况下，暂时禁用服务器上可能运行的任何其他程序。
3 个赞