VPS 성능 벤치마크 제대로 하는 방법: yabs.sh 및 도구 활용

VPS 벤치마크의 의미

VPS를 벤치마킹한다는 것은 다음 네 가지를 측정하는 것입니다. 단일 CPU 코어의 실행 속도, 시스템의 메모리 대역폭, 스토리지의 초당 소규모 랜덤 디스크 작업 처리량, 그리고 네트워크 링크의 처리량입니다. yabs.sh을 한 번 실행하면 약 10분 내에 CPU, 디스크, 네트워크 결과를 얻을 수 있습니다. 메모리 대역폭은 아래의 별도 메모리 테스트를 사용하십시오. VPS(가상 사설 서버)는 물리적 하드웨어를 다른 사용자와 공유하므로, 같은 장비라도 03:00에 측정한 값과 20:00에 측정한 값이 크게 다를 수 있어 결과를 해석하는 것이 더 어렵습니다.

이 가이드의 계획은 먼저 yabs.sh을 실행하여 전체적인 성능을 빠르게 파악한 다음, 하위 도구들을 직접 실행하는 것입니다. 직접 도구를 실행해 보면 특정 플래그를 변경했을 때 수치가 어떻게 변하는지 관찰할 수 있으며, 해당 수치가 실제로 무엇을 측정하는지 이해할 수 있습니다. 이 작업은 서버 설정이 완료된 후에 수행하십시오. 새 VPS 설정 후 첫 10분에 나오는 단계들을 먼저 진행해야 합니다. 초기 업데이트가 진행 중인 서버는 하드웨어 성능과 무관한 이유로 벤치마크 결과가 낮게 나올 수 있기 때문입니다.

측정하기 전에 시스템을 먼저 확인하십시오

잘못된 벤치마크 결과의 절반은 작성자가 시스템을 제대로 이해하지 못했기 때문에 발생합니다.

nproc
lscpu | grep -E 'Model name|Hypervisor|Thread'
free -h
df -hT /
uname -r
systemd-detect-virt

Hypervisor vendor: KVM는 완전 가상화를 의미하므로 사용자가 직접 커널을 실행합니다. systemd-detect-virt에서 lxc 또는 openvz를 출력한다는 것은 컨테이너 가상화를 사용 중임을 의미합니다. 이 경우 호스트 커널을 공유하며, CPU 및 메모리 제한은 가상 하드웨어가 아닌 cgroup(control group) 설정에 의해 결정됩니다. cgroup v2 시스템에서는 컨테이너의 cgroup에서 CPU 제한을 읽을 수 있습니다. 해당 cgroup이 /sys/fs/cgroup에 마운트된 경우 다음 경로가 적용됩니다.

cat /sys/fs/cgroup/cpu.max

max 100000는 이 cgroup에 자체 할당량이 없음을 의미하지만, 상위 cgroup이 할당량을 제한할 수 있습니다. 200000 100000는 100000 마이크로초 주기마다 200000 마이크로초의 CPU 시간을 사용할 수 있음을 의미하며, 이는 2개 코어에 해당하는 할당량입니다. 4 vCPU라고 광고하는 플랜이라도 할당량이 2개 코어라면 결코 4개 코어와 같은 성능을 낼 수 없습니다. 벤치마크 도구는 이러한 제한을 식별할 수 있습니다. VoxelBench는 CPU 할당량을 보고하며, 호스트가 서버가 사용할 수 있는 것보다 훨씬 많은 CPU를 노출할 때 공유 또는 스로틀링된 CPU를 표시합니다.

df -hT /은 다른 이유로 중요합니다. 바로 Type 열 때문입니다. 이 값이 overlay이라면 컨테이너 내부에서 실행 중인 것이며, 디스크 결과는 해당 오버레이 아래에 있는 스토리지의 성능을 나타냅니다. 지금 이 내용을 기록해 두십시오.

스틸 타임(steal time)을 상시 모니터링하십시오

스틸 타임은 하이퍼바이저가 가상 CPU를 스케줄링하지 않아 해당 CPU가 비자발적으로 대기한 시간의 비율입니다. 이는 CPU 자원을 사용할 수 없는 상태를 나타내는 유용한 지표이지만, 이웃한 가상 머신이 바쁜 것인지 아니면 공급자가 CPU 할당량을 강제로 제한하는 것인지는 구분하지 못합니다.

