운영 체제, 상시 서비스, 현실적 동시성을 위한 메모리를 여유를 두고 선택하십시오. 어떤 작업이 바쁜지, 병렬로 실행되는지, 사용자가 실제로 겪는 지연이 무엇인지 측정한 후 CPU을 선택하십시오.
일상 작업과 혼잡 작업을 구분하여 설명하십시오.
방문자 수만으로는 크기 산정 입력으로 부족합니다. 한 요청은 캐시된 파일을 제공할 수 있지만 다른 요청은 보고서를 생성하거나 많은 테이블을 쿼리할 수 있습니다. VPS을 공유할 웹 워커, 데이터베이스, 캐시, 큐 소비자, 유지보수 작업을 나열하십시오. 일반적인 동시성과 가장 바쁠 것으로 예상되는 작업을 설명하십시오. 예약된 내보내기, 패키지 업데이트, 배포를 보이지 않는 백그라운드 활동으로 취급하지 말고 포함하십시오.
기존 프로젝트의 경우 혼잡 시간대를 포함한 대표 기간을 수집하십시오. 자원 사용량과 함께 응답 시간과 오류를 기록하십시오. 신규 프로젝트의 경우 현실적인 요청 형태와 데이터 크기로 작은 테스트를 만드십시오. 초기 추정은 불완전할 수 있습니다. 유용한 목표는 배포 후 측정된 동작과 비교할 수 있는 문서화된 출발점입니다.
프로세스를 추가하기 전에 메모리 예산을 구성하십시오.
메모리 수요는 시스템, 상시 애플리케이션 서비스, 워커별 사용량, 임시 작업에서 발생합니다. 워커의 사용량에 계획된 동시성을 곱하는 것은 대략적인 계획 도구일 뿐 보장이 아닙니다. 공유 메모리와 캐시가 총량을 복잡하게 만들기 때문입니다. 부하 상태의 실제 프로세스를 관찰하십시오. 유지보수 작업이 애플리케이션으로 하여금 남은 모든 페이지를 두고 경쟁하게 만들지 않도록 충분한 여유를 두십시오.
데이터베이스 설정은 예상치 못하게 메모리 사용을 배가할 수 있습니다. PostgreSQL 문서에 따르면 work_mem은 쿼리 작업에 적용되며, 여러 작업이나 세션이 동시에 실행될 수 있습니다. 따라서 단독으로 보면 적당해 보이는 설정이 시스템 전체에 더 큰 영향을 줄 수 있습니다. 데이터베이스 자체 지침을 읽고, 현실적인 동시성을 테스트하며, 광고된 모든 기가바이트를 단일 캐시에 할당하지 마십시오.
CPU 활용률과 유용한 병렬성을 구분하십시오.
프로세서 수는 게스트에 제공되는 실행 자원의 수를 알려줄 뿐, 소프트웨어가 이를 얼마나 효율적으로 사용할 수 있는지는 알려주지 않습니다. 하나의 바쁜 스레드가 애플리케이션을 제한하는 동안 다른 코어는 조용할 수 있습니다. 워커를 추가하면 독립적인 요청에 도움이 될 수 있지만 데이터베이스 경합과 메모리 수요도 증가할 수 있습니다. 코어 수가 두 배면 처리량도 두 배라고 가정하기 전에 애플리케이션의 동시성 모델을 확인하십시오.
KVM은 자체 가상 하드웨어를 갖춘 가상 머신을 제공합니다. 그러나 모든 vCPU 레이블이 호스트와 프로세서 세대 전반에 걸쳐 동일한 벤치마크가 되는 것은 아닙니다. 가능한 경우 명시된 CPU 모델과 할당 조건을 비교한 다음, 자체 워크로드로 서비스를 평가하십시오. 애플리케이션과 유사하지 않은 짧은 합성 점수로 구매 결론을 내리지 마십시오.
평균만 보지 말고 압박과 대기를 찾으십시오.
시스템은 평균 CPU 비율이 높지 않아도 느리게 느껴질 수 있습니다. 프로세스가 스토리지, 메모리 회수 또는 다른 서비스를 기다릴 수 있습니다. Linux 커널의 Pressure Stall Information은 지원되는 시스템에서 CPU, 메모리, I/O 지연 정보를 노출합니다. 이러한 신호는 일반적인 활용률 지표 및 애플리케이션 타이밍과 함께 자원 경합을 식별하는 데 도움이 될 수 있습니다.
지표를 함께 읽으십시오. 지속적인 메모리 압박, 스왑, 할당 실패, 느린 요청은 단일 바쁜 컴퓨트 워커와는 다른 개입을 가리킵니다. 스토리지 대기는 쿼리 변경이나 다른 디스크 프로필을 정당화할 수 있습니다. 외부 API 지연은 로컬 RAM을 추가한다고 해결되지 않습니다. 어떤 자원을 늘릴지 선택하기 전에 관찰된 제약을 설명하십시오.
| 관찰된 동작 | 조사할 질문 | 가능한 다음 단계 |
|---|---|---|
| 하나의 스레드가 바쁘고 여유 코어는 조용함 | 이 작업을 병렬로 실행할 수 있습니까? | 작업을 개선하거나 워커 설계를 변경하십시오. |
| 보고서 생성 중 메모리 압박 | 얼마나 많은 작업이 중첩됩니까? | 동시성을 제한하거나 테스트된 여유를 추가하십시오. |
| I/O 대기가 있는 느린 요청 | 어떤 읽기 또는 쓰기가 지연됩니까? | 쿼리와 스토리지 동작을 점검하십시오. |
| CPU 및 메모리 부족, 느린 요청 | 의존성이 응답을 지연시키고 있습니까? | 다운스트림 호출을 측정하십시오. |
명시적 가정이 있는 계획 예시
두 개의 웹 워커, 데이터베이스, 하나의 큐 소비자가 있는 작은 애플리케이션을 상상해 보십시오. 팀은 일반 요청과 보고서 생성 작업 중 해당 서비스를 측정합니다. 보고서를 한 번에 네 개 허용하면 정상 트래픽을 지연시키면서 메모리 수요가 급증한다는 사실을 발견합니다. 즉시 가장 큰 요금제를 구매하는 대신 보고서 동시성을 제한하고 결과를 다시 측정합니다.
조정된 워크로드가 여전히 더 많은 메모리를 필요로 한다면, 이제 업그레이드는 관찰된 요구사항에 대한 답이 됩니다. 큐가 여전히 CPU에 제한되고 독립적인 작업이 동시에 실행될 수 있다면 더 많은 실행 자원이 적절할 수 있습니다. 이는 예시적 결정이며 SwissOctet 요금제의 성능 수치가 아닙니다. 선택한 구성과 함께 자체 측정값과 제약을 유지하십시오.
다음 측정을 위한 명확한 경로를 남기십시오.
검토를 촉발할 징후를 정의하십시오. 응답 시간 악화, 반복되는 메모리 압박, 증가하는 큐, 변경된 워크로드 등입니다. 모니터링이 새로운 병목이 되지 않을 만큼 가볍게 유지하십시오. 기능이나 주요 데이터셋을 추가한 후 재평가하고, 실제 문제가 무제한 프로세스나 느린 쿼리일 때 반복적인 업그레이드를 피하십시오.
SwissOctet의 VPS 패밀리는 CPU 및 메모리 사양과 선택된 자원 옵션을 제공합니다. 추가 항목을 더한 후 청구 기간과 총액을 포함한 최종 구성을 읽으십시오. 업그레이드 조건에 의존하기 전에 실제 운영자와 확인하십시오. 유용한 VPS 크기는 측정된 워크로드를 합리적인 여유와 이해 가능한 다음 단계와 함께 실행하는 크기입니다.
실용 체크리스트.
- 서비스와 유지보수 작업을 목록화하십시오.
- 일반 및 혼잡 시간대 동시성을 측정하십시오.
- 상시 및 임시 메모리를 예산에 반영하십시오.
- CPU 작업이 병렬로 실행될 수 있는지 확인하십시오.
- 압박, 활용률, 애플리케이션 타이밍을 비교하십시오.
- 구성을 검토할 시점을 정의하십시오.
중요한 세부 사항.
월간 방문자 수로 VPS 크기를 산정해야 합니까?+
방문자 수를 맥락으로 사용한 다음 요청 복잡성, 동시성, 데이터 크기, 백그라운드 작업을 측정하십시오. 같은 방문자 수라도 서로 다른 부하를 만들 수 있습니다.
RAM이 많을수록 항상 서비스가 빨라집니까?+
아니요. 메모리가 제약이거나 유용한 캐싱을 가능하게 할 때 도움이 되지만, 모든 CPU, 스토리지 또는 외부 의존성 지연을 해결하지는 않습니다.
vCPU 수가 두 배면 성능도 두 배가 됩니까?+
아니요. 병렬성, 프로세서 특성, 경합, 애플리케이션 설계가 추가 용량이 얼마나 유용한지를 결정합니다.
출처로 이동하세요.
이 참고 자료는 이 가이드의 기술 개념을 뒷받침합니다. 프로덕션 시스템을 변경하기 전에 최신 문서를 확인하세요.
- Linux 커널: Pressure Stall Information docs.kernel.org
- PostgreSQL: 자원 소비 www.postgresql.org
- KVM 프로젝트: 커널 가상 머신 www.linux-kvm.org
SwissOctet의 편집 지침. 예시는 설명용입니다. 서비스 사양, 사용 가능한 옵션 및 계약 조건은 별도로 확인해야 합니다.