Benchmark VPS đúng cách với yabs.sh, fio, sysbench

Ý nghĩa của việc benchmark VPS

Để benchmark một VPS, bạn đo 4 yếu tố: tốc độ chạy của một CPU core, băng thông memory của máy, số thao tác disk ngẫu nhiên nhỏ mà storage xử lý mỗi giây và throughput mà network link cung cấp. Một lần chạy yabs.sh cho kết quả về CPU, disk và network trong khoảng 10 phút; hãy dùng memory test riêng bên dưới để đo băng thông memory. Đọc kết quả mới là phần khó hơn, vì VPS (virtual private server) dùng chung hardware vật lý với các tenant khác. Do đó, cùng một máy có thể báo một con số lúc 03:00 và một con số rất khác lúc 20:00.

Kế hoạch ở đây là chạy yabs.sh để có đánh giá nhanh, sau đó tự chạy từng tool bên dưới. Tự chạy giúp bạn thay đổi từng flag, theo dõi con số thay đổi và hiểu chính xác con số đó đang đo gì. Hãy thực hiện sau khi đã setup máy, không phải trước đó. Các bước trong 10 phút đầu tiên trên một VPS mới phải được thực hiện trước, vì một máy vẫn đang áp dụng đợt update đầu tiên sẽ cho kết quả benchmark không chính xác vì những lý do không liên quan đến hardware.

Xem máy trước khi đo

Một nửa nguyên nhân khiến benchmark cho kết quả kém là do người viết không hiểu rõ máy đang được đo.

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

Hypervisor vendor: KVM nghĩa là ảo hóa toàn phần, nên bạn chạy kernel của riêng mình. systemd-detect-virt hiển thị lxc hoặc openvz nghĩa là ảo hóa container: bạn dùng chung kernel của host, còn giới hạn CPU và bộ nhớ được đặt bằng cgroup (control group), không phải phần cứng ảo. Trên hệ thống dùng cgroup v2, bạn có thể đọc giới hạn CPU từ cgroup của container; đường dẫn sau áp dụng khi cgroup đó được mount tại /sys/fs/cgroup.

cat /sys/fs/cgroup/cpu.max

max 100000 nghĩa là cgroup này không có quota riêng; các cgroup cấp trên vẫn có thể áp quota. 200000 100000 nghĩa là bạn được dùng 200000 microseconds CPU trong mỗi chu kỳ 100000 microseconds, tương đương quota của 2 core. Một gói được quảng cáo là 4 vCPU nhưng có quota tương đương 2 core sẽ không bao giờ đạt điểm như 4 core. Công cụ benchmark có thể xác định giới hạn này: VoxelBench báo cáo CPU quota và đánh dấu CPU dùng chung hoặc bị throttled khi host cung cấp nhiều CPU hơn đáng kể so với số CPU server được phép sử dụng.

df -hT / quan trọng vì một lý do khác: cột Type. Nếu cột này hiển thị overlay, bạn đang ở trong container, và kết quả disk sẽ mô tả storage bên dưới lớp overlay đó. Hãy ghi nhận điều này ngay.

Theo dõi steal time liên tục

Steal time là phần thời gian CPU ảo của bạn phải chờ ngoài ý muốn vì hypervisor không cấp lịch chạy cho nó. Đây là tín hiệu hữu ích cho biết CPU không khả dụng, nhưng không phân biệt được hàng xóm đang bận với việc nhà cung cấp áp dụng CPU quota cho bạn.

vmstat 1 10

Đọc cột st ở bên phải. Steal time duy trì ở mức cao nghĩa là guest không được cấp CPU time, nhưng giá trị trên 5% không chứng minh host đang bị overcommit. Nhà cung cấp có thể cố ý thể hiện việc áp dụng CPU quota dưới dạng steal time. top hiển thị cùng một chỉ số với %st trên dòng CPU. Hãy để vmstat 1 chạy trong một phiên SSH thứ hai khi benchmark, rồi ghi lại giá trị steal bên cạnh từng kết quả.

