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

VPS 벤치마크의 의미

VPS를 벤치마크한다는 것은 다음 네 가지를 측정하는 것입니다. 단일 CPU 코어의 실행 속도, 시스템의 메모리 대역폭, 초당 처리 가능한 작은 무작위 디스크 작업 횟수, 그리고 네트워크 링크의 처리량입니다. yabs.sh를 한 번 실행하면 약 10분 안에 이 네 가지를 모두 확인할 수 있습니다. 결과 해석이 더 어려운 이유는 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은 완전 가상화를 의미하므로 사용자가 직접 커널을 실행합니다. lxc 또는 openvz를 출력하는 systemd-detect-virt는 컨테이너 가상화를 의미합니다. 이 경우 호스트 커널을 공유하며, CPU 및 메모리 제한은 가상 하드웨어가 아닌 cgroup(control group) 설정에 의해 결정됩니다. cgroup v2 시스템에서는 CPU 제한을 직접 확인할 수 있습니다.

cat /sys/fs/cgroup/cpu.max

max 100000는 할당량이 없음을 의미합니다. 200000 100000은 100000 마이크로초 주기마다 200000 마이크로초의 CPU 시간을 사용할 수 있음을 의미하며, 이는 2개 코어 분량의 할당량입니다. 4 vCPU라고 광고하는 플랜이라도 할당량이 2개 코어라면 4개 코어와 같은 성능을 낼 수 없으며, 어떤 벤치마크 도구도 그 이유를 설명하는 메시지를 출력하지 않습니다.

df -hT /은 다른 이유로 중요합니다. 바로 Type 열 때문입니다. 이 값이 overlay라면 컨테이너 내부에서 실행 중인 것이며, 아래의 디스크 테스트를 변경해야 합니다. 지금 확인해 두십시오.

항상 steal time 모니터링하기

Steal time은 가상 CPU가 실행 준비를 마쳤음에도 하이퍼바이저가 물리 코어를 다른 작업에 할당하여 대기한 시간의 비율입니다. 이는 성능 저하의 원인이 하드웨어가 아닌 이웃 가상 머신에 있음을 알려주는 가장 유용한 지표입니다.

vmstat 1 10

오른쪽의 st 열을 확인하십시오. 0이나 1이 지속되는 것은 정상입니다. 5를 초과하는 값이 지속된다면 해당 시점에 호스트의 자원이 과도하게 할당된 상태이므로, 해당 구간에서 기록된 모든 CPU 수치는 시스템의 결함이 아닌 외부 요인으로 인해 낮게 측정된 것입니다. top은 CPU 행의 %st와 동일한 수치를 보여줍니다. 벤치마크를 수행하는 동안 두 번째 SSH 세션에서 vmstat 1을 계속 실행해 두고, 각 결과 옆에 steal 수치를 기록하십시오.

yabs.sh로 시작하기

yabs.sh (Yet Another Bench Script)는 정적 fio, iperf3, Geekbench 바이너리를 다운로드하여 실행한 뒤 요약 결과를 출력하는 셸 스크립트입니다. 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 테스트 지역을 2곳으로 줄이고, -j은 결과를 JSON 형식으로 출력하며, -w results.json은 해당 JSON을 파일로 저장합니다.

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

첫 실행 전에 알아두어야 할 두 가지 사항이 있습니다. Geekbench는 테스트 결과를 업로드하고 public 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를 사용할 수 있는 것은 아닙니다. Docker가 컨테이너에 기본으로 제공하는 파일 시스템인 overlay와 여러 네트워크 파일 시스템은 O_DIRECT을 지원하지 않습니다. 따라서 libaio가 커널이 완료할 수 없는 요청을 제출하게 되고, fio는 작업을 중단합니다.

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 .을 실행하십시오. Type 열에 overlay라고 표시된다면, --filename을 bind mount된 볼륨과 같은 실제 스토리지 경로로 지정하거나 컨테이너 내부가 아닌 호스트에서 fio를 실행하십시오. 실제 스토리지를 사용할 수 없는 경우, 버퍼를 사용하는 동기식 실행을 통해 최소한 명령어 자체가 올바른지 확인할 수 있습니다.

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

이 명령은 단일 스레드와 하나의 요청이 진행 중인 상태에서의 순차 쓰기 처리량을 측정합니다. 이는 기본적인 정상 작동 여부를 확인하는 용도로는 적절합니다. 하지만 무작위 입출력(random IO)에 대해서는 아무것도 알려주지 않으며, 32개의 요청이 동시에 들어올 때 어떤 일이 벌어지는지도 측정하지 못합니다. oflag=direct를 생략하면 이 명령은 커널이 메모리로 쓰기 작업을 얼마나 빨리 받아들이는지만 측정하게 되며, 이것이 포럼 게시물에서 인용되는 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는 64비트 정수 연산을 사용하여 반복적으로 소수를 찾습니다. 이 과정은 실제 워크로드와 유사한 방식으로 메모리 대역폭, 벡터 유닛, 캐시에 부하를 주지 않습니다. 따라서 두 호스트의 성능 순위를 매기는 데는 유용하지만, 실제 애플리케이션의 실행 성능을 예측하는 데는 적합하지 않습니다.

