升级单个插件时，从 admin/upgrade 进行升级需要很长时间。
通常情况下，完整重建大约需要 7 分钟。
自 2023-03-02T20:07:00Z 起一直在升级，当前状态为：
HTOP 输出：
编辑：2023-03-02T20:44:00Z - 仍然停留在同一日志行。CPU 使用率也相同。此时已启动 CLI 重建。
编辑 2：为了参考我的机器上重建的确切时间，重建完成时间戳：2023-03-02T20:51:00Z
4 个赞
是的，至少从昨天开始我就遇到了同样的问题。
现在从升级屏幕升级几乎不可能在合理的时间内完成，因此您被迫从命令行升级。
我也是，我遇到了完全相同的问题。升级插件时非常烦人，耗时非常非常长——极其不方便。
2 个赞
有什么办法可以解决这个问题吗？每次升级以跟上 Discourse Chatbot 
(支持 ChatGPT) - 插件 - Discourse Meta 的更新时，都需要花费很长时间。
这仍然是一个问题。
但是，这似乎只影响较低配置的服务器？
1 个赞
只是想多说几句，而不是提供答案…… 
我有一个只有 1GB 的 DO 测试站点，有很多插件，所以它通常不是最快的。不过，我认为最近它也花费了很长时间，而且前几天我的站点也像 @MarcP 一样出现了奇怪的问题，我不得不重置它。
我以前从未计时过，但今天我将其设置为“全部更新”，并记下了我点击按钮的时间。到目前为止，我们是早上 9:30 开始，到 10:15 还在进行。它目前正在打包一些资源。我可以比较有信心地说，它通常不会花费超过 45 分钟（并且还在继续）来完成它的工作。
不过看起来它在清除临时文件时遇到了一些权限问题？不确定这是否相关。
4 个赞
@david 和我找到了根本原因。（类似于 @Falco 过去找到的原因）
我们使用特殊的 Ruby 标志来尝试在升级期间限制内存，但这在 Ruby 3.2 上不再有效。
我们应该很快会有一个 PR 来解决这个问题。
7 个赞
7 个赞
注意……要使修复生效，存在一个先有鸡还是先有蛋的局面。运行升级时仍会加载旧代码。
您可能需要第一次运行 ./launcher rebuild，之后再次运行时，Web 升级程序将正常工作。
没有简单的解决方法。@cvx 这是一个棘手的问题……严格来说，我们应该让 DockerManager::Upgrader.new(user_id, repo, repo_version).upgrade 在升级时进行外部调用并运行新的升级代码……但这就像打开了一个潘多拉的盒子。
快速解决方法
- 启动 Docker 管理器升级
- 在卡住时取消
- 在 shell 中运行
./launcher restart app - Web 升级将正常工作。
简单解决方法
- 运行
./launcher rebuild app
之后一切都会正常。
编辑
提前关闭此问题，因为我希望这是关于此主题的最后一篇文章。这样人们可以轻松找到解决方法。如果重建后仍有问题，请标记以重新打开。
8 个赞