방금 구매한 VPS에는 3GB RAM + 1GB 파티션 스왑이 포함되어 있습니다. 스왑 파일도 별도로 설정해야 하나요, 아니면 이 정도면 충분한가요?
작은 Discourse 인스턴스라면 이 정도면 충분합니다.
제가 말하려는 건 실행 속도 같은 문제가 아니라, 예를 들어 추가 메모리를 할당하지 못하는 등의 오류가 발생하느냐의 여부입니다. 제 질문이 잘 전달되었나요? 또한, 더 낮은 우선순위의 파일 스왑을 추가하는 것이 도움이 될까요? 확실하게 알고 싶어서요.
RAM이 최소 8GB인 더 강력한 VPS를 구매하세요. 그렇지 않으면 시간을 낭비하게 될 것입니다.
이것은 제 질문에 대한 답이 아닙니다.
RAM 8GB 미만으로 Discourse를 실행하는 것은 상상할 수 없습니다.
Discourse 팀 구성원이 괜찮다고 하니까, 괜찮은 거겠죠.
행운을 빕니다.
Discourse-setup은 모든 메모리 문제를 표시합니다.
이 답변도 제 질문에 답이 되지 않습니다. 제가 질문을 잘못 표현한 걸까요?
Digital Ocean의 2GB 메모리/50GB 디스크 드롭릿에서 비교적 조용한 포럼을 운영하고 있으며, 잘 작동하고 있습니다.
당시 Discourse 설치 가이드는 최소 1GB를 권장하고 있었지만, 어느 시점에 업그레이드했습니다.
포럼의 규모나 활동량에 대해 더 많은 정보를 제공하시면 더 자세한 답변을 얻으실 수 있을 것입니다.
Discourse 설치 프로그램이 스왑 파일을 자동으로 설정한다고 생각합니다(수동으로 아무것도 하지 않았습니다) - 따라서 질문에 대한 일부 답변이 될 것 같습니다.
기존 스왑 파일이 없음을 감지하면 설치 시 2GB 크기의 스왑 파일을 생성한다고 생각합니다.
수정: 다음 내용이 더 정확합니다:
공식적으로 지원되는 최소 사양은 RAM 1GB + 스왑 2GB입니다. 꽤 작은 규모의 포럼이라면 이 정도면 충분합니다. 다만, 업데이트가 진행될수록 요구 사양이 조금씩 커지므로, 언젠가는 부족해질 수 있을 것으로 예상됩니다.
포럼이 정상적으로 작동하고 크래시가 일어나지 않도록 하려면, RAM과 스왑의 총합이 중요한 수치입니다.
포럼이 반응이 빠르고 너무 느리지 않으려면 더 많은 RAM이 권장됩니다. 따라서 RAM 1GB + 스왑 2GB가 충분하다면, RAM 3GB + 스왑 1GB도 충분할 것이며 성능이 더 좋을 수도 있습니다.
저는 포럼을 두 개 운영하고 있는데, 둘 다 규모가 꽤 작습니다. 하나는 1+2 구성으로, 다른 하나는 2+2 구성으로 실행되고 있습니다.
지난해 저는 이렇게 적었습니다:
수정: 디스크 공간이 충분하다면 스왑을 추가하세요. 추가하지 않을 만한 좋은 이유는 없으며, 필요할 수도 있습니다. free 명령어로 사용량이 얼마인지 알 수 있고, vmstat 명령어로 실시간 상태를 확인할 수 있습니다. 하지만 평균 사용량은 중요하지 않으며, 피크(최대) 사용량이 중요합니다.
네, 제 질문은 좀 더 이론적인 측면에서입니다. 현재 시점에서 포럼의 인기 정도를 예측할 수 없습니다. 제가 이해하려는 것은 특정 시나리오에서 RAM이 고갈될 수 있는 이론적인 가능성을 어떻게 완화할 수 있는지에 대한 것입니다. Discourse가 메모리를 가장 많이 소비하는 시점이 언제인지 잘 모르겠습니다 - 백업 생성 시, 이미지 리사이즈 시, 관리자 콘솔을 통한 업데이트 시, 아니면 … 전혀 감이 잡히지 않습니다.
그래서 제 생각은, 메모리가 부족할 경우 Discourse가 죽지 않고 단지 매우 느려지는 것을 보장하기 위해 어떤 스왑 파일을 만들어야 하는지에 대한 것이었습니다. 동시에 이미 1GB의 스왑 파티션이 있다는 사실을 알게 되었고, 그렇다면 3GB의 실제 메모리 + 1GB 파티션 스왑이 충분하지 않을 경우 어떻게 해야 할지, 파티션 기반 스왑보다 우선순위가 더 낮은 몇 GB 크기의 스왑 파일도 만들어야 하는지 고민했습니다. 이제 제 질문이 더 명확해졌기를 바랍니다.
그렇다면 네요. 설치 readme 파일을 업데이트하는 것이 유용할 것입니다. 과거에는 설치 readme 파일에서 스왑 파일을 직접 생성하도록 공식적으로 언급되었던 시절이 있었는데, 이제는 자동으로 처리되는지, 더 이상 필요하지 않은지, 아니면 공식 howto에서 제거된 다른 이유가 있는지 조금 혼란스럽습니다.
… 만약 1GB 파티션 기반 스왑을 감지한다면 어떻게 되나요?
따라서 제 질문의 후속 부분은, 파티션 기반 스왑 영역 하나와 파일 기반 스왑 영역 하나를 모두 가지는 것이 좋은 아이디어인지입니다.
여러 개의 스왑 영역(또는 실제로 여러 개의 스왑 파일)을 사용하는 데는 전혀 문제가 없습니다.
가장 큰 메모리 피크는 업그레이드 중에 발생한다고 생각하며, 이때의 위험은 도움이 받을 때까지 포럼이 다운된 상태로 유지될 수 있다는 것입니다.
오버커밋(overcommit)을 더 관대한 설정으로 변경하는 것도 가치가 있습니다. 아직 조정하지 않았다면 업그레이드 로그에 이미 관련 내용이 기록되어 있을 것입니다.
WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add ‘vm.overcommit_memory = 1’ to /etc/sysctl.conf and then reboot or run the command ‘sysctl vm.overcommit_memory=1’ for this to take effect.
이전에 여러 번 언급되었지만, 표준 Discourse 설치 레시피에 이를 추가하는 데는 저항이 있습니다. 이는 도커 이미지 내부에서 설정할 수 없고 호스트에서 수행해야 하는 유형의 설정입니다.
당신이 할 수 있는 일은 위험을 줄이는 것뿐이며, 더 많은 자금이 있다면 위험을 더 큰 폭으로 줄일 수 있습니다. 이 질문은 트레이드오프의 영역에 속합니다!
저에게 무제한의 디스크 공간이 있다면, 고민조차 하지 않고 4GB까지 스왑을 추가했을 것입니다. 아무런 해가 되지 않으니까요. 무제한의 자금이 있다면, 구할 수 있는 최대 RAM을 갖췄을 것입니다. 하지만 제 경우에는 그렇지 않습니다.
포럼이 성장할 것으로 예상한다면, 처음에 한 번만 하드웨어 규모를 정하는 것보다 시간이 지나면서 운영에 필요한 자원을 점진적으로 늘려나갈 것을 예상해야 합니다.
저는 아직 포럼에 사용하는 서버의 크기를 늘리지 않았지만, 올해 또는 내년쯤에는 늘릴 것으로 예상합니다.
그렇게 되어야 합니다. 저는 일상적으로 1GB와 2GB의 드롭렛에 2GB의 스왑을 설정해서 사용하는데 잘 동작합니다. 현재 재빌드에는 RAM이 많이 필요하지만, 그 정도는 문제없이 작동할 것입니다.
상상력이 더 필요해 보입니다.
저는 월 페이지뷰가 약 100만 건 수준이고 데이터베이스가 상당히 큰 사이트에서만 그 정도 용량을 사용합니다.
저는 처음 Discourse를 설치했을 때 이 문제를 언급했습니다(Warnings: overcommit_memory and Transparent Huge Pages). 왜 이 설정을 하는 것이 가치 있는지, 그리고 저항의 이유는 무엇인가요? 저는 기본 설정을 변경하지 않았습니다.
제가 이전에 작성한 내용이 있습니다:
특히 다음 부분을 참고해 주세요.
기본 상태에서는 커널이 충족할 수 없는 할당을 거부합니다. 이 조정을 통해 이러한 할당을 허용하게 되면 실패를 피할 수 있거나, 할당이 실제 사용으로 전환될 때 나중에 실패가 발생할 수 있습니다.
RAM과 스왑의 총 용량이 충분히 크다면 이 설정을 변경할 필요가 없습니다. 총 용량이 충분하지 않다면, 변경하는 것이 도움이 될 수 있습니다.
또한
이는 사용 가능한 가상 메모리 양을 늘리기 위한 것입니다. (즉, RAM과 스왑의 합입니다.) RAM이 소진되면 성능 문제가 발생하기 시작합니다. 하지만 가상 메모리가 소진되면 프로세스가 시작되지 않거나 종료되거나 강제 종료됩니다. 상황이 매우 심각해집니다.
RAM과 디스크 용량이 모두 작은 경우, 스왑을 대량으로 추가할 자유가 없을 수 있지만, 2GB가 좋은 최소값인 것 같습니다. (RAM이 16GB라면 스왑이 전혀 필요 없을 수 있지만, 그것은 별개의 이야기입니다. 문제가 프로세스 실패인 경우, 두 가지를 합한 총량이 중요합니다.)
저항에 대해서는, 이 변경이 Redis의 이익을 위한 것으로 인식되고 대부분의 사용자에게는 필요하지 않을 것이라는 인식이 원인이라고 생각합니다.
수정: 최근 이 스레드는 작은 인스턴스가 메모리를 소진하고 overcommit이 설정되어 있지 않았던 사례로, 적절한 예시가 될 수 있습니다. 하지만 overcommit을 설정했으면 이 문제를 해결할 수 있었는지는 알 수 없습니다. 해당 사용자는 RAM을 8GB로 업그레이드했습니다.