GCP Compute Engine에서 e2-micro 인스턴스로 포럼을 시작하려고 합니다. 처음 실행을 시도했을 때 2GB 스왑파일이 생성된 것 같습니다.
기억이 정확하지는 않지만 10GB는 용량이 부족해서 작동하지 않았던 것 같아서 20GB로 늘렸습니다.
./launcher rebuild app 명령을 실행한 후 프로세스가 시작되었습니다. ...[@embroider/webpack 단계에서 처리 시간이 너무 길어서 잠시 자리를 비웠다가 약 2시간 후에 돌아왔습니다.
작업은 완료되어 있었지만, VM의 외부 IP에 Namecheap A 레코드를 연결해 두었음에도 포럼에 접근할 수 없었습니다.
다시 시도해 보았는데, 전체 로그는 다음과 같습니다(로그가 너무 깁니다):
GCP e2-micro discourse logs.txt (176.7 KB)
그런데도 제 Discourse 사이트는 작동하지 않습니다. 다음 오류가 표시됩니다:
nginx
되게 만들었어요! 신경 쓰지 마세요. 제가 한 건 없어요. 알아서 해결됐어요.
containers/app.yml에서 Unicorn 워커를 1로 줄여 메모리를 절약한 뒤, ./launcher rebuild app로 앱을 다시 빌드하면 효과가 있을까요?
또는 인스턴스를 일시적으로 e2-small 이상으로 업그레이드하고, 재빌드를 완료한 후 다시 e2-micro로 리사이즈하는 방법도 있습니다.
이미 재구축하는 데 약 2시간이 걸렸습니다. 세 번째로 또 그 정도를 기다리고 싶지는 않네요.
그리고 다른 이야기인데, 제 이메일이 지금은 작동하지 않습니다.
이메일은 이제 잘 작동하지만, 플러그인 설치 시 리빌딩에 약 2시간이 걸려서 걱정이 됩니다. 이 정도는 정상적인 시간이 아니라고 생각하는데, VM의 리소스를 변경하지 않고 속도를 높이는 방법이 있을까요?
새로 설치한 건가요? 아니면 기존 사이트를 새 서버로 이전하면서 새로 설치한 건가요?
제 경험상 2시간은 꽤 긴 시간이네요.
새로 설치했습니다. 서버의 vCPU가 0.25라서 그런 걸까요..?
그럴 수도 있겠네요. 제가 여쭤봐도 괜찮다면 VP의 시스템 사양이 어떻게 되나요?
꽤 오래전에 일이었습니다. 제가 자원봉사자로 관리하던 서버 중 하나가 기본 20GB VP를 사용 중이었죠. 데이터베이스가 아무리 크더라도 보통 15분 정도밖에 걸리지 않았습니다.
결국 클라이언트는 서버가 심각하게 크래시 난 후 더 큰 서버로 이동을 강제로 해야 했습니다. 그 당시에는 제가 
서버가 곧 크래시 날 것이며 커맨드라인으로 더 이상 재빌드할 수 없다고 경고했지만 무시했습니다.
그래서 여기 회원 한 명에게 256GB 플랜의 새 서버로 이전을 맡겼습니다. 문제를 무시한 대가로 약 2.5주라는 상당한 다운타임을 감수해야 했습니다.
다행히도 이제는 경고를 받을 때 대부분 더 잘 듣는 편입니다.
0.25 vCPU와 1GB RAM이라고 생각합니다. 설정 과정에서 2GB의 스왑파일이 생성되었습니다. 원래 서버에는 10GB의 저장 공간이 제공되었지만, 설치 중 남은 공간이 약 1.7GB밖에 없어서 계속 진행하려면 더 많은 공간이 필요하다고 표시되었습니다. 그래서 20GB로 확장했는데, 아직까지 저장 공간 관련 경고는 나타나지 않았습니다.