azhdrake
7월 10, 2026, 12:08오전
1
안녕하세요,
저는 25GB 용량의 서버에 작은 규모의 Discourse 인스턴스를 운영하고 있습니다. 현재 여유 공간이 3.4GB밖에 남지 않았는데, 그 이유가 무엇인지 모르겠습니다. 이로 인해 업데이트를 실행할 수 없는 상태입니다.
이 인스턴스에는 Discourse 외에는 다른 서비스가 실행되지 않고 있으며, 과거에도 그랬습니다.
지금까지 공간을 확보하기 위해 다음과 같은 조치를 취했습니다:
Discourse와 /var/log/journal에서 찾을 수 있는 모든 로그를 삭제했습니다.
Discourse 백업 중 하나를 제외한 나머지를 모두 삭제했습니다.
오래된 Docker 이미지들을 정리했습니다.
apt-get autoclean과 apt-get autoremove를 실행했습니다.오래된 커널이 없는지 확인했습니다.
Postgres 데이터를 외부 드라이브로 옮기는 것도 고려해 봤지만, 현재 용량이 1GB가 채 되지 않아 그렇게 큰 도움이 되지 않을 것 같습니다.
/dev/vda1 파티션이 20GB의 공간을 사용하고 있습니다.
더 이상 해 볼 수 있는 방법이 있을까요? 25GB는 더 이상 Discourse를 실행하기에 합리적인 디스크 용량이 아닌가 걱정됩니다.
주로 업로드 파일에 따라 달라지지만, 백업과 PostgreSQL도 영향을 미칩니다. 사이트가 매우 큰 경우 말이죠(질문 내용을 들어보면 이것이 문제는 아닌 것 같습니다). 업로드 파일의 크기는 얼마나 되나요? 관리자 대시보드 하단에 표시되어 있습니다.
azhdrake
7월 10, 2026, 12:13오전
3
용량은 50MB 미만이며, 이 인스턴스는 크거나 오래된 것이 아닙니다. 앞서 언급했듯이 메인 드라이브에서 옮기는 것을 고려해 보았지만, 이것이 여기서 주요 문제라고 생각하지는 않습니다.
업로드 파일이 약 25MB이고 Postgres가 약 1GB라면, Discourse가 필요 없는 백업을 생성하고 있을 가능성이 있습니다. 백업 유지 설정(관리자 > 설정 > 백업)을 확인하고 현재 백업(관리자 > 백업)을 살펴본 후 필요 없는 백업을 삭제해 보세요.
아니에요. 이미 정리해 두셨다는 걸 떠올렸으면 좋았을 텐데요.
공용 영역에서 공간을 차지하는 요소를 확인해 볼 수 있습니다:
du -sh /shared/*
du -sh /var/www/discourse/*
du -sh /var/www/discourse/public/*
azhdrake
7월 10, 2026, 12:22오전
5
디스크에서 백업을 복사한 후 남은 백업 하나를 삭제했습니다. 그래도 여전히 3.5GB만 남아 있습니다.
네, 죄송합니다. 방금 게시글을 업데이트하여 새 지침을 추가했습니다.
azhdrake
7월 10, 2026, 12:34오전
7
이 서버에는 /shared/ 디렉터리가 없습니다.
du -sh /var/discourse/* 명령으로 확인한 결과는 다음과 같으며, 총 크기는 658M입니다:
4.0K /var/discourse/LICENSE
12K /var/discourse/README.md
4.0K /var/discourse/bin
4.0K /var/discourse/cids
8.0K /var/discourse/containers
12K /var/discourse/discourse-doctor
8.0K /var/discourse/discourse-setup
368K /var/discourse/image
8.0K /var/discourse/install-discourse
28K /var/discourse/launcher
32K /var/discourse/samples
8.0K /var/discourse/scripts
657M /var/discourse/shared
180K /var/discourse/templates
파일 시스템에서 가장 많은 공간을 차지하는 항목은 2.4GB인 /var/lib/containerd/io.containerd.content.v1.content와 무려 12GB에 달하는 /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs입니다.
미안합니다. 컨테이너 안에 있어야 한다는 점을 언급하지 못했네요. 말씀하신 파일은 Docker에서 온 것입니다. 필요할 경우 docker system df 명령어로 해당 파일이 어디에 사용되고 있는지 확인할 수 있으며, docker system prune 명령어로 전체 정리를 수행할 수도 있습니다. 다만, 이 작업을 수행할 때는 Discourse가 실행 중인지 반드시 확인해 주세요.
azhdrake
7월 10, 2026, 1:02오전
9
아, 그게 말이 되겠네요.
컨테이너 안에서 1GB를 초과하는 것은 2.1GB인 /var/www/discourse/vendor/bundle/ruby/뿐입니다.
업데이트 시 가져오는 이미지를 정리하면 충분한 공간이 확보되지만, 업데이트를 시도하여 이미지를 다시 가져오면 그 공간이 사라집니다. 따라서 새 이미지는 거의 5GB의 공간을 차지합니다.
그 도커 명령어의 출력을 보여줄 수 있나요? 그 디렉토리는 모든 Ruby gem을 포함하고 있으며, 그 크기는 제게는 이상할 정도로 크다고 느껴지지 않습니다.
Ed_S
7월 10, 2026, 7:48오전
11
정말, 모든 출력 결과를 보여주세요. 컨테이너 내부에서 이리저리 살펴보는 것은 권장하지 않습니다. 문제는 시스템 레벨에 있으며, 거기서부터 조사를 시작해야 합니다. 그리고 문제가 있을 것이라고 생각하는 곳만 보지 말고, 전체적인 상황을 살펴보세요.
먼저 재부팅을 실행하세요. 깨끗한 파일시스템과 새로운 시스템이 필요합니다.
다음으로, 자세한 조언을 위해 이전 스레드를 참고하세요:
pfaffman
7월 10, 2026, 3:12오후
12
다음 명령을 실행해 보셨나요?
./launcher cleanup
또는 docker를 정리하셨나요?
가장 작은 포럼을 제외하고는 25GB로는 운영이 어렵습니다.
제 포럼은 작은 포럼(실제로는 거의 저 혼자 쓰는 수준)인데, 업데이트로 인한 스트레스를 받지 않으려고 여유를 두고 40GB VPS를 사용하고 있습니다.
제 VPS 3대 중 20GB를 사용하지 않는 곳은 이 곳뿐입니다. 나머지 하나는 MySQL과 PHP 백엔드를 가진 HTTP 서버이고, 또 하나는 rtmp 서버입니다. Discourse가 돌아가는 이 VPS에는 docker-mailserver도 함께 실행 중이지만, 다이제스트 메일은 꺼져 있고 dms의 footprint가 매우 작아서 문제없습니다.
pfaffman
7월 11, 2026, 4:05오전
14
이렇게 하면 문제가 해결될 가능성이 높습니다.
조금의 공간을 확보하기 위해 다음 명령어를 사용합니다. 재빌드 과정을 진행하는 데 도움이 될 수 있습니다.
sudo apt -y autoremove && apt -y autoclean
sudo apt clean
sudo journalctl --vacuum-time=1s
1번과 2번은 Ubuntu를 정리합니다.
이 내용은 OP에 이미 있었지만, Discourse 명령어를 실행하는 것이 명백히 더 좋습니다.
azhdrake:
azhdrake
7월 11, 2026, 5:16오후
17
답변 주셔서 감사합니다! 갑자기 사라져서 죄송합니다. 일이 생겨서 어제 더 많은 문제를 해결할 시간이 없었습니다.
요약하자면, 이 특정 문제에 대한 스레드가 얼마나 많은지 알아차렸고, 이번에는 해결하더라도 다시 발생할 것 같아서 인스턴스를 35GB 용량의 좀 더 큰 서버로 이전했습니다.
이 문제를 해결하기 위해 이곳을 방문했지만 업그레이드를 원하지 않는 분들을 위해:
./launcher cleanup은 이미 시도해 봤지만, 충분한 공간을 확보하지는 못했습니다. 또한 이미 다음 명령어를 실행해 보았지만,
sudo apt -y autoremove && apt -y autoclean
sudo apt clean
sudo journalctl --vacuum-time=1s
다시 한번 말씀드리지만, 이것만으로는 부족했습니다. journalctl에 로그가 많이 쌓여 있었습니다(25GB 머신 기준). 따라서 본인에게도 해당되는지 꼭 확인해 보시길 권합니다. 하지만 제 경우에는 충분한 도움이 되지 않았습니다.
pfaffman
7월 13, 2026, 7:01오전
18
맞아요! 공간이 꽤 많이 차지할 수 있죠. 제 대시보드 스크립트는 공간이 부족하면 로그를 정리해 줍니다. 그 부분을 깜빡하고 있었네요 (스크립트로 처리되므로 제 대시보드를 사용하는 사이트에는 문제가 되지 않기 때문이라고 생각해요).
참고로 일부 프로바이더는 기존 위치에 디스크 용량을 증설할 수 있도록 허용합니다(예: Scaleway는 가능하다고 알고 있고, DO도 가능할 것 같습니다?).
또 다른 시도해볼 만한 방법은 VPS를 단순히 재부팅하는 것입니다. 이미 수행한 일부 정리 작업을 반복할 수는 있지만, 때로는 공간을 확보하는 데 도움이 될 수 있습니다.
Ed_S
7월 14, 2026, 5:54오전
20
정말 맞습니다: 리소스 제약 조건을 완화하기 위해 더 많은 비용을 지출할 수 있다면, 시간과 노력을 절약할 수 있습니다.
하지만 이번에는 다른 방식으로 이 문제를 처리하는 방법을 볼 기회를 놓쳤다고 생각합니다. 즉, 무슨 일이 일어나고 있는지 보여주는 명령어를 실행하고, 그 출력을 여기에 공유하며, 상황을 분석하는 것입니다.
소형 시스템에서 소규모 규모의 포럼을 실행하는 것은 가능하고, 핵심 기능으로서도 가능해야 합니다.