업데이트 실패: 디스크 공간 부족 -- 오버레이 파일 과다?

제품 지원 자체 호스팅
1

음, 한숨 – 실패한 업그레이드에 막혀 있습니다.

25G VPS를 사용 중이며, 지원되는 Docker 설치 방식을 사용하고 있습니다.

관리자 패널을 통한 docker_manager 업그레이드는 정상적으로 완료되었습니다.

하지만 관리자 패널을 통해 v3.2.0.beta1 +125에서 v3.2.0.beta3 +325로 Discourse를 업그레이드하는 과정에서 실패하여, 명령줄 설치를 시도해 보았습니다:

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

…이것도 실패했습니다:

You have less than 5GB of free space on the disk where /var/lib/docker is located. You will need more space to continue
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용이고 다른 하나는… "없음?"입니다.

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"은 dangling 또는 intermediate 이미지를 의미하는 것 같습니다: 왜 Docker에 “none” 이미지가 나타나는지 그리고 이를 어떻게 피할 수 있는지 - Stack Overflow – 하지만 너무 작아서 이것이 제 최우선 순위라고 생각하지 않습니다.

Is it safe to clean docker/overlay2/ - Stack Overflow의 조언이 이미지와 오버레이를 grep으로 대조하는 수준까지 가면 저는 지쳐 버립니다. 제 docker/overlay2에는 해시된 폴더가 60개나 있습니다… 120번이나 grep하게 해 주시지는 말아 주세요…

이 시점에서 제 선택지는 다음과 같다고 생각합니다:
A. 이 오버레이 중 하나라도 삭제할 수 있는지 확인하는 데 도움을 얻기.
B. 스냅샷에서 복원하고, 디스크 공간을 늘려 업그레이드한 후 다시 시도하기. 항상 이렇게 거대한 오버레이가 생기는 건가요?

(그리고 25G 인스턴스에 3 x 18G 파일이 어떻게 있을 수 있는 거죠..?)

이 시간에 깨어 계신 분이 조언을 주실 수 있다면 감사하겠습니다.

2

기본적인 사항들을 하나씩 확인해 보려고 하는데, ./launcher cleanup을 실행해 보셨나요? 실행 후에도 여전히 남아 있는 것이 무엇인지 확인해 주세요.

3

네 - 클린업이 효과가 없었습니다.

4

18GB 오버레이 파일이 두 개 있는 것이 아닙니다. 그것은 단서를 오도하는 것입니다. Docker는 overlayfs를 사용하며, 이는 기존 디스크가 컨테이너에 어떻게 표시되는지를 나타낼 뿐입니다. /dev/vda2는 사용자의 디스크이며 /에 마운트되어 있습니다 - 노력이 집중되어야 할 곳은 바로 여기입니다.

./launcher cleanup이 아무 효과도 없었으면, docker image prune(고유한 이미지를 제거)도 마찬가지일 것이라고 추측합니다. 이 서버를 discourse에만 사용하고 있다면, 홈 디렉터리 내에 큰 파일이나 폴더가 없는지 주변을 확인해 볼 필요가 있을 수 있습니다.

5

오 – 아니, 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 아래에 있는 overlays야:

   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

몇 달 사이에 봇들이 로그인을 시도한 흔적이 많이 쌓인 것 같아.
로그를 좀 보관해 두는 것이 신중할 것 같긴 한데, 이 포럼은 아직 베타 버전이니까.
아마 그걸 vacuum 처리하면 다시 돌아가기 시작할 수 있을 거야.

6

음, 그게 완전히 해결되지는 않아서 서버를 55G로 업그레이드했습니다. 만약 그런 큰 오버레이 파일이 필수 불가결하다면, 사실 선택지가 없었던 것 같습니다.

Discourse 업그레이드가 방금 완료되었고, 사이트는 3.2.0.beta4-dev에서 정상적으로 작동하는 것으로 보입니다. :sweat_smile:

관심과 조언을 주신 @JammyDodger님과 @Stephen님께 감사드립니다!

7

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. 쓸모없는 로케일 파일이 약 0.5GB의 공간을 차지하고 있었습니다.

  4. /var/lib/docker/overlay2/.../merged/home/discourse/.cache 디렉터리가 1GB 이상의 공간을 차지하고 있었습니다.

어리석은 질문일 수 있지만, merge와 diff 디렉터리에는 정확히 무엇이 포함되어 있나요? 어느 시점에 이 중 하나를 안전하게 삭제할 수 있을까요?

Docker container with fatass /merged and /diff directories
Docker container with fatass /merged and /diff directories1076×146 13.7 KB