vmstat 1 10

오른쪽의 st 열을 확인하십시오. 스틸 타임이 지속된다는 것은 게스트가 CPU 시간을 할당받지 못했음을 의미하지만, 5%를 넘는다고 해서 호스트의 자원이 과도하게 할당(oversubscribed)되었다고 단정할 수는 없습니다. 클라우드 공급자는 CPU 할당량 제한을 의도적으로 스틸 타임으로 노출할 수 있기 때문입니다. top은 CPU 라인의 %st과 동일한 수치를 보여줍니다. 벤치마크를 수행하는 동안 두 번째 SSH 세션에서 vmstat 1를 계속 실행해 두고, 각 결과 옆에 스틸 타임 수치를 기록하십시오.

yabs.sh로 시작하기

yabs.sh (Yet Another Bench Script)는 fio, iperf3, Geekbench를 실행하고 하나의 요약본을 출력하는 셸 스크립트입니다. 이미 설치되어 있다면 fio와 iperf3를 사용하고, 그렇지 않으면 정적 바이너리를 다운로드합니다. VPS 벤치마크 논의에서 공용어로 사용되므로, yabs 출력 결과는 다른 사람과 정보를 비교하는 가장 빠른 방법입니다.

프로젝트에서 제공하는 한 줄 실행 명령은 다음과 같습니다.

curl -sL yabs.sh | bash

이 명령은 URL이 제공하는 내용을 즉시 셸로 전달합니다. 다운로드하여 내용을 읽어본 뒤 실행하십시오.

curl -sLo yabs.sh https://raw.githubusercontent.com/masonr/yet-another-bench-script/master/yabs.sh
less yabs.sh
bash yabs.sh

파이프를 사용할 때는 -s -- 뒤에, 로컬 파일을 실행할 때는 파일명 바로 뒤에 플래그를 붙입니다. 유용한 플래그는 다음과 같습니다. -f는 디스크 테스트를 건너뛰고, -i은 네트워크 테스트를 건너뛰며, -g은 Geekbench를 건너뜁니다. -r는 iperf3 테스트 지역을 3곳으로 줄이고, -j은 결과를 JSON 형식으로 출력하며, -w results.json는 해당 JSON을 파일로 저장합니다.

bash yabs.sh -r -w yabs-run1.json

첫 실행 전에 알아두어야 할 두 가지 사항이 있습니다. Geekbench는 결과를 업로드하고 공개된 browser.geekbench.com URL을 출력하므로, 링크를 가진 사람은 누구나 CPU 모델과 점수를 확인할 수 있습니다. -g를 사용하면 해당 테스트를 완전히 건너뜁니다. 둘째, iperf3 단계는 여러 지역의 서버로 실제 트래픽을 전송하며, 이는 월간 대역폭 할당량에서 차감됩니다. 1 Gbit/s 링크에서 전체 네트워크 테스트를 수행하면 수십 기가바이트의 데이터가 전송될 수 있으므로, 할당량이 적다면 -r을 사용하고 종량제 링크라면 -i을 사용하십시오.

yabs 출력 결과의 각 항목이 의미하는 바

디스크 섹션은 4k, 64k, 512k, 1m의 네 가지 블록 크기로 읽기/쓰기 비율을 50/50으로 설정하여 fio를 실행합니다. 각 블록 크기에 대한 IOPS(초당 입출력 횟수)와 대역폭을 보고합니다. 데이터베이스, 메일 서버 또는 작은 쓰기 작업이 빈번한 서비스의 경우 4k 행을 중점적으로 확인해야 합니다. 대부분의 서버 IO는 작고 분산된 형태로 발생하기 때문입니다. 1m 행은 대용량 데이터를 전송하는 백업이나 영상 서비스와 관련이 있습니다.

네트워크 섹션은 여러 지역의 공개 서버를 대상으로 병렬 스트림을 사용하여 양방향 iperf3 테스트를 수행합니다. 여기서 낮은 수치가 나오더라도 이를 최종적인 결과로 단정 짓지 마십시오. 공개 iperf3 서버는 여러 사용자가 공유하며 종종 포화 상태이므로, 낮은 결과값은 상대측 서버의 문제일 가능성이 있습니다.