Bắt đầu với yabs.sh

yabs.sh (Yet Another Bench Script) là một shell script chạy fio, iperf3 và Geekbench rồi in ra một bản tóm tắt. Script sử dụng fio và iperf3 nếu chúng đã được cài đặt, và tải binary tĩnh khi chưa có. Đây là cách diễn đạt phổ biến trong các cuộc thảo luận về benchmark VPS, nên output của yabs là cách nhanh nhất để so sánh kết quả với người khác.

Dạng one-line chính thức của project là như sau.

curl -sL yabs.sh | bash

Lệnh này pipe mọi nội dung URL trả về tại thời điểm chạy thẳng vào shell. Hãy tải xuống, đọc nội dung, rồi mới chạy.

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

Khi pipe, đặt các flag sau -s --. Khi chạy bản copy cục bộ, đặt chúng ngay sau tên file. Các flag hữu ích gồm: -f bỏ qua disk test, -i bỏ qua network test, -g bỏ qua Geekbench, -r giảm số location của iperf3 xuống còn ba, -j in kết quả ở dạng JSON, và -w results.json ghi JSON đó vào một file.

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

Có 2 điều cần biết trước lần chạy đầu tiên. Geekbench upload kết quả của bạn và in ra một URL public trên browser.geekbench.com, nên bất kỳ ai có link đó đều có thể xem CPU model và điểm số của bạn. -g bỏ qua hoàn toàn test này. Thứ hai, giai đoạn iperf3 truyền network traffic thực đến các server ở nhiều region và lượng traffic đó được tính vào monthly bandwidth allowance của bạn. Trên đường truyền 1 Gbit/s, một network stage đầy đủ có thể truyền hàng chục gigabyte, vì vậy hãy dùng -r nếu allowance nhỏ và -i nếu đường truyền được tính phí theo dung lượng.

Ý nghĩa của từng phần trong kết quả yabs

Phần disk chạy fio với tỷ lệ đọc/ghi 50/50 ở 4 kích thước block: 4k, 64k, 512k và 1m. Phần này báo IOPS (số thao tác input/output mỗi giây) và băng thông cho từng kích thước. Dòng 4k đáng chú ý đối với database, mail server hoặc mọi workload thực hiện nhiều thao tác ghi nhỏ, vì phần lớn IO của server có kích thước nhỏ và phân tán. Dòng 1m phù hợp để đánh giá backup và video, nơi dữ liệu được truyền theo các chuỗi byte dài.

Phần network chạy iperf3 với các public server ở nhiều khu vực, theo cả hai chiều và sử dụng các parallel stream. Hãy xem kết quả thấp ở đây là một vấn đề cần kiểm tra, không phải kết luận cuối cùng, vì các public iperf3 server được dùng chung và thường bị bão hòa. Kết quả kém có thể do phía server ở đầu xa.

Phần Geekbench cung cấp điểm single core và multi core. Điểm single core cho biết một request, một lần compile hoặc một query hoàn tất nhanh đến mức nào. Điểm multi core chủ yếu cho biết bạn thực sự được cấp bao nhiêu core.

Disk: tự chạy fio

fio (flexible IO tester) là công cụ phía sau phần disk của yabs. Chạy trực tiếp fio sẽ giúp bạn hiểu rõ ý nghĩa của các flag.

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

Bài test đọc ngẫu nhiên 4k với queue depth bằng 32, trên filesystem bạn thực sự quan tâm:

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

Dòng tóm tắt cần đọc trong output có dạng như sau.

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

Bên dưới, fio in ra một block clat percentiles. Phân vị 99.00 là giá trị đáng trích dẫn, vì nó cho biết request chậm nhất trong mỗi 100 request đã phải chờ bao lâu. Latency trung bình che khuất chính những lần bị stall mà người dùng nhận thấy.

