2+2가 더 이상 충분하지 않을 것 같습니다… 저는 비교적 무난한(크거나 화려한 플러그인 없음) Discourse 인스턴스를 관리하고 있는데, 오늘부터는 부트스트랩에 실패하고 있습니다. ember가 찾을 수 있는 모든 RAM과 모든 스왑을 잡아먹으면서 기기가 응답하지 않는 상태까지 몰고 가고 있기 때문입니다. 스왑을 2GB 추가로 확보하니 부트스트랩이 완료되었고, 스왑 사용량 정점은 약 2.5GB였습니다.
아, 이건 @david가 조사할 목록에 있는 항목이에요.
@david 님이 조사를 진행 중이며, 현재로서는 2GB가 Docker 재빌드에는 충분하지만 웹 업그레이더 실행에는 부족하다는 점을 확인했습니다.
웹 업그레이더 실행 중에 모든 Ruby 프로세스를 종료하여 300~500MB의 추가 메모리를 확보하는 방안이 하나 있습니다. 이렇게 하면 에셋 프리컴파일(Asset Precompilation)에 필요한 충분한 메모리가 확보됩니다.
셀프 호스터(Self hosters)를 위한 장기적인 접근 방식으로는 부트스트랩이 완료된 컨테이너를 제공하는 것이 될 가능성이 높습니다. 하지만 이는 판도라의 상자 같은 문제입니다. 웹 업그레이더가 이를 어떻게 처리할 수 있을지 불분명하기 때문입니다. Docker 소켓을 마운트하는 것은 원하지 않습니다.
정말 난감한 상황이네요.
글쎄요, 제게는 그렇지 않았습니다.
이것은 기본 순수 설치 환경과 실제 상황 간의 비교인가요?
실제로, 완벽하게 일관되지는 않습니다. 다른 모든 것을 종료해도 여전히 실패할 수 있습니다.
불행히도 우리는 현대적인 JS 빌드 도구를 상대로 싸우고 있습니다. 이 모든 것은 1GB VPS가 아니라, 최신 개발자 머신의 8GB 이상의 RAM에서 실행되도록 설계되어 있습니다. 
우리는 몇 가지 해결책을 구상하고 있습니다. 예를 들어, 자동으로 다운로드할 수 있는 사전 빌드된 에셋을 제공하는 것입니다. 우리가 직면한 큰 도전은 플러그인인데, 이는 모든 사이트에서 다양하며, 현재 핵심 빌드에 긴밀하게 통합되어 있기 때문입니다.
하지만 지금은, 웹 UI 업데이트보다 전체 CLI 재빌드 실행이 더 높은 성공률을 가질 것으로 예상됩니다.
Jagster와 마찬가지로, 2GB RAM + 2GB 스왑은 제 CLI 기반 docker 재빌드에 실제로는 충분하지 않습니다. 추가로 확인해보니 이 설치 환경에 있는 플러그인은 docker_manager와 discourse-prometheus뿐인데, 이 둘 중 어느 것도 예상치 못한 부하를 ember에 가할 것이라고는 생각하지 않습니다.
최소 사양이 변경되어야 한다면 그것은 아쉬울 것ですが, 예상치 못한 시점에 모든 업그레이드마다 기계가 마비되는 현재의 상황보다는 훨씬 나을 것입니다.
그렇다면 권장 사양을 조금 높이는 것이 여전히 나을 것 같습니다. 개인적으로 재빌드가 더 안정적으로 이루어진다면 스왑 공간을 2GB(또는 4GB) 더 추가하는 것에 대해 크게 신경 쓰지 않습니다. 다만, 소규모에서 중규모 커뮤니티의 경우 일상적인 운영이 여전히 2~4GB의 RAM으로 원활하게 이루어진다면요.
실제로 최근 4코어 4GB 인스턴스에서 초기 설치 시 실패했습니다. Ed가 스왑 파일 생성을 제안했고, 스왑을 생성하는 방법을 찾아 4GB 스왑을 만들었습니다. 이제 웹이나 CLI를 통한 업데이트/업그레이드가 모두 예상대로 정상 작동합니다.
제 생각에는 Discourse가 과거보다 더 많은 RAM이 필요하다는 점을 받아들여야 할 것 같습니다.
zram을 사용하는 것이 합리적이지 않을까요?
방금 이 커밋을 병합했는데, 상황이 개선되길 바랍니다. 결과를 알려주세요! (약 30분 이내에 tests-passed에 반영될 예정입니다)
로컬에서 메모리가 제한된 docker 컨테이너로 테스트해 보니, 이제 -m 1600m로 성공적인 빌드를 수행할 수 있습니다. 이 변경 사항 이전에는 최소 -m 3000m까지 줄일 수 있었습니다.
다양한 환경에서 깨끗한 설치와 재구성을 통해 제어된 실험을 해보고 싶습니다. 특히 vm 오버커밋(overcommit)을 활성화한 상태에서 실행했을 때의 차이(있다면)를 확인해 보고 싶은데, 아쉽게도 시간이 부족했습니다.
(오버커밋이 비활성화된 경우, 포크(fork)하는 대규모 프로세스는 메모리 사용량이 순간적으로 증가하여 치명적인 결과를 초래할 수 있으며, 이는 폴링 방식의 모니터링에서는 감지되지 않습니다. 오버커밋이 활성화되어 있더라도, htop이나 vmstat 등 어떤 도구를 사용하든 메모리 증가 속도가 너무 빨라서 폴링을 통해 감지되지 않을 수 있습니다.)
오버커밋을 사용 중인지 여부에 대해 스스로 보고하는 사람을 본 적이 거의 없는데, 제 생각에는 이는 호스트 설정에서 매우 중요한 측면입니다.
대부분의 사람이 그렇지 않다고 봅니다.
저는 설치할 때 자동으로 설정합니다. 하지만 여전히 그에 대한 경고 메시지가 표시됩니다.
여기서는 overcommit이 관련이 없습니다. 문제는 프로세스가 너무 일찍 OOM-kill되는 것이 아니라, 5파운드짜리 주머니에 10파운드짜리 할당된 메모리를 억지로 쑤셔 넣으려는 시도이기 때문입니다.
실제로 overcommit_memory=2로 Discourse 재빌드를 실행하는 것은 불가능합니다. 왜냐하면 ember(물론 다른 것들도 있겠지만)가 대량의 가상 메모리를 사전에 할당하기 때문입니다(기억이 맞다면 제가 확인한 바에 따르면 약 80GB였습니다). 따라서 이는 어떤 합리적인 overcommit_ratio 설정에서도 항상 실패하게 됩니다. overcommit_memory=1을 설정하는 것도 도움이 되지 않습니다. 다시 말하지만, 문제는 과도하게 엄격한 VMM이 프로세스를 종료시키는 것이 아니라, ember 컴파일러의 끔찍하게 나쁜 메모리 관리 때문입니다.
저는 당신의 분석에 완전히 동의하지는 않습니다! 제 이해로는, overcommit은 프로세스가 실제로 접근하지 않는 메모리를 할당할 수 있게 해줍니다. 단순히 OOM-killer의 동작 문제만이 아닙니다. 하지만 말씀드린 것처럼, 저는 몇 가지 통제된 실험을 진행해 보고 싶습니다. 어떤 것이 실제로 차이를 만들고 어떤 것이 그렇지 않은지 확인하는 더 나은 방법이니까요.
RAM이 4GB이고 플러그인이 많습니다(스왑 파일은 없는 것으로 알고 있습니다). 몇 개의 플러그인을 사용하시나요? 그리고 순수한 4GB RAM이 충분한지 어떻게 생각하시나요?
부분적으로 맞지만, 그렇더라도 이 주제에서 논의되고 있는 문제는 프로세스가 실제로 접근하는 메모리를 할당하는 것이며, 시스템이 가용한 양보다 더 많은 메모리에 접근하여 고객에게 가시적인 장애를 일으키는 것입니다. 따라서 이 문제는 관련이 없습니다.
@david의 변경 사항 이후 메모리 요구 사항이 줄어든 것을 확인해 주실 수 있을까요? 지금은 적절한 상태가 되어야 합니다.
다음 큰 변화는 사전 컴파일 및 사전 컴파일된 자산의 배포일 것입니다. 이를 구현하기까지는 상당한 변화가 필요하지만, 완료되면 인터넷에서 많은 작업을 없앨 수 있을 것입니다.
존중의 말씀을 드리지만, 그 점에는 동의하기 어렵습니다. 포킹(forking) 실패를 보여주는 로그 파일을 여러 번 본 적이 있습니다. 이 스레드에서 우리는 "메모리 요구 사항"이라고 말하고 있지만, 제 생각에는 여기에는 커널의 가상 메모리 관리 전략도 포함됩니다. 과잉 커밋(overcommit)에 대해 제가 맞는지 틀린지는 분명히 몇 가지 실험으로 알 수 있을 것입니다.
그것은 플러그인 없이 새로 빌드한 것이었습니다. 몇 개의 플러그인을 활성화하고 스왑을 일시적으로 비활성화하여 빌드가 정상적으로 진행되는지 확인해 볼 수 있습니다. 다만, 시간이 나기까지는 며칠 정도 걸릴 것 같습니다.