리소스가 제한적인 VPS용 스위치?

지원 자체 호스팅
1

스와프는 필요 없습니다. OOM 리스크를 감수하겠습니다. RAM을 2GB 이하로 제한하기 위해 여기에 암시되는 커맨드라인 스위치가 있나요?

이 인스턴스는 최대 10명의 사용자를 가집니다. 맞습니다. 열 명입니다. 아마도 빈번하게 접속하는 사용자는 3명 정도일 것입니다.

  • 1GB의 기본 RAM은 작은 Discourse 커뮤니티에 적합합니다. 더 큰 커뮤니티에는 2GB의 RAM을 권장합니다.

따라서 환불이 불가능한 1코어 2GB 인스턴스를 프로비저닝했습니다. 이것으로 끝입니다. 업그레이드는 없습니다. 스와프는 너무 많은 공간을 차지하므로 패스합니다.

불만스럽습니다.

2

스왑 없이 컨테이너를 빌드할 수 없을 가능성이 높습니다. 스왑을 생성한 후 컨테이너를 빌드하고, 컨테이너를 종료한 뒤 스왑을 제거하는 방법을 시도해 볼 수 있습니다.

스왑은 거의 10년 동안 필수 요구사항이었습니다.

3

이 부분은 정말 혼자 해결해야 합니다. SWAP 요구 사항을 우회하려는 시도는 강력히 권장하지 않습니다. 클라우드 제공업체에 연락하여 더 큰 디스크를 프로비저닝해 달라고 요청하는 것이 좋습니다.

4

저는 두 개의 SSH 창을 사용하여 그다음 최선의 방법을 시도했습니다. 스왑 생성, 런처 실행, 다른 SSH 창에서 스왑 삭제, 런처가 계속 실행되었습니다. 이는 더 잘 프로비저닝된 VPS에서는 작동할 수 있습니다. 다음에 유휴인 인스턴스가 생기면 시도해 보겠습니다. 현재 4c12r 인스턴스에서 실행 중입니다.

주어진 조건: 리소스를 증가시킬 수 없음

제안: 리소스 증가

5

보통 업데이트 시에는 정상 서비스 운영 시보다 더 많은 메모리(RAM+스왑)가 필요합니다.

스왑 공간이 부족하다면, 포럼 데이터(데이터베이스+업로드 파일)가 필요한 공간을 차지하고 있기 때문입니다.

아래와 같은 전략을 따르는 것도 가능합니다.

  • 업데이트를 하지 않음

또는

  • 매번 데이터를 최신 상태로 설치된 새 인스턴스로 마이그레이션하기

하지만 저는 수십 년간의 시스템 관리 경험을 바탕으로 최소 사양 인스턴스에서 직접 여러 번 시도해 보았습니다. 결국 더 큰 머신을 사용하는 것이 훨씬 낫다는 결론에 도달했습니다. 사실, 더 큰 머신이 오히려 더 저렴했기 때문에 매우 바람직한 선택이었습니다. 이는 프로바이더마다 요금이 다르기 때문입니다. 저는 Digital Ocean에서 Hetzner로 이전했습니다.

6

다른 가능성은 상당한 작업이 필요하지만, 새 이미지를 다른 머신에서 빌드하고 해당 이미지를 저장소에 올린 다음 리소스가 제한된 머신에서 실행하는 것입니다.

하지만 포럼에서 실현 가능한 수준의 도움을 제공하기에는 그 범위를 벗어납니다.

7

제 생각에는 핵심 교훈은 다음과 같습니다.

그리고 단순히 앞으로 나아갈 수 있는 하나의 제안에 불과했던

이것이 아니라는 것입니다.