2.6.0 beta 3 更新失败，磁盘/内存空间不足

支持 安装
21

我在想，除了磁盘空间问题外，升级过程是否也超出了分配给该 Droplet 的可用内存（1GB）？在我上方的控制台截图中，可以看到在运行 ./launcher rebuild app 后，第一条日志记录就是“内存不足”。

我此前未提及的是，在那次尝试之后，控制台停止响应（尽管当时我使用的是 DigitalOcean 控制面板中的基于 Web 的控制台，它一直不太稳定），随后我重启了 Droplet。（之后我改用了 PuTTY。）

无论如何，升级页面在遇到同样的内存和/或磁盘问题后仍报告更新成功，这显然不太理想。

2 个赞
22

啊，OOM 杀手被触发了。这肯定不好。通常我会建议增加交换空间。你可以用 swapon 查看当前的使用情况，我的情况如下：

# swapon 
NAME      TYPE SIZE USED PRIO
/swapfile file   2G   3M   -2

另外还可以用 free：

# free
              total        used        free      shared  buff/cache   available
Mem:        1992060      792904       80148       34696     1119008     1004956
Swap:       2097148        3084     2094064

如果你的 2G 交换文件没有启用，那可就糟了。更糟糕的是，你无法在不占用磁盘空间的情况下添加交换空间！

一种为升级腾出磁盘空间的方法是将所有备份文件复制到异地，检查其完整性，然后从服务器上删除它们。升级过程中你绝对需要在某个安全的地方保留一份良好的近期备份，以防万一，但它不必存储在服务器本身上。我会放心地只保留最新的备份，但肯定会先制作一份离线副本。

在你完成所有清理工作后，最好再查看一下 du 的结果。

2 个赞
23

我在想：这里的 1G 是指你的 RAM 分配，而 25G 是指你的磁盘分配吗？这是两个完全不同的概念。

编辑：据我所知，官方支持的标准建议是拥有远多于 1G 的 RAM。
编辑：不，显然 1G 仍然是推荐的绝对最低要求。

2 个赞
24

我刚刚重新连接，控制台窗口启动时显示的系统信息如下：

系统负载：0.01               进程数：136
/ 分区使用率：24.06GB 中的 59.4%   已登录用户数：0
内存使用率：73%                eth0 的 IP 地址：159.65.140.176
交换空间使用率：17%            docker0 的 IP 地址：172.17.0.1

那么 17% 的交换空间使用率是否等于 4GB？

在论坛无人登录、仅当前通过 PuTTY 连接到 droplet 的情况下，内存已占用 73%。这意味着只需少量活动就可能导致论坛进入交换空间。如果这进一步消耗了原本就紧张的 24GB 磁盘空间，那么在更新过程中，磁盘使用率已经很高，这可能会引发“完美风暴”。

现在运行 du -kx / | sort -n | tail -33 的结果如下：

root@nz:~# du -kx / | sort -n | tail -33
505512  /usr/bin
528784  /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse/vendor/bundle/ruby/2.6.0
528788  /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse/vendor/bundle/ruby
528792  /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse/vendor/bundle
536848  /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse/vendor
548952  /var/lib/docker/overlay2/c126267f944d8d7f12415ac4f5908eba8a6a686b093cad3e0115eded8edfd6ba/diff
548968  /var/lib/docker/overlay2/c126267f944d8d7f12415ac4f5908eba8a6a686b093cad3e0115eded8edfd6ba
817700  /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/usr/lib
827812  /var/log/journal/8bebc832e1a692c83690ffe65e1256e3
868792  /var/log/journal
1069356 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse
1069368 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www
1069396 /var/log
1142352 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var
1202004 /var/discourse/shared/standalone/import/data
1307816 /var/discourse/shared/standalone/import
1362804 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/usr
1399332 /var/discourse/shared/standalone/backups/default
1399336 /var/discourse/shared/standalone/backups
1709408 /usr
2438224 /var/discourse/shared/standalone/postgres_data/base/16583
2462944 /var/discourse/shared/standalone/postgres_data/base
2481288 /var/discourse/shared/standalone/postgres_data
2540188 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff
2540204 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35
3387776 /var/lib/docker/overlay2
3460136 /var/lib/docker
3830584 /var/lib
5629420 /var/discourse/shared/standalone
5629504 /var/discourse/shared
5632224 /var/discourse
10747244        /var
14961492        /
root@nz:~#
1 个赞
25

我认为你可以用 journalctl 来优化这一点，例如：

# journalctl --vacuum-size=50M

（你可以在尝试升级之前立即执行此操作）

有趣的是，PostgreSQL 的占用量并没有下降。

free 命令会显示交换空间的使用情况：已使用 17%，总量可能是 2GB 左右。

很明显，你的机器配置略显不足：你需要更多的内存或更多的交换空间，而在不增加磁盘容量的情况下，实际上无法显著增加交换空间。

1 个赞
26

抱歉——您完全正确。1GB 指的是内存，而非已使用的磁盘空间。

1 个赞
27

再次说得非常对。

root@nz:~# free
              total        used        free      shared  buff/cache   available
Mem:        1008828      655660       61716      102288      291452       96576
Swap:       2097148      459776     1637372

我在想，升级过程是否应该在启动前评估主机系统的容量，以确定是否具备执行升级的条件？

2 个赞
28

我觉得这有点像是在预测未来！检查 5G 磁盘空间显然很有帮助，但并不能保证万无一失。可用内存更难判断，因为需要多少内存相当难以捉摸。我想，这将取决于论坛的规模有多大，也可能取决于每次升级时需要触及哪些部分。

我谨慎地控制成本，因此会花时间尝试在廉价服务器上运行。但随着论坛的发展，最终升级到更高一级的配置肯定是值得的。这虽然需要花钱，但能节省时间和精力。

2 个赞
29

我很遗憾，我处于‘尽量降低成本’这一端——这个论坛完全由志愿者运营，不产生任何收入。而由于用户要求增加通过邮件发帖的功能（通过 MailGun 实现），目前每月维持论坛运行已经需要花费我一些钱。

不过，比起其他爱好，比如去夜店喝酒，这还算便宜吧！

6 个赞
30

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.