Geekbench 섹션은 싱글 코어 점수와 멀티 코어 점수를 제공합니다. 싱글 코어 점수는 단일 요청, 컴파일 또는 쿼리가 얼마나 빨리 완료되는지를 예측하는 지표입니다. 멀티 코어 점수는 실제 가용한 코어의 성능을 나타냅니다.

디스크: 직접 fio 실행하기

fio(flexible IO tester)는 yabs 디스크 섹션의 기반이 되는 도구이며, 직접 실행할 때 비로소 각 플래그의 의미가 명확해집니다.

sudo apt update && sudo apt install -y fio sysbench iperf3

실제 사용하는 파일 시스템에서 큐 깊이(queue depth) 32로 4k 랜덤 읽기 테스트를 수행합니다.

fio --name=randread4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randread --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting

출력 결과에서 확인해야 할 요약 줄은 다음과 같습니다.

read: IOPS=184k, BW=719MiB/s (754MB/s)(42.1GiB/60001msec)

그 아래에 fio는 clat percentiles 블록을 출력합니다. 99.00번째 백분위수(99.00th percentile) 값이 인용할 가치가 있는 수치인데, 이는 100개의 요청 중 가장 느린 요청 하나가 얼마나 대기했는지를 나타내기 때문입니다. 평균 지연 시간은 사용자가 체감하는 지연 현상을 정확히 숨겨버립니다.

• --direct=1은 O_DIRECT 옵션으로 파일을 열어 커널 페이지 캐시를 우회합니다. 이 옵션이 없으면 8G RAM을 가진 시스템에서 2G 파일을 두 번째로 읽을 때 메모리에서 데이터를 가져오게 되며, fio는 수백만 단위의 IOPS를 보고합니다. 그 수치는 실제 수치이지만, 디스크가 아닌 메모리 성능입니다.
• --ioengine=libaio은 비동기 요청을 제출하며, 이를 통해 --iodepth=32가 32개의 요청을 동시에 처리할 수 있게 합니다. psync과 같은 동기식 엔진을 사용하면 iodepth를 1 이상으로 설정해도 아무런 효과가 없으므로, 한 번에 하나의 요청만 측정하게 됩니다.
• --time_based --runtime=60은 고정된 작업량이 아닌 60초 동안 테스트를 수행하므로, 빠른 디스크와 느린 디스크 모두 동일한 시간 동안 측정되어 공정한 비교가 가능합니다.
• --size=2G는 테스트 파일 크기를 설정합니다. 경로상의 모든 캐시보다 크게 유지하고, 사전에 여유 공간이 충분한지 확인하십시오.

랜덤 쓰기 테스트는 --rw=randwrite 플래그를 사용하여 동일한 명령을 실행합니다. 별도로 실행한 뒤 파일을 삭제하십시오.

fio --name=randwrite4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randwrite --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting
rm -f ./fio-testfile

실제 트래픽과 유사한 혼합 테스트를 하려면 --rw=randrw --rwmixread=70를 사용하십시오. 어떤 종류의 스토리지를 사용하는지가 어떤 플래그를 사용하는지보다 결과에 더 큰 영향을 미치며, 이 차이에 대해서는 VPS에서 NVMe와 SATA SSD 스토리지의 차이에서 다룹니다.

fio가 Unknown error -1로 중단되는 경우

Direct IO는 모든 파일 시스템에서 지원되지 않으므로, --direct=1 옵션을 설정한 fio가 첫 번째 요청에서 실패한다면 Direct IO 지원 여부를 가장 먼저 확인해야 합니다. 실패 시 다음과 같은 메시지가 나타날 수 있습니다.

fio: io_u error on file ./fio-testfile: Unknown error -1: read offset=0, buflen=4096
fio: pid=1234, err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1

