실제로 실행하는 앱에 맞게 크기를 조정하세요.

측정하기 전에

애플리케이션과 대표 데이터가 있는, 사용자가 통제하는 Linux 테스트 머신을 사용하십시오. 아래 명령은 리소스를 검사하며, 커널을 조정하거나 파일을 삭제하지 않습니다. procps와 GNU coreutils, 그리고 선택한 애플리케이션 디렉터리를 검사할 권한이 필요합니다. 다음을 바꾸십시오 /srv/my-app 를 실제 경로로. 앱이 아직 어디에서도 실행되지 않는다면 개발 또는 스테이징 환경을 사용하여 초기 추정치를 구축한 다음, 의도된 시스템에서 그 추정치를 다시 검토하십시오.

VPS를 공유하는 항목을 기록하십시오: 운영 체제, 프록시, API, 데이터베이스, 워커 및 모니터링. 자산 빌드가 여기서 실행되는지, 백업이 로컬에서 압축되는지, 예약된 작업이 배포와 겹칠 수 있는지 기록하십시오. 조용한 애플리케이션 프로세스는 비용이 많이 드는 릴리스 프로세스와 공존할 수 있습니다.

사용 가능한 메모리를 읽고 프로세스를 식별하십시오

free -m
ps -eo pid,comm,rss --sort=-rss | head -n 12

free -m 는 메비바이트를 보고합니다. 다음에 집중하십시오 available, 스왑 없이 새 작업을 지원할 수 있는 메모리 추정치; free 만으로는 유용하게 회수 가능한 메모리를 제외합니다. 따라서 캐시 자체는 RAM을 더 구매할 이유가 아닙니다. 다음을 참조하십시오 free 필드 정의.

Illustrative selected fields — not an OffVPS measurement
Mem total: 2048 MiB
Mem free:   180 MiB
Mem available: 800 MiB

Illustrative ps rows
  PID COMMAND     RSS
 2100 postgres 393216
 2140 node     184320
  920 caddy     32768

위의 프로세스 RSS 값은 대략 384, 180 및 32 MiB에 해당합니다. 이는 메모리 사용 위치를 찾는 데 도움이 되지만, 모든 RSS 값을 더하는 것이 정확한 머신 총계는 아닙니다: 공유 페이지가 두 번 이상 계산될 수 있고 일부 커널 비용은 프로세스 수치 밖에 있습니다. 보고서를 수집할 때 명령 인수나 환경을 출력하지 마십시오. 비밀이 포함될 수 있습니다. ps 매뉴얼 은 해당 필드와 스냅샷 동작을 설명합니다.

관찰을 워크시트로 전환하십시오

다음 허용치는 로컬 데이터베이스와 워커 하나가 있는 작은 API를 예시합니다. 이는 발명된 계획 값이며 특정 프레임워크의 벤치마크나 최소 요구 사항이 아닙니다. 측정값으로 대체하고, 어떤 허용치가 동시에 최대치에 도달할 수 있는지 기록하십시오.

이 워크시트는 이미 1,024 MiB 예산을 초과합니다. 2,048 MiB 테스트 환경은 이 허용치에 대해 676 MiB를 남기지만, 유용한 결과는 앱이 응답성을 유지하면서 실제 대표 작업이 맞는지 여부입니다. 배포 허용치가 지배적이라면 영구 서버를 늘리는 것보다 다른 곳에서 아티팩트를 빌드하는 것이 더 나은 변경일 수 있습니다. 가정을 총계 옆에 보존하십시오.

유용한 작업 중 CPU 및 스왑을 관찰하십시오

vmstat 1 10

대표적인 요청 배치, 작업 및 릴리스 중에 이것을 실행하십시오. 최근 간격을 해석할 때 첫 번째 줄은 무시하십시오: 부팅 이후 활동을 요약합니다. 이후 줄은 샘플링 간격을 설명합니다. r, 에서 낮은 유휴 시간 id 과 느린 요청은 함께 CPU 압력을 조사할 이유가 됩니다. 반복적인 si/so 활동은 스와핑을 보여줍니다; 할당된 스왑만으로는 현재 압력을 입증하지 않습니다. wa 및 st 에는 자동 CPU 업그레이드보다 맥락이 필요합니다. 이러한 필드는 다음에 정의되어 있습니다 vmstat.

애플리케이션에서의 응답 시간도 기록하십시오. 느린 외부 API 또는 데이터베이스 쿼리는 CPU가 대부분 유휴 상태인 동안 요청을 대기하게 만들 수 있습니다. 하나의 변경 후 동일한 워크로드를 반복하여 어떤 변경이 도움이 되었는지 알 수 있도록 하십시오. 부하 테스트는 통제하는 시스템만 대상으로 해야 하며, 다른 사용자를 방해하지 않는 속도와 중지 조건을 사용하십시오.

디스크 증가와 전송을 별도로 예산에 포함하십시오

df -h /srv/my-app
df -i /srv/my-app
du -sh /srv/my-app

df 는 다른 디렉터리와 공유되는 공간을 포함하여 경로가 포함된 파일 시스템을 설명합니다; df -i 는 지원되는 경우 inode 사용을 확인합니다. 많은 수의 작은 파일은 바이트 용량보다 먼저 inode를 소진할 수 있습니다. du 는 접근 권한에 따라 선택된 트리를 추정합니다. 이들은 서로 다른 질문이므로 그 총계가 일치할 필요는 없습니다. 다음을 참조하십시오 df 및 du.

현재 데이터베이스, 업로드, 로그, 애플리케이션 아티팩트 및 로컬 백업 스테이징 공간을 나열하십시오. 이전 릴리스와 함께 릴리스에 필요한 공간을 추가한 다음 다음 검토 기간 동안의 증가를 추정하십시오. 예를 들어, 매일 100 MiB의 새 업로드는 복제본 또는 백업 전에 30 일 동안 약 3,000 MiB를 추가합니다. 결과를 카탈로그와 비교할 때 십진 GB와 이진 GiB를 일관되게 표시하십시오.

전송의 경우, 예시적 20 kB 응답을 50,000 번 보내면 약 1 GB 의 응답 페이로드입니다. 업로드, 정적 파일, 프로토콜 오버헤드 및 백업 트래픽을 추가하십시오. 그 산술은 처리량이나 동시 사용자가 아닌 볼륨을 추정합니다. 서비스가 트래픽을 계산하고 초과분을 처리하는 방식을 확인하십시오.

다음 작업을 선택하고 확인하십시오

• 정상 피크 중 낮은 사용 가능 메모리: 주요 소비자를 검사하고 더 큰 메모리 예산을 테스트하십시오.
• 지속적인 CPU 압력이 있는 느린 요청: 바쁜 경로를 프로파일링한 다음 동일한 워크로드를 사용하여 CPU 변경을 비교하십시오.
• 디스크 사용 증가: 삭제하기 전에 책임 디렉터리와 보존 정책을 식별하십시오.
• 리소스는 편안해 보이지만 앱이 느림: 종속성, 쿼리 및 요청 경로를 조사하십시오.

워크로드 설명, 샘플 시간, 단위 및 다음 검토 날짜와 함께 워크시트를 저장하십시오. 상당한 릴리스, 데이터 증가 또는 워커 추가 후 다시 확인하십시오. 이러한 관찰에서 구성을 선택하십시오; 어떤 계획 이름도 요청 용량을 보장하지 않습니다. 다음으로 계속하십시오 메모리 및 디스크 경고 읽기 또는 첫 번째 API 리소스 시나리오.