升级失败:磁盘空间不足——超额覆盖文件?

嗯,叹气——我被卡在了一个失败的升级上。

我使用的是一个 25G 的 VPS,并采用了支持的 Docker 安装。

通过管理面板升级 docker_manager 没问题。

通过管理面板将 Discourse 从 v3.2.0.beta1 +125 升级到 v3.2.0.beta3 +325 失败了,所以我尝试了命令行安装:

cd /var/discourse
git pull
./launcher rebuild app

……这也失败了:

您在 /var/lib/docker 所在磁盘上的可用空间少于 5GB。继续操作需要更多空间
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda2        23G   22G  640M  98% /

显然是因为两个 18G 的“overlay”文件:

root@forum:/var/discourse# df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs            95M  1.4M   94M   2% /run
/dev/vda2        23G   18G  4.1G  82% /
tmpfs           474M     0  474M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/vda1       511M  6.1M  505M   2% /boot/efi
tmpfs            95M  4.0K   95M   1% /run/user/0
overlay          23G   18G  4.1G  82% /var/lib/docker/overlay2/8a331589d7fa9046a6ef73489cc830c2583cb76c9174125c8bfe1064d58cd503/merged
overlay          23G   18G  4.1G  82% /var/lib/docker/overlay2/d56574358c8edbc9bc1fb50022585b854462a8ce56daa636b07f3a3771949251/merged

(一个 25G 的服务器上有 三个 18G 的文件?那就有 54G 了……)

似乎有些东西是可以回收的:

root@forum:/var/discourse# docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          2         2         4.3GB     3.334GB (77%)
Containers      2         2         1.849GB   0B (0%)
Local Volumes   0         0         0B        0B
Build Cache     0         0         0B        0B

……但我不知道是什么,也不知道如何操作。

/var/discourse/shared/standalone/backups/default 的内容只有 67Mb。

我用 systemctl stop docker 停止了 docker,并尝试了以下命令,但都没有效果:

docker system prune -a
docker buildx prune --all
docker builder prune --all

……都报告释放了 0B。

我有两个 Docker 镜像,一个是 Discourse 的,另一个是……“none?”

root@forum:/var/discourse/image# docker images
REPOSITORY            TAG       IMAGE ID       CREATED        SIZE
local_discourse/app   latest    5ff1dcfe050c   2 months ago   4.09GB
<none>                <none>    bbaceb5f4a80   2 months ago   214MB

Apparently “none” indicates a dangling or intermediate image: Why the “none” image appears in Docker and how can we avoid it - Stack Overflow – 但它太小了,我不认为这是我的首要任务。

当 Stack Overflow 上关于 Is it safe to clean docker/overlay2/ - Stack Overflow 的建议涉及到对 overlays 进行 grep 来匹配 images 时,我就晕了。我的 docker/overlay2 中有 60 个哈希文件夹……拜托,别让我 grep 120 次……

我想我目前的选项是:
A. 获得一些帮助,弄清楚这些 overlay 是否可以删除。
B. 从快照恢复,升级以获得更多磁盘空间,然后重试。我是否总是会有这些巨大的 overlay?

(以及我怎么会在一个 25G 的实例上拥有 3 个 18G 的文件……?)

如果有人在这个时间还有精力,并且有什么建议,我将不胜感激。

为了排除基本问题,但您已经尝试过 ./launcher cleanup,这是剩余的内容吗?

3 个赞

是的,清理没有效果。

2 个赞

你没有两个 18GB 的 overlay 文件,那是个障眼法。Docker 使用 overlayfs,这些只是你现有的磁盘如何呈现给容器。/dev/vda2 是你的磁盘,挂载在 / — 这才是你应该努力的方向。

如果 ./launcher cleanup 没有起到任何作用,那么我猜 docker image prune(移除悬空镜像)也不会有作用。如果你只用这个服务器来运行 discourse,你可能需要检查一下你的主目录中是否还有其他大型文件/文件夹。

3 个赞

哦,Docker 这样做有点棘手……
不,清理操作没有恢复任何东西。
我正在用 ncdu 浏览 /usr…… 没什么明显不属于那里的东西,尽管我不确定如何处理 /usr/lib/modules:

  547.2 MiB [###########################] /6.2.0-37-generic
  547.2 MiB [########################## ] /6.2.0-34-generic
    1.2 MiB [                           ] /6.2.0-33-generic
    1.2 MiB [                           ] /6.2.0-32-generic
    1.2 MiB [                           ] /6.2.0-35-generic
    1.2 MiB [                           ] /6.2.0-36-generic

到目前为止,报告最多的使用量是 /var 下的覆盖层:

   16.0 GiB [###########################] /var
    4.3 GiB [#######                    ] /usr
    2.3 GiB [###                        ]  swapfile
    1.7 GiB [##                         ] /snap
  289.5 MiB [                           ] /boot

/snap 里没有什么不属于它的东西:

root@forum:/# snap list
Name    Version       Rev    Tracking         Publisher   Notes
core22  20230801      864    latest/stable    canonical✓  base
lxd     5.19-8635f82  26200  latest/stable/…  canonical✓  -
snapd   2.60.4        20290  latest/stable    canonical✓  snapd

哇——/var/log/journal 变大了!

    1.8 GiB [###########################] /7341e5ac94ae440bbd06f743e242da89
   16.0 MiB [                           ] /7025a9ae870140c1bef8e55211d339dc

看起来在短短几个月里,有大量的机器人试图登录。
保留日志一段时间似乎是明智的,但这个论坛仍处于测试阶段。
也许清理一下就足够让我重新开始工作了。

2 个赞

好吧,那并没有完全解决问题,所以我将服务器升级到了 55G。如果那些大的覆盖文件是不可避免的,我想别无选择。

Discourse 升级已完成,该站点在 3.2.0.beta4-dev 上运行正常。:sweat_smile:

感谢 @JammyDodger@Stephen 的关注和建议!

3 个赞

我一个 50GB 的 Linode VPS 空间快用完了。

以下是一些尚未提及的空间占用者。有些是 Discourse 特有的,有些是 Linux 系统通用的。

  1. 运行 ll /lib/modules。我惊讶地发现大约有 15GB 的旧内核,apt autoremove 没有移除它们。Claude 认为它们是以非标准方式安装的,并生成了一个安全的 移除脚本。这花了一个小时左右,但它奏效了(当然,风险自负),我能够运行 ./launcher rebuild 而没有 no space left on device 错误。

  2. 该脚本没有删除 /usr/src 中相应的头文件。为此,ChatGPT 创建了 另一个脚本

  3. 无用的 locale 占用了大约半 GB 的空间。

  4. /var/lib/docker/overlay2/.../merged/home/discourse/.cache 目录又占用了 1GB 以上。

也许是个愚蠢的问题,但 mergediff 目录具体包含什么?它们中的任何一个可以安全地删除吗?

1 个赞