먼저 df -hT . 명령을 실행하십시오. Docker가 컨테이너에 기본으로 제공하는 파일 시스템인 overlay의 Type 자체가 원인은 아닙니다. overlayfs는 O_DIRECT를 하위 파일 시스템으로 그대로 전달하며, 하위 파일 시스템이 Direct IO를 수행할 수 없을 때만 이를 거부합니다. 따라서 --direct=1 --ioengine=libaio은 ext4나 xfs 위에 구성된 overlay 환경에서도 정상적으로 작동합니다. 테스트 파일이 위치한 파일 시스템이 실제로 Direct IO를 지원하지 않는 경우, fio는 파일을 열 때 보통 fio: looks like your file system does not support direct=1/buffered=0와 같은 오류를 출력합니다. 이 경우 --filename를 bind mount된 볼륨과 같은 실제 로컬 스토리지 경로로 지정하거나, 컨테이너 내부가 아닌 호스트에서 fio를 실행하십시오. 실제 스토리지를 사용할 수 없는 상황이라면, buffered synchronous 방식으로 실행하여 명령 자체에 오류가 없음을 먼저 증명하십시오.

fio --name=randread4k-buffered --filename=./fio-testfile --size=256M --bs=4k \
  --rw=randread --ioengine=psync --direct=0 --numjobs=1 \
  --runtime=15 --time_based --group_reporting
rm -f ./fio-testfile

해당 실행 결과가 무엇을 의미하는지 명확히 인지해야 합니다. 첫 번째 실행 이후 256M 파일은 페이지 캐시에 상주하게 되므로, 측정된 IOPS 수치는 RAM의 성능을 나타냅니다. 이 방식은 fio가 정상적으로 설치되었고 플래그가 올바르게 해석되는지 확인하는 용도로만 사용하십시오. 이 결과를 디스크 성능 결과로 인용해서는 안 됩니다.

왜 dd가 디스크 벤치마크 도구가 아닌가

dd은 VPS 관련 게시물에서 자주 등장하며, 매우 제한적인 질문에 대해서만 답을 제공합니다.

dd if=/dev/zero of=./ddtest bs=1M count=1024 oflag=direct conv=fdatasync
rm -f ./ddtest

이 명령은 단일 스레드와 하나의 요청이 진행 중인 상태에서 순차 쓰기 처리량(sequential write throughput)을 측정합니다. 이는 기본적인 상태 점검으로는 적절합니다. 하지만 무작위 입출력(random IO)에 대해서는 아무런 정보를 주지 않으며, 32개의 요청이 동시에 들어올 때 어떤 일이 벌어지는지도 알 수 없습니다. oflag=direct를 생략하면 쓰기 작업이 페이지 캐시를 거치게 되며, conv=fdatasync는 명령이 종료되기 전에 출력 데이터를 저장 장치로 강제 기록하게 만듭니다. 이마저도 생략하면 결과값은 커널이 메모리로 쓰기 작업을 얼마나 빨리 받아들이는지만 측정하게 될 가능성이 큽니다. 포럼 게시물에서 터무니없는 dd 수치가 자주 인용되는 이유가 바로 이것입니다.

CPU: sysbench cpu

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

유의해야 할 수치는 events per second입니다. 먼저 단일 스레드로 실행하십시오. 이 수치는 하나의 PHP 요청이 완료되거나 컴파일 작업 하나가 끝나는 속도를 결정하며, 동일한 가격대의 호스트 간에 가장 큰 차이를 보이는 지표입니다. 그 후 모든 스레드를 사용하여 실행하면 할당된 vCPU 전반에서 처리량이 어떻게 확장되는지 확인할 수 있습니다.

이 테스트가 무엇을 측정하는지 명확히 이해해야 합니다. sysbench cpu는 시도 나눗셈(trial division)을 통해 반복적으로 소수를 찾습니다. 각 후보 숫자에 대해 배정밀도 제곱근을 구한 뒤, 64비트 정수 모듈로 연산을 사용하여 제수를 테스트하고 각 제수를 해당 부동 소수점 한계값과 비교합니다. 따라서 이 테스트는 정수 연산과 부동 소수점 연산을 혼합하여 수행합니다. 메모리 대역폭, 벡터 유닛, 캐시를 실제 워크로드와 유사한 방식으로 부하를 주지 않으므로, 두 호스트의 성능 순위를 매기는 데는 유용하지만 애플리케이션의 실제 실행 성능을 예측하는 데는 적합하지 않습니다.

