升级过程中整机挂起

安装
1

自从我尝试了AI插件（后来又删除了它们）之后，我的机器在/admin/upgrade时就会完全卡死。

不是每次都会，但大约80%的时间都会。

通常我的整个EC2实例都会冻结，我必须通过AWS EC2网页界面进行硬重启。

今天它又卡死了。令我惊讶的是，它并没有完全冻结。当我打开根URL时，它现在显示：

哎呀

驱动这个讨论论坛的软件遇到了一个意外问题。我们对造成的不便表示歉意。

错误详情已记录，并生成了自动通知。我们会查看一下。

无需进一步操作。但是，如果错误状况持续存在，您可以通过在该站点的反馈类别中发布讨论主题来提供更多详细信息，包括重现错误的步骤。

我现在将尝试再次重启它，并执行通常能修复它的sudo ./launcher rebuild app命令。祈祷它今天也能再次奏效。

我的问题

谁能给我一些提示，我可以在哪里查看日志文件或类似的东西，至少能得到一个错误消息，说明为什么会发生卡死？

2

官方的 AI 插件？

我会从控制台运行它，看看它在哪里卡住，分享日志。

1 个赞
3

是的，官方插件。

我通过再次从 app.yml 中删除插件并重新构建来卸载它。也许这样做还不够？

“这个”指的是什么？是 sudo ./launcher rebuild app 吗？

1 个赞
4

您的服务器配置是什么？

依我看，如今在线升级的最低要求是 4GB 服务器 + 2GB 交换空间。

2 个赞
5

我正在使用一台拥有 2 个 vCPU 和 4 GiB RAM 的 AWS EC2 “t2.medium”。

HDD 为 100 GiB，剩余 60 GiB 空间。

如果需要，我可以将“t2.medium”升级到更大的实例类型。

我感到困惑的是，在测试了官方 AI 插件之前，这个设置运行得非常稳定（多年），并且自从移除它之后，升级过程中才会出现这些挂起。

1 个赞
6

还有一件事也变了：您正在升级到的软件版本。它最近变得更加消耗内存。所以我认为可能是其中一个原因。

将实例临时且可逆地升级到具有更多 RAM 的实例可能是测试内存不足是否是问题的最简单方法，尽管这需要几次重启。另一种方法是添加交换空间，这也是可逆的。

3 个赞
7

我会尝试添加交换空间。

2 个赞
8

谢谢大家，我将谷歌搜索如何做到这一点，然后去做 :slight_smile:。

更新 1

我现在添加了 8 GiB 的交换空间：

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       290Mi       2.9Gi       1.0Mi       677Mi       3.3Gi
Swap:          8.0Gi          0B       8.0Gi

在进行一些后续升级后，我会在这里发布更新，看看这是否有帮助。

更新 2

刚刚进行了 /admin/upgrade 并监控了 RAM 使用情况：

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       1.4Gi       1.5Gi        50Mi       891Mi       2.0Gi
Swap:          8.0Gi       200Mi       7.8Gi

升级已成功完成。 :tada: 希望能一直保持这样。

更新 3

几天和几次升级后，我再也没有遇到过卡顿。

所以我认为交换空间是解决方案。再次感谢所有帮助我解决此问题的人。

2 个赞
9

这有点离题，但我真的很想明白。为什么交换（使用了 200 MB）在有 2 GB 空闲 RAM 时会有帮助？

（我明白在英制单位世界中，SI 制可能令人困惑，因为它使用 10 的比例，但为什么还要用 Mi？我有点理解 Gi，因为它缩写自 giga，但 mega 难道不应该是 Me 吗？）

1 个赞
10

我猜 Mi 是 Mibibytes（米比字节）的意思，Gi 是 Gibibytes（吉比字节）的意思。

1 个赞
11

谢谢。我不知道，这很明显。但它是 mebibyte :wink:

也给其他不知道的人 :smirking_face:

2 个赞
12

我认为最初的问题可能是某个进程因为内存不足而被杀死（小心 OOM killer）。添加交换空间意味着内存没有耗尽。这两个 free 的输出可能没有 telling the whole story，除非它们是在机器压力最大的时候非常仔细地获取的。我认为，有趣的应该是峰值交换使用量。

但正如在 MKJ 的主观 Discourse 部署配置 中提到的，还有一个内核可调参数的问题，我已经正确设置了它，但也许很多人没有正确设置。

值得注意的是，内存超额提交与 Redis 没有太大关系。只是 Redis 很乐意提示它应该被正确设置。

3 个赞
13

又启动了一次 /admin/upgrade，并打开了一个 shell 来大约每秒手动调用一次 tree -h。

我找到的最高内存使用值是这些：

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           3.8Gi       3.2Gi       120Mi        80Mi       542Mi       266Mi
Swap:          8.0Gi       276Mi       7.7Gi

升级成功了。

1 个赞
14

因此，在构建时，4 GB 刚好处于边缘，如果我们假设最后一个截图显示了最紧张的时刻。

这是我无法理解的另一件事：为什么其他人会遇到内存不足的问题，而我却使用了大量插件和组件，却没有任何问题 :thinking: 是什么造成了这种差异？

我之所以使用过去时，是因为现在我拥有 8 GB 内存，这得益于 AI（对我来说，价格差异并不重要，但那是另一回事）。

这个帖子应该移到别处吗，还是我们将其视为解释为什么使用交换空间有帮助的帖子？

总之。对于其他初学者来说，这是一个关于内存不足及其原因的讨论示例：

这是一个在升级失败时经常被问到的 FAQ 问题。但原因很少被解释。

1 个赞
15

@Jagster @uwe_keim 请报告这些命令的输出

cat /proc/sys/vm/overcommit_memory 
cat /sys/kernel/mm/transparent_hugepage/enabled

在我的系统上，我有

# cat /proc/sys/vm/overcommit_memory 
1
# cat /sys/kernel/mm/transparent_hugepage/enabled 
always madvise [never]
1 个赞
16 
$ cat /proc/sys/vm/overcommit_memory
0

和

$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
1 个赞
17

感谢 @uwe_keim - 我想这可能是您需要添加交换空间的原因，尽管它似乎没有被使用。（如果您需要添加大量内存，情况也是如此，因为可用内存总量是 RAM+swap。）

1 个赞
18

如果我建议这样做，我可以随时更改服务器设置。

19 
root@foorumi-hel:/var/discourse# cat /proc/sys/vm/overcommit_memory
0
root@foorumi-hel:/var/discourse# cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
2 个赞
20

我推荐！

这将修复将来的重启问题（请注意，它会覆盖文件而不检查当前状态）：

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
sysctl --system
1 个赞