Ubuntu 24.04는 sysbench 1.0.20 버전을 제공하며, 이 버전에서는 테스트 이름을 먼저 입력해야 합니다. 오래된 게시물에서 --test=cpu가 포함된 명령어를 그대로 복사하면 WARNING: the --test option is deprecated 오류가 발생합니다. sysbench 0.4 버전과 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에서 수치가 급락하는 이유는 연산당 오버헤드가 1000배 더 자주 발생하기 때문입니다. 결과적으로 메모리 대역폭이 아닌 루프 비용을 측정하게 됩니다. 이는 메모리 성능 지표를 게시할 때 가장 흔하게 잘못 설정되는 플래그입니다.

네트워크: 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이 켜져 있는지 확인하십시오. 만약 켜져 있는데도 결과가 낮다면, 해당 스토리지가 제품 페이지에 설명된 사양과 다르거나 매우 혼잡한 이웃 사용자와 자원을 공유하고 있을 가능성이 큽니다.

단 한 번의 실행이 벤치마크가 될 수 없는 이유

단일 결과는 공유 서버에서 특정 1분 동안의 상태를 찍은 스냅샷에 불과합니다. 이를 하나의 표본으로 취급하십시오.

• 모든 테스트는 최소 5회 이상 실행하며, 서로 다른 시간대와 최소 2일 이상의 기간에 걸쳐 수행하십시오. 중앙값과 분포 범위를 기록하십시오. 분포 범위 없이 발표된 결과는 마케팅 수치일 뿐입니다.
• 각 실행마다 steal time을 기록하십시오. st가 높았던 실행 결과는 폐기하거나, 최소한 해당 사실을 명시하십시오.
• 디스크 테스트는 두 가지 지속 시간으로 실행하십시오. 많은 플랜이 시간이 지나면 다시 채워지는 burst IOPS 허용량을 제공하므로, 60초간의 fio 실행은 burst 성능을 측정하는 반면 --runtime=600은 하한선을 측정합니다. 하한선은 서버 상태가 좋지 않을 때 얻게 되는 성능입니다.
• 다른 작업이 실행 중이지 않은지 확인하십시오. CPU 테스트 도중에 unattended-upgrades가 apt 트랜잭션을 시작하면 실제 성능 점수가 하락하며, 각 실행 전에 ps -e -o comm= | grep -E 'apt|dpkg'를 수행하면 1초가 소요됩니다.
• 한 번에 하나의 변수만 변경하십시오. 도구 버전, 블록 크기, 스레드 수가 다르면 아무리 비슷해 보여도 서로 비교할 수 없는 수치가 나옵니다.

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

자신의 워크로드로 직접 벤치마크하십시오

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

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이 5를 넘는다면 호스트가 바쁜 상태이며, 사용자의 CPU 점수는 시스템 외부 요인으로 인해 낮게 측정된 것입니다. 이 문제의 해결책은 튜닝이 아니라 방법론에 있습니다. 각 테스트를 서로 다른 시간대에 5회 이상 실행한 뒤, 중앙값과 분포 범위를 함께 보고하십시오.

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

거의 대부분 --direct=1가 누락되었기 때문입니다. 이 옵션이 없으면 fio는 커널 페이지 캐시를 통해 읽기를 수행하므로, 첫 번째 패스 이후 2G 테스트 파일은 RAM에서 제공되어 결과적으로 메모리 대역폭을 측정하게 됩니다. --direct=1을 추가하고 테스트 파일을 경로상의 모든 캐시보다 크게 유지하십시오. 만약 --direct=1이 err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1 오류로 실패한다면 df -hT .을 실행하십시오. overlay의 Type는 O_DIRECT을 지원하지 않으므로, 실제 스토리지 대상을 지정해야 합니다.

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

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

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

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

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

fio, sysbench, iperf3는 모두 Ubuntu 및 Debian 저장소에 포함되어 있으므로 sudo apt install -y fio sysbench iperf3을 사용하면 됩니다. yabs.sh는 curl만 있으면 충분합니다. 누락된 구성 요소에 대해 정적 바이너리를 자동으로 다운로드하기 때문입니다. 테스트가 끝나면 모든 테스트 파일을 삭제하십시오. 20G 디스크에 남겨둔 2G fio 파일은 몇 주 뒤 누군가의 디스크 용량 부족 경고가 될 수 있습니다.