• --direct=1 mở file với O_DIRECT, nên các thao tác đọc bỏ qua kernel page cache. Nếu không dùng tùy chọn này, lần chạy thứ hai trên file 2G ở máy có 8G RAM sẽ được phục vụ từ memory và fio báo IOPS lên đến hàng triệu. Con số đó là có thật, nhưng đó là con số của memory.
• --ioengine=libaio gửi các request bất đồng bộ. Nhờ đó --iodepth=32 có thể duy trì 32 request đang được xử lý. Với engine đồng bộ như psync, iodepth lớn hơn 1 hoàn toàn không có tác dụng, nên bạn đo từng request một.
• --time_based --runtime=60 chạy trong 60 giây cố định thay vì xử lý một lượng công việc cố định. Nhờ đó disk nhanh và disk chậm có cùng thời gian thực tế, giúp so sánh công bằng hơn.
• --size=2G đặt kích thước file test. Hãy giữ kích thước này lớn hơn mọi cache trên đường đi và kiểm tra dung lượng trống trước.

Random write dùng cùng command này với --rw=randwrite. Chạy riêng bài test đó, sau đó xóa file.

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

Để mô phỏng hỗn hợp gần với network traffic thực tế hơn, hãy dùng --rw=randrw --rwmixread=70. Loại storage bạn đang sử dụng ảnh hưởng đến kết quả nhiều hơn bất kỳ flag nào. Phần khác biệt giữa NVMe và SATA SSD storage trên VPS giải thích sự khác biệt này.

Khi fio dừng với lỗi Unknown error -1

Không phải filesystem nào cũng hỗ trợ Direct IO. Vì vậy, khi fio thất bại ngay ở request đầu tiên với --direct=1 được bật, hãy kiểm tra Direct IO trước. Lỗi có thể trông như sau:

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

Trước tiên hãy chạy df -hT .. Type của overlay, là filesystem Docker cấp mặc định cho container, tự nó không phải nguyên nhân. overlayfs chuyển O_DIRECT xuống filesystem bên dưới và chỉ từ chối khi filesystem đó không thể thực hiện Direct IO. Vì vậy, --direct=1 --ioengine=libaio vẫn hoạt động trên overlayfs nằm trên ext4 hoặc xfs. Khi filesystem bên dưới file kiểm thử thực sự không hỗ trợ Direct IO, fio thường báo lỗi ngay lúc mở file: fio: looks like your file system does not support direct=1/buffered=0. Trong trường hợp đó, hãy trỏ --filename đến một path trên storage local thực, chẳng hạn volume được bind mount, hoặc chạy fio trên host thay vì trong container. Nếu không thể truy cập storage thực, một lần chạy synchronous có buffering ít nhất cũng xác nhận rằng bản thân command là đúng.

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

Hãy hiểu đúng ý nghĩa của lần chạy đó. Sau lần đầu tiên, file 256M nằm trong page cache, nên chỉ số IOPS phản ánh RAM của bạn. Hãy dùng kết quả này để xác nhận fio đã được cài đặt và các flag được parse đúng. Không bao giờ trích dẫn nó như kết quả của disk.

Vì sao dd không phải công cụ benchmark disk

dd xuất hiện trong rất nhiều topic về VPS và nó chỉ trả lời một câu hỏi hẹp.

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

Lệnh này đo throughput ghi tuần tự với một thread và một request đang xử lý. Đây là một phép kiểm tra nhanh hợp lý. Nó không cho biết gì về random IO, cũng không cho biết điều gì xảy ra khi có 32 request đến cùng lúc. Bỏ oflag=direct thì thao tác ghi sẽ đi qua page cache, nhưng conv=fdatasync vẫn buộc dữ liệu đầu ra được ghi xuống storage trước khi command kết thúc. Bỏ cả tùy chọn đó thì kết quả phần lớn chỉ đo tốc độ kernel nhận dữ liệu ghi vào memory, vì vậy các con số dd được trích dẫn trong các bài đăng trên forum thường vô lý.