Ubuntu 24.04는 sysbench 1.0.20 버전을 제공하며, 이 버전에서는 테스트 이름을 먼저 명시해야 합니다. 오래된 게시물에서 --test=cpu이 포함된 명령어를 그대로 복사하면 WARNING: the --test option is deprecated 오류가 발생합니다. sysbench 0.4 버전과 sysbench 1.0 버전의 점수는 서로 비교할 수 없으므로, 버전 정보가 명시되지 않은 공개된 수치와 자신의 측정값을 비교해서는 안 됩니다.

메모리: sysbench memory

sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=write --threads=1 run
sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read --threads=1 run

결과는 MiB/sec 단위로 출력됩니다. --memory-block-size은 1M으로 유지하고, 비교하는 모든 호스트에서 동일하게 설정하십시오. 1K에서 수치가 급락하는 이유는 연산당 오버헤드가 1,000배 더 자주 발생하기 때문이며, 결과적으로 메모리 대역폭이 아닌 루프 비용을 측정하게 됩니다. 이는 공개된 메모리 성능 점수에서 가장 흔하게 잘못 설정되는 플래그입니다.

네트워크: iperf3

처리량을 정직하게 테스트하는 방법은 직접 제어할 수 있는 다른 장비를 대상으로 하는 것입니다. 그래야 양쪽 끝에서 어떤 일이 일어나는지 파악할 수 있기 때문입니다.

상대편 장비에서 다음을 실행합니다:

iperf3 -s

이 명령은 TCP 5201 포트에서 대기합니다. 테스트를 수행할 주소에 대해서만 포트를 열고, 작업이 끝나면 즉시 닫으십시오. VPS의 기본적인 ufw 방화벽 규칙에서 관련 문법을 다룹니다.

테스트 대상 VPS에서 다음을 실행합니다:

iperf3 -c 203.0.113.10 -t 30
iperf3 -c 203.0.113.10 -t 30 -R
iperf3 -c 203.0.113.10 -t 30 -P 8

첫 번째 명령은 테스트 대상 장비에서의 업로드 속도를 측정합니다. -R 옵션은 방향을 반대로 바꾸어 다운로드 속도를 측정합니다. -P 8 옵션은 8개의 병렬 스트림을 엽니다.

단일 스트림과 병렬 스트림 버전을 모두 실행하십시오. 두 방식은 서로 다른 질문에 대한 답을 제공하기 때문입니다. 하나의 TCP 연결은 윈도우 크기가 허용하는 만큼의 미확인 데이터만 유지할 수 있으므로, 처리량의 상한선은 대략 '윈도우 크기 / 왕복 시간(RTT)'으로 결정됩니다. 지연 시간이 80 ms이고 윈도우 크기가 4 MB라면, 실제 링크 속도가 아무리 빨라도 상한선은 약 400 Mbit/s가 됩니다. 단일 스트림 수치는 단일 다운로드 시 얻을 수 있는 속도를 보여주며, 병렬 수치는 링크의 전체 용량을 나타냅니다.

테스트 중 대역폭 제한을 주의하십시오. 1 Gbit/s 속도로 30초 동안 데이터를 전송하면 약 3.75 GB를 소모하게 되며, 각 방향으로 여러 번 테스트를 수행하게 될 것입니다.

참조 수치 및 수치 해석 방법

[
  {
    "device": "Local NVMe",
    "iops_4k_read": "180,000"
  },
  {
    "device": "Local SATA SSD",
    "iops_4k_read": "90,000"
  },
  {
    "device": "Network block",
    "iops_4k_read": "12,000"
  },
  {
    "device": "Spinning disk",
    "iops_4k_read": "180"
  }
]

공개된 결과에서 로컬 NVMe 볼륨은 보통 180,000 4k 랜덤 읽기 IOPS 근처의 성능을 보입니다. 로컬 SATA SSD는 약 90,000 정도입니다. 모든 요청이 디스크에 도달하기 전 네트워크를 거쳐야 하는 네트워크 연결 블록 스토리지는 12,000에 가깝고, 회전식 디스크는 랜덤 요청마다 물리적인 헤드를 이동해야 하므로 대략 180 정도의 성능을 냅니다.

