디스크 공간 문제 외에도 업그레이드 프로세스가 드롭렛에 할당된 가용 메모리(1GB)를 초과했을 가능성은 없는지 궁금합니다. 위 콘솔 스크린샷에서 ./launcher rebuild app 실행 후 첫 번째로 기록된 항목으로 'Out of memory’가 언급되는 것을 확인하실 수 있습니다.
참고하지 못한 점은, 해당 시도를 한 후 콘솔이 응답을 멈췄다는 것입니다(그 시점에는 Digital Ocean 제어판의 웹 기반 콘솔을 사용 중이었는데, 이 콘솔은 항상 불안정합니다). 이후 저는 드롭렛의 전원을 재시작했습니다. (그 이후로는 PuTTY를 사용했습니다.)
어쨌든, 동일한 메모리 및/또는 디스크 문제를 겪었을 것으로 추정되는 상황에서 업데이트가 Discourse 업그레이드 페이지를 통해 성공으로 보고된 것은 좋은 상황이 아닙니다.
아, 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
2GB 스왑 파일이 실제로 사용되고 있지 않다면 좋지 않은 상황이 될 것입니다. 디스크 공간을 사용하지 않고 스왑을 추가할 수 없다는 점도 문제입니다.
업그레이드를 위해 디스크 공간을 확보하는 방법 중 하나는 모든 백업 파일을 외부로 복사한 후 무결성을 확인하고 서버에서 삭제하는 것입니다. 업그레이드 과정에서 혹시 모를 사태에 대비해 안전하고 최신 상태의 백업이 어딘가에 꼭 필요하지만, 반드시 서버 자체에 있을 필요는 없습니다. 저는 최신 백업 하나만 남기고 나머지를 모두 삭제하는 것에 대해 편안함을 느낄 수 있지만, 반드시 오프라인으로 사본을 만들어 두겠습니다.
이제 모든 정리 작업을 마쳤으므로, du 명령어의 결과를 다시 확인해 보는 것이 좋습니다.
궁금한 점이 있습니다: 1GB가 RAM 할당량이고 25GB가 디스크 할당량인가요? 둘은 매우 다른 개념입니다.
수정: 지원되는 표준 권장 사양은 RAM이 1GB보다 훨씬 많아야 한다는 것으로 알고 있습니다.
수정: 아니요, 표준에 따르면 1GB가 여전히 권장되는 최소 사양입니다.
방금 다시 연결했는데, 콘솔 창이 열릴 때 보고된 시스템 정보는 다음과 같습니다.
System load: 0.01 Processes: 136
Usage of /: 59.4% of 24.06GB Users logged in: 0
Memory usage: 73% IP address for eth0: 159.65.140.176
Swap usage: 17% IP address for docker0: 172.17.0.1
즉, 스왑 사용량 17%는 4GB를 의미합니까?
포럼에 로그인한 사람이 없고 현재 활성 상태인 연결이 PuTTY를 통한 드롭렛 연결뿐인데도 RAM 사용률이 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:~#
journalctl을 사용하여 이를 개선할 수 있을 것 같습니다.
# journalctl --vacuum-size=50M
(업그레이드를 시도하기 직전에 이 작업을 수행할 수 있습니다)
postgresql 사용량이 감소하지 않은 것이 흥미롭네요.
free 명령어는 스왑 사용량을 보여줍니다: 어떤 양의 17%가 사용 중이며, 아마도 2G일 것입니다.
당신의 머신이 다소 비좁다는 것이 명확합니다: 더 많은 RAM이나 더 많은 스왑이 필요하며, 디스크 용량을 늘리지 않고서는 실질적으로 스왑을 크게 늘릴 수 없습니다.
죄송합니다 - 말씀이 맞습니다. 1GB는 디스크 용량이 아니라 RAM이었습니다.
정말 정확하시네요.
root@nz:~# free
total used free shared buff/cache available
Mem: 1008828 655660 61716 102288 291452 96576
Swap: 2097148 459776 1637372
업그레이드 프로세스가 시작되기 직전에 호스트 시스템이 업그레이드를 수행할 수 있는 용량을 평가해야 하는 것은 아닐까요?
이것은 다소 미래를 예측하는 범주에 속한다고 생각합니다. 5GB 디스크 공간에 대한 확인은 분명 도움이 되지만, 완벽할 수는 없습니다. 사용 가능한 RAM은 더 어렵습니다. 얼마나 필요한지 파악하기가 상당히 까다롭기 때문입니다. 이는 포럼의 규모가 얼마나 커졌는지에 따라 달라질 것이며, 아마도 각 업그레이드 과정에서 어떤 부분을 수정해야 하는지에 따라 달라질 것이라 생각합니다.
저는 비용을 최소화하는 데 주의를 기울이기 때문에, 저렴한 서버에 맞추기 위해 시간을 들입니다. 하지만 결국 포럼이 성장함에 따라, 상위 단계의 서버로 이동하는 것이 가치가 있을 것입니다. 비용은 들겠지만, 시간과 노력을 절약할 수 있을 것입니다.
안타깝게도 저는 비용 최소화에 초점을 맞출 수밖에 없습니다. 이 포럼은 순수하게 자원봉사 기반으로 운영되며 수익을 내지 않고, 사용자들의 요구로 이메일 기반 게시 기능(MailGun을 통해)이 추가되면서 현재처럼 유지하는 데 매월 약간의 비용이 듭니다.
취미라고 생각하면, 나이트클럽에서 술 마시는 것보다 훨씬 저렴하다고 할 수 있겠네요!