CPU: sysbench CPU

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

Chỉ số cần giữ lại là events per second. Trước tiên hãy chạy với một thread. Đây là chỉ số quyết định một request PHP hoàn tất nhanh đến đâu hoặc một job compile hoàn thành nhanh đến đâu. Chỉ số này cũng khác biệt nhiều nhất giữa các host có cùng mức giá. Sau đó hãy chạy với tất cả thread. Kết quả cho biết throughput tăng như thế nào trên số vCPU được cấp cho bạn.

Cần hiểu rõ phép đo này: sysbench CPU liên tục tìm số nguyên tố bằng phép chia thử. Với mỗi số ứng viên, nó tính căn bậc hai double precision, sau đó kiểm tra các ước bằng phép modulo số nguyên 64 bit và so sánh từng ước với giới hạn floating point đó. Vì vậy, bài test kết hợp cả tác vụ integer và floating point. Nó không tạo tải cho memory bandwidth, vector unit hoặc cache theo cách giống workload thực tế. Do đó, bài test phù hợp để xếp hạng hai host nhưng không phù hợp để dự đoán ứng dụng của bạn sẽ chạy như thế nào.

Ubuntu 24.04 phát hành kèm sysbench 1.0.20, trong đó tên bài test được đặt trước. Nếu copy lệnh có --test=cpu từ một bài viết cũ, bạn sẽ nhận được WARNING: the --test option is deprecated. Điểm từ sysbench 0.4 và sysbench 1.0 hoàn toàn không thể so sánh. Vì vậy, không bao giờ so sánh kết quả của bạn với một con số được công bố nếu con số đó không ghi rõ version.

Bộ nhớ: 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

Kết quả được tính bằng MiB/giây. Giữ --memory-block-size ở mức 1M và giữ nguyên giá trị này trên mọi host bạn so sánh. Ở 1K, con số giảm mạnh vì chi phí cho mỗi operation xuất hiện thường xuyên hơn gấp một nghìn lần. Do đó, bạn đang đo chi phí của vòng lặp thay vì băng thông bộ nhớ. Đây là flag thường bị đặt không nhất quán nhất trong các điểm số bộ nhớ được công bố.

Network: iperf3

Cách kiểm tra throughput chính xác là kiểm tra với một máy thứ hai do bạn kiểm soát, vì khi đó bạn biết cả hai đầu đang làm gì.

Trên máy ở đầu xa:

iperf3 -s

Lệnh này lắng nghe trên TCP 5201. Chỉ mở port cho địa chỉ mà bạn dùng để kiểm tra, rồi đóng port khi hoàn tất. Các quy tắc firewall ufw cơ bản trên VPS trình bày cú pháp.

Từ VPS đang được kiểm tra:

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

Lệnh đầu tiên đo tốc độ upload từ máy đang được kiểm tra. -R đảo ngược hướng truyền, để đo tốc độ download. -P 8 mở tám stream song song.

Hãy chạy cả phiên bản một stream và phiên bản song song, vì chúng trả lời các câu hỏi khác nhau. Một kết nối TCP chỉ có thể giữ lượng dữ liệu chưa được xác nhận bằng kích thước window cho phép. Vì vậy, giới hạn của nó xấp xỉ kích thước window chia cho round-trip time. Với độ trễ 80 ms và window 4 MB, giới hạn này là khoảng 400 Mbit/s, dù link bên dưới có tốc độ cao đến đâu. Giá trị của một stream cho biết một lượt download sẽ đạt được bao nhiêu. Giá trị khi chạy song song cho biết capacity của link.

Trong khi kiểm tra, hãy theo dõi hạn mức bandwidth của bạn. Chạy 30 giây ở tốc độ 1 Gbit/s sẽ truyền khoảng 3.75 GB, và bạn sẽ chạy lệnh này nhiều lần theo cả hai hướng.

