다음에 두 서버를 업데이트할 때, 호스팅 제공업체의 유연성을 활용하여 업데이트 전에 더 큰 RAM으로 이주하고, 업데이트 직후 다시 현재 최소 구성으로 되돌리는 방법을 사용할 계획입니다. 이로 인해 다운타임이 약간 증가하지만, 재구축(rebuild) 속도가 훨씬 빨라진다면 전체적으로 이득이 될 수 있습니다. 추가 비용은 1시간당 추가 RAM에 대해 1달러 미만, 아마도 1센트에 불과할 것입니다 (제 경우, Digital Ocean에서 시간당 과금 기준으로 월 6달러에서 월 12달러로, 각각 1센트와 2센트입니다).
링크된 스레드에서 언급했듯이, 경우에 따라 재부팅이 도움이 되므로, 제 경우에는 OS 패키지를 업데이트하고 재부팅하기에 좋은 타이밍입니다.
이것이 저에게도 덜 부담이 되기를 바랍니다.
사실 1GB에서 8GB로 업그레이드하는 것을 선택할 수도 있습니다. 시간당 6센트가 추가되지만, 이를 통해 스왑파일을 일시적으로 삭제할 수 있는 자유를 얻고 디스크 공간 부족 문제를 완화할 수 있습니다.
모든 것이 업데이트 시점에 피크에 도달합니다. 그 외 시간에는 현재 최소 구성으로도 충분해 보입니다.
확실히 비용과 시간 사이의 트레이드오프의 일부입니다. 제 경우, 업그레이드를 위해 1시간의 베이비시팅을 이미 계획해 두었고, 이 시스옵(시스템 관리) 절차를 완전히 알고 있으므로 시간은 이미 확보된 상태입니다. 시간이 좀 더 걸리더라도 월 운영 비용을 최대한 낮게 유지하는 것을 선호합니다. 물론 다른 분들은 다른 트레이드오프를 선택할 수 있겠죠.
참고로, 방금 두 개의 포럼을 업데이트했는데, 두 경우 모두 일시적으로 RAM을 8GB로 늘렸다가 다시 원래대로 되돌린 상태였습니다. 두 경우 모두 경과 시간이 1시간 이내로 완료되었습니다. 이 특정 단계는 (일시적으로) 4개 CPU와 8GB RAM 환경에서 약 5분 정도 걸렸습니다.
I, [2024-01-10T16:07:58.323464 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake themes:update assets:precompile'
110:M 10 Jan 2024 16:08:52.047 * 100 changes in 300 seconds. Saving...
110:M 10 Jan 2024 16:08:52.048 * Background saving started by pid 3276
3276:C 10 Jan 2024 16:08:52.384 * DB saved on disk
3276:C 10 Jan 2024 16:08:52.386 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 0 MB
110:M 10 Jan 2024 16:08:52.449 * Background saving terminated with success
Purging temp files
Bundling assets
MaxMind IP database updates require a license
Please set DISCOURSE_MAXMIND_LICENSE_KEY to one you generated at https://www.maxmind.com
MaxMind IP database updates require a license
Please set DISCOURSE_MAXMIND_LICENSE_KEY to one you generated at https://www.maxmind.com
I, [2024-01-10T16:12:14.362017 #3300] INFO -- : Writing /var/www/discourse/public/assets/break_string-cc617154cd957804f2f6a1f3bc68258c9cdca3d4b9a322bf777d145fed04790e.js
여기서 12번째 열에 있는 ember 프로세스가 6번째 열에 표시된 대로 2.5GB의 RAM을 사용하고 있으며, 3번째 열에 표시된 대로 CPU를 하나 이상 사용하고 있는 것을 볼 수 있습니다.
제 경우에는 4GB RAM으로도 충분했을 것 같습니다. 하지만 언급했듯이 이 전체 작업은 몇 센트 정도의 비용에 불과했습니다. (이제 보니, 1센트 더 지불하면 더 빠른 CPU를 선택할 수 있었음을 알게 되었습니다.)
수정: 작업을 시작하기 전에 백업을 하나 하고, 작업이 완료된 후에도 백업을 하나 더 했습니다. 두 백업 사이의 간격은 35분이었습니다. 따라서 사용자가 체감한 다운타임은 그보다 길지 않았습니다.
수정: Digital Ocean 제어판에 따르면 리사이징 작업은 디스크의 데이터 용량 1GB당 최대 1분까지 걸릴 수 있다고 합니다. 제 경우 데이터가 14GB뿐이었고, 실제로는 리사이징마다 2분 정도 걸렸습니다. 하지만 인스턴스에 데이터가 매우 많다면, 이 리사이징 과정이 더 오래 걸릴 수 있습니다. (다시 말해, 데이터가 매우 많다면 아마도 4GB 미만의 RAM으로 실행하려 하지 않을 것입니다.)
일부 경우 4GB RAM은 여전히 충분하지 않습니다. 예를 들어, 저는 트래픽이 거의 없는 8GB RAM 샌드박스를 사용하고 있지만, 5개의 일회용 샌드박스를 허용하기 위해 멀티사이트 설정으로 구성되어 있습니다. 오늘 재구축이 에러 137(OOM)으로 인해 실패했고, 위에서 @richard가 제안한 트릭을 시도해 보았습니다. 그러나 매번 이런 번거로움을 겪지 않기 위해 더 큰 스왑(4GB)을 생성했는데, 이로 인해 당분간 재구축이 이루어지는 것 같습니다. 지난 1년 동안 서버를 계속 업그레이드하고 있는 것 같은데, 어떤 이유에서인지 discourse 재구축이 정말로 RAM을 많이 소모하고 있습니다.
이것에 대해 생각해보니, 그 이점은 사실상 전체 재빌드(full rebuild)에만 제한적으로 적용되는 것 같습니다. 현재 저는 2+2 구성에서 온라인 업그레이드를 사용할 수 없거든요 … 그리고 예를 들어 단일 플러그인 업데이트를 위해 이런 업그레이드/다운그레이드 절차를 반복할 것 같지는 않습니다 …
개인적으로는 최소 4GB로 영구적으로 업그레이드하는 것이 유일한 방법이라고 생각합니다 …
참고: 시대의 흐름에 맞춰야 한다는 사실에 대해 불평하는 것은 아닙니다 … 하지만 아마도 문서와 관리자 조언에서 현실을 더 잘 반영하기 시작해야 하지 않을까요?
불행히도 이는 디스코르스(Discourse)를 새로운 사용자, 특히 젊은 사용자에게 조금 덜 접근하기 쉽게 만듭니다
저는 실제로 이 아이디어에 동의합니다: 현재 최소 권장 구성을 목표로 유지하면서, 코드의 조정이나 상류(업스트림) 변경을 통해 문제를 통제해 보자는 것입니다. 최소 구성 가격이 지금 두 배가 되었다면 이는 제공되는 서비스의 큰 변화가 됩니다. 그래서 저는 다른 곳에서 과도한 메모리 요구 사항은 버그라고 언급한 것입니다.
실제로 메모리 부족 오류입니다. 디스크 공간이 충분하다면 스왑을 추가하는 것만으로 충분할 것입니다. 다만 RAM을 추가하는 경우보다 처리 시간이 더 오래 걸립니다. 호스팅 제공업체에서 RAM을 일시적으로 업그레이드했다가 나중에 원래대로 되돌릴 수 있는 옵션을 제공하는 경우가 있습니다. 이 경우 재부팅 몇 번, 짧은 다운타임, 그리고 소액의 추가 비용이 발생할 가능성이 높습니다.
수정: 명확히 하자면, 메모리 = RAM + 스왑입니다. RAM은 빠르고 스왑은 저렴합니다.
… 그리고 예를 들어 단일 플러그인 업데이트를 위해 이런 업그레이드/다운그레이드 절차를 반복할 것 같지는 않습니다 …