アップグレード失敗:ディスク容量不足 -- 余分なオーバーレイファイル?

うーん、 sigh – アップグレードに失敗して困っています。

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」ファイルが 2 つあるためらしいです。

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 のファイルが 3 つ? それは 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 の解放と報告されました。

Discourse 用と、「none?」用の 2 つの Docker イメージがあります。

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

「none」はダングリングまたは中間イメージを示しているようです: Why the “none” image appears in Docker and how can we avoid it - Stack Overflow – しかし、これは非常に小さいので、最優先事項ではないと思います。

Is it safe to clean docker/overlay2/ - Stack Overflow のアドバイスで、overlay をイメージに対して grep する段階になると、意欲がなくなります。docker/overlay2 には 60 個のハッシュ化されたフォルダがあります… 120 回も grep させないでください…

現時点での私の選択肢は次のとおりだと思います。
A. これらの overlay のどちらかを削除できるかどうか、理解するのを手伝ってもらう。
B. スナップショットから復元し、ディスク容量を増やして再度アップグレードする。これらの巨大な overlay は常に存在するのでしょうか?

(そして、25G のインスタンスに 3 つの 18G ファイルがどのように存在するのでしょうか…?)

もし今この時間に起きている人がいて、何か意見があれば、感謝します。

念のため基本的なことを確認しますが、./launcher cleanup を試して、これだけが残ったということでしょうか?

「いいね!」 3

はい、クリーンアップは効果がありませんでした。

「いいね!」 2

18GBのオーバーレイファイルが2つあるわけではありません。それは見当違いです。Dockerはoverlayfsを使用しており、これらは既存のディスクがコンテナに提示される方法にすぎません。/dev/vda2はあなたのディスクであり、/にマウントされています。そこが努力を向けるべき場所です。

./launcher cleanupが何も効果がなかった場合、docker image prune(ぶら下がっているイメージを削除します)も効果がないと推測します。このサーバーをDiscourse専用に使用している場合は、ホームディレクトリに大きなファイルやフォルダがないことを確認する必要があります。

「いいね!」 3

Dockerはトリッキーですね…
いいえ、prune操作では何も回復しませんでした。
現在、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 を実行します。apt autoremove が削除しなかった古いカーネルが約15GBあることに驚きました。Claudeは、これらが標準的でない方法でインストールされたと考えており、安全な削除スクリプトを作成しました。1時間ほどかかりましたが、うまくいきました(もちろん、自己責任で実行してください)。これにより、no space left on device エラーなしで ./launcher rebuild を実行できるようになりました。

  2. スクリプトは /usr/src の対応するヘッダーを削除しませんでした。そのためにChatGPTが別のスクリプトを作成しました。

  3. 約500MBの容量が不要なロケールによって消費されていました。

  4. さらに1GB以上が /var/lib/docker/overlay2/.../merged/home/discourse/.cache ディレクトリによって消費されていました。

愚かな質問かもしれませんが、merge および diff ディレクトリには具体的に何が含まれていますか?どちらかを安全に削除できる時期はありますか?

「いいね!」 1