Các mốc tham chiếu và cách đọc kết quả của bạn

[
  {
    "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"
  }
]

Một volume NVMe cục bộ trong các kết quả được công bố thường đạt gần 180,000 IOPS đọc ngẫu nhiên 4k. SSD SATA cục bộ thường đạt khoảng 90,000. Block storage gắn qua mạng, trong đó mỗi request phải đi qua mạng trước khi đến disk, thường đạt gần 12,000, còn disk quay chỉ đạt khoảng 180 vì phải di chuyển đầu đọc vật lý cho từng request ngẫu nhiên.

Đây là các số liệu tham khảo thường thấy được công bố cho từng loại storage, không phải kết quả đo từ một host cụ thể. Chỉ dùng chúng cho một mục đích: kiểm tra xem kết quả của bạn có nằm đúng bậc độ lớn hay không. Nếu một plan được bán là NVMe nhưng benchmark chỉ đạt vài nghìn IOPS 4k, trước tiên hãy xác nhận --direct=1 đã được bật. Nếu đã bật, hãy kiểm tra giới hạn IOPS và burst credits của plan, đồng thời kiểm tra tình trạng tranh chấp storage và phần cứng được quảng cáo.

Vì sao một lần chạy không phải là benchmark

Một kết quả chỉ là ảnh chụp tại một thời điểm trong một phút trên máy dùng chung. Hãy xem đó là một mẫu duy nhất.

• Chạy mỗi bài test ít nhất 5 lần, vào các giờ khác nhau và ít nhất 2 ngày khác nhau. Giữ lại median và độ phân tán. Một kết quả được công bố mà không có độ phân tán chỉ là số liệu marketing.
• Ghi lại steal time bên cạnh từng lần chạy. Giữ lại các lần chạy khi st cao và điều tra xem chúng phản ánh tranh chấp tài nguyên hay CPU quota của gói; loại bỏ chúng có thể che giấu hiệu năng thực tế bạn nhận được.
• Chạy disk test với 2 thời lượng. Nhiều gói có burst IOPS allowance được bổ sung dần theo thời gian, nhưng cả bài chạy fio 60 giây lẫn --runtime=600 đều không đảm bảo rằng bạn đã đo được mức sàn. AWS gp2 có thể duy trì 3,000 IOPS trong ít nhất 30 phút khi balance đầy, nên cả 2 lần chạy đều có thể đo burst performance. Kiểm tra mô hình credit của provider và monitor credit balance trước khi gọi một kết quả là sustained performance.
• Kiểm tra để chắc chắn không có tác vụ nào khác đang chạy. unattended-upgrades bắt đầu một apt transaction giữa bài CPU test sẽ làm mất điểm thực tế, còn ps -e -o comm= | grep -E 'apt|dpkg' trước mỗi lần chạy chỉ mất một giây.
• Chỉ thay đổi một biến mỗi lần. Các phiên bản tool, block size hoặc thread count khác nhau tạo ra những con số không thể so sánh, dù chúng trông rất giống nhau.

Khi so sánh 2 provider, hãy chạy test vào cùng một giờ trong cùng một ngày. Nếu không, bạn chỉ đang đo thời điểm trong ngày.

Benchmark workload của chính bạn trước

Các công cụ benchmark tổng hợp dùng để xếp hạng máy chủ. Chỉ workload của chính bạn mới cho biết một máy có đủ hay không. Hãy đo thời gian cho tác vụ bạn thực sự chạy.

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