이 수치들은 각 스토리지 등급에 대해 일반적으로 공개된 수치이며, 단일 호스트에서 측정한 값이 아닙니다. 이 수치들은 오직 본인의 측정 결과가 올바른 자릿수 범위 내에 있는지 확인하는 용도로만 사용하십시오. NVMe로 판매되는 플랜이 4k IOPS 수천 단위 초반의 벤치마크 결과를 보인다면, 우선 --direct=1가 켜져 있는지 확인하십시오. 만약 켜져 있다면, 해당 플랜의 IOPS 제한과 버스트 크레딧, 그리고 스토리지 경합 상태와 광고된 하드웨어 사양을 함께 확인하십시오.

단일 실행이 벤치마크가 될 수 없는 이유

단일 결과는 공유 서버에서 특정 1분을 포착한 스냅샷에 불과합니다. 이를 하나의 표본으로 취급하십시오.

• 모든 테스트는 최소 5회 이상 실행하며, 서로 다른 시간대와 최소 2일 이상의 기간에 걸쳐 수행하십시오. 중앙값과 분포 범위를 기록하십시오. 분포 범위 없이 게시된 결과는 마케팅 수치일 뿐입니다.
• 각 실행마다 steal time을 함께 기록하십시오. st 값이 높게 나온 실행 결과는 폐기하지 말고, 이것이 리소스 경합 때문인지 아니면 해당 플랜의 CPU 할당량 때문인지 조사하십시오. 이를 무시하면 실제 성능을 왜곡하게 됩니다.
• 디스크 테스트는 두 가지 지속 시간으로 실행하십시오. 많은 플랜이 시간이 지나면 충전되는 버스트 IOPS 허용량을 제공하지만, 60초간의 fio 실행이나 --runtime=600만으로는 최저 성능을 측정했다고 보장할 수 없습니다. AWS gp2 크레딧은 잔액이 가득 찼을 때 최소 30분 동안 3,000 IOPS를 유지할 수 있으므로, 두 실행 모두 버스트 성능을 측정하는 결과가 될 수 있습니다. 제공업체의 크레딧 모델을 확인하고, 결과를 지속 가능한 성능이라고 부르기 전에 크레딧 잔액을 모니터링하십시오.
• 다른 작업이 실행 중이지 않은지 확인하십시오. CPU 테스트 도중에 unattended-upgrades가 apt 트랜잭션을 시작하면 실제 점수에 영향을 미치며, 각 실행 전에 ps -e -o comm= | grep -E 'apt|dpkg'을 수행하는 데도 시간이 소요됩니다.
• 한 번에 하나의 변수만 변경하십시오. 도구 버전, 블록 크기, 스레드 수가 다르면 결과가 아무리 비슷해 보여도 서로 비교할 수 없습니다.

두 제공업체를 비교할 때는 같은 날 같은 시간에 테스트를 실행하십시오. 그렇지 않으면 성능이 아닌 시간대별 변동을 측정하게 됩니다.

자신의 작업 부하를 마지막에 벤치마크하십시오

합성 벤치마크 도구는 기기의 순위를 매깁니다. 오직 자신의 작업 부하만이 해당 기기가 충분한지 알려줍니다. 실제로 수행하는 작업을 측정하십시오.

time tar -czf /tmp/bench.tgz /usr/share
rm -f /tmp/bench.tgz

해당 작업은 수백 메가바이트를 압축하므로 CPU와 디스크를 동시에 사용하며, 둘 중 하나라도 변경되면 성능이 변합니다. Removing leading / from member names 경고는 정상입니다. 더 좋은 방법은 직접 빌드하거나, 가장 느린 쿼리를 실행하거나, 페이지를 렌더링하는 시간을 측정하는 것입니다. 한 호스트에서 4분, 다른 호스트에서 7분이 걸리는 빌드라면 Geekbench의 결과와 상관없이 성능 차이는 명확해집니다. 또한 이 측정값은 더 높은 사양의 기기에 비용을 지불할 가치가 없어지는 시점을 알려주며, 이는 VPS의 실제 월 비용을 확인하거나 전용 서버로 작업 부하를 옮기기 전에 알아두어야 할 사항입니다.

FAQ

벤치마크를 실행할 때마다 결과가 다른 이유는 무엇입니까?

VPS는 물리적 CPU, 스토리지, 네트워크를 다른 사용자와 공유하므로 결과는 해당 시점의 다른 사용자 활동에 따라 달라집니다. 테스트 중에 vmstat 1을 실행하고 st 열을 확인하십시오. 지속적인 steal time은 사용할 수 없는 CPU 시간을 기록하지만, 이는 호스트의 경합뿐만 아니라 공급자가 구매한 CPU 할당량을 강제하는 상황을 반영할 수도 있습니다. 5% 이상의 값이 나왔다고 해서 반드시 특정 원인이 있는 것은 아닙니다. 해결책은 튜닝이 아니라 방법론에 있습니다. 각 테스트를 서로 다른 시간대에 5회 이상 실행한 다음, 중앙값과 분포 범위를 함께 보고하십시오.

fio에서 수백만 IOPS가 보고되는 이유는 무엇입니까?

거의 항상 --direct=1 옵션이 누락되었기 때문입니다. 이 옵션이 없으면 fio는 커널 페이지 캐시를 통해 읽기를 수행하므로, 첫 번째 패스 이후 2G 테스트 파일은 RAM에서 제공되며 결과적으로 메모리 대역폭을 측정한 셈이 됩니다. --direct=1을 추가하고 테스트 파일을 경로상의 모든 캐시보다 크게 유지하십시오. 만약 --direct=1이 실패하면 df -hT .를 실행하여 테스트 파일이 위치한 곳을 확인하십시오. overlay 유형 자체는 문제가 되지 않습니다. overlayfs는 O_DIRECT를 하위 스토리지로 그대로 전달하기 때문입니다. 하위 파일 시스템이 직접 IO를 거부하는 경우에만 테스트 파일을 실제 로컬 스토리지로 옮기십시오.

yabs.sh 하나만으로 충분합니까?

초기 확인 용도로는 충분합니다. 이 도구는 4가지 블록 크기로 fio를, 양방향으로 iperf3를, 그리고 Geekbench를 실행하며 다른 사람들이 읽을 수 있는 요약본을 출력합니다. 하지만 수치가 왜 그렇게 나왔는지 파악해야 할 때는 부족합니다. 테스트마다 플래그를 변경할 수 없기 때문입니다. yabs 결과가 이상하게 보인다면 fio나 sysbench를 직접 사용하여 재현하고, 한 번에 하나의 플래그만 변경하며 확인하십시오.

애플리케이션의 체감 성능을 예측할 수 있는 단일 지표는 무엇입니까?

대부분의 웹 및 데이터베이스 워크로드에서는 단일 코어 CPU 속도와 4k 랜덤 읽기 지연 시간이 중요합니다. 처리량 수치는 인상적으로 보일 수 있으나 실제 성능을 결정하는 경우는 드뭅니다. 일반적인 요청은 크기가 작기 때문입니다. 평균값보다는 fio clat percentiles 블록의 99번째 백분위수(99th percentile) 값을 확인하십시오. 100번의 요청 중 느린 1번의 요청이 사용자가 체감하는 성능이기 때문입니다.

벤치마크 전에 설치해야 할 것이 있습니까?

fio, sysbench, iperf3는 모두 Ubuntu 및 Debian 저장소에 포함되어 있습니다: sudo apt install -y fio sysbench iperf3. yabs.sh은 Bash에서 실행되며 다운로드를 위해 curl 또는 wget가 필요하고, Geekbench 추출을 위해 tar이 필요합니다. tar이 없으면 Geekbench는 건너뜁니다. 이 도구는 설치된 fio와 iperf3를 사용하며, 설치되어 있지 않으면 정적 바이너리를 다운로드합니다. 테스트가 끝나면 모든 테스트 파일을 삭제하십시오. 20G 디스크에 남겨둔 2G fio 파일은 몇 주 뒤 누군가의 디스크 용량 부족 경고가 될 수 있습니다.