Tác vụ này nén vài trăm megabyte, nên kiểm tra đồng thời CPU và disk. Kết quả sẽ thay đổi khi một trong hai thành phần thay đổi. Cảnh báo Removing leading / from member names là bình thường. Tốt hơn nữa, hãy đo thời gian build của chính bạn, query chậm nhất của chính bạn hoặc thời gian render page của chính bạn. Build mất 4 phút trên một host và 7 phút trên host khác đã đủ trả lời câu hỏi, bất kể Geekbench cho kết quả thế nào. Đây cũng là phép đo cho biết khi nào việc trả thêm tiền để nâng cấp máy không còn đáng nữa. Bạn nên biết điều đó trước khi đọc chi phí thực tế mỗi tháng của một VPS hoặc chuyển workload sang dedicated server.

FAQ

Tại sao mỗi lần chạy benchmark tôi lại nhận được kết quả khác nhau?

VPS dùng chung CPU vật lý, storage và network với các tenant khác, nên kết quả phụ thuộc vào việc họ đang làm gì tại thời điểm đó. Chạy vmstat 1 trong lúc test và đọc cột st: steal time tích lũy ghi lại thời gian CPU không khả dụng, nhưng giá trị này có thể phản ánh cả việc provider áp dụng giới hạn CPU đã mua lẫn tình trạng tranh chấp tài nguyên trên host. Giá trị trên 5% không đủ để xác định nguyên nhân. Cách xử lý là dùng phương pháp đo đúng, không phải tuning. Chạy mỗi test ít nhất năm lần vào các giờ khác nhau, rồi báo cáo median cùng với độ phân tán của kết quả.

Tại sao fio báo hàng triệu IOPS?

Gần như luôn là do thiếu --direct=1. Nếu không có tùy chọn này, fio đọc qua page cache của kernel. Sau lượt đầu tiên, file test 2G được phục vụ từ RAM và bạn đang đo memory bandwidth. Thêm --direct=1 và giữ file test lớn hơn mọi cache trên đường đi. Nếu --direct=1 vẫn fail, chạy df -hT . và kiểm tra file test đang nằm trên loại storage nào. Bản thân filesystem kiểu overlay không phải vấn đề, vì overlayfs chuyển tiếp O_DIRECT xuống storage bên dưới. Chỉ chuyển file test sang local storage thực nếu filesystem bên dưới không hỗ trợ direct IO.

Chỉ dùng yabs.sh có đủ không?

Để kiểm tra ban đầu thì đủ. Nó chạy fio với bốn block size, iperf3 theo cả hai hướng và Geekbench, rồi in ra một bản tóm tắt mà người khác có thể đọc. Nó không còn đủ khi bạn muốn biết tại sao một con số lại có giá trị như vậy, vì bạn không thể thay đổi các flag riêng cho từng test. Khi kết quả yabs có vẻ sai, hãy chạy lại bằng fio hoặc sysbench trực tiếp và thay đổi từng flag một.

Một con số duy nhất nào dự đoán được ứng dụng của tôi sẽ phản hồi ra sao?

Đối với phần lớn workload web và database, đó là tốc độ CPU đơn nhân, sau đó đến độ trễ đọc ngẫu nhiên 4k. Các con số throughput thường trông ấn tượng nhưng hiếm khi quyết định hiệu năng, vì một request điển hình có kích thước nhỏ. Hãy báo cáo percentile 99 từ block clat percentiles của fio thay vì giá trị trung bình, vì request chậm trong mỗi 100 request là điều người dùng nhận thấy.

Tôi có cần cài gì trước khi benchmark không?

fio, sysbench và iperf3 đều có trong các archive của Ubuntu và Debian: sudo apt install -y fio sysbench iperf3. yabs.sh chạy trong Bash và cần curl hoặc wget để download, cùng với tar để giải nén Geekbench; nếu không có tar, nó sẽ bỏ qua Geekbench. Khi các package này đã được cài, script dùng fio và iperf3; nếu thiếu, nó sẽ download static binary. Xóa mọi file test sau khi hoàn tất, vì file fio 2G bị bỏ lại trên disk 20G có thể trở thành cảnh báo disk full của người khác sau vài tuần.