Paano Mag-benchmark ng VPS nang Tama

Ang ibig sabihin ng pag-benchmark ng VPS

Sa pag-benchmark ng VPS, sinusukat ang apat na bagay: kung gaano kabilis tumakbo ang isang CPU core, kung gaano kalaki ang memory bandwidth ng machine, kung ilang maliit at random na disk operation ang kayang ihatid ng storage bawat segundo, at kung gaano kalaking throughput ang naibibigay ng network link. Isang run ng yabs.sh ang nagbibigay ng lahat ng ito sa loob ng humigit-kumulang sampung minuto. Mas mahirap basahin ang resulta, dahil nakikibahagi ang isang VPS (virtual private server) sa physical hardware kasama ng iba pang tenant. Kaya maaaring mag-ulat ang parehong machine ng isang value sa 03:00 at ibang-iba namang value sa 20:00.

Ang plano ay patakbuhin muna ang yabs.sh para sa mabilis na pangkalahatang larawan, at pagkatapos ay mano-manong patakbuhin ang mga tool na nasa ilalim nito. Kapag ikaw mismo ang nagpatakbo sa mga ito, maaari mong baguhin ang isang flag, obserbahan kung paano nagbabago ang value, at malaman kung ano talaga ang sinusukat ng value na iyon. Gawin ito pagkatapos ma-set up ang machine, hindi bago. Mauuna ang mga hakbang sa unang sampung minuto sa bagong VPS, dahil hindi maayos ang resulta ng benchmark sa isang machine na ina-apply pa ang unang batch ng updates dahil sa mga dahilang walang kinalaman sa hardware.

Suriin ang machine bago ito sukatin

Kalahati ng bawat hindi maaasahang benchmark ay isang machine na hindi naunawaan ng gumawa.

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

Ang Hypervisor vendor: KVM ay nangangahulugang full virtualisation, kaya sarili mong kernel ang pinapatakbo mo. Ang pag-print ng systemd-detect-virt o lxc o openvz ay nangangahulugang container virtualisation naman: ginagamit mo ang host kernel, at ang CPU at memory limit mo ay mga cgroup (control group) setting sa halip na virtual hardware. Sa cgroup v2 system, mababasa mo mismo ang CPU limit.

cat /sys/fs/cgroup/cpu.max

Ang max 100000 ay nangangahulugang walang quota. Ang 200000 100000 ay nangangahulugang maaari kang gumamit ng 200000 microseconds ng CPU sa bawat 100000 microsecond na period, na katumbas ng quota para sa dalawang core. Ang planong ina-advertise bilang 4 vCPU na may quota para sa dalawang core ay hindi kailanman makakakuha ng score na katulad ng apat na core, at walang benchmark tool na magpi-print ng linyang nagpapaliwanag kung bakit.

Mahalaga ang df -hT / sa ibang dahilan: ang Type column. Kung mabasa rito ang overlay, nasa loob ka ng container, at kailangang baguhin ang disk test sa ibaba. Itala ito ngayon.

Bantayan ang steal time sa buong proseso

Ang steal time ay bahagi ng oras na handa nang tumakbo ang iyong virtual CPU pero ipinagamit ng hypervisor ang physical core sa ibang virtual machine. Ito ang pinakamalinaw na single signal na nagpapakitang ang resulta ay dulot ng ibang tenant sa halip na ng hardware.

vmstat 1 10

Basahin ang column na st sa kanan. Normal ang tuloy-tuloy na 0 o 1. Kapag lampas 5 ang sustained value, overloaded ang host sa oras na iyon. Dahil dito, mababa ang bawat CPU number na makukuha mo sa window na iyon, at hindi ito kasalanan ng iyong machine. Ipinapakita ng top ang kaparehong figure na nasa %st sa CPU line. Patakbuhin ang vmstat 1 sa ikalawang SSH session habang nagsasagawa ka ng benchmark, at itala ang steal figure sa tabi ng bawat resulta.

Magsimula sa yabs.sh

yabs.sh (Yet Another Bench Script) ay isang shell script na nagda-download ng static fio, iperf3, at Geekbench binaries, pinapatakbo ang mga ito, at nagpi-print ng isang buod. Ito ang karaniwang wika sa mga talakayan tungkol sa VPS benchmarks, kaya ang yabs output ang pinakamabilis na paraan upang maikumpara ang resulta sa ibang tao.

Ganito ang one-line form mula mismo sa proyekto.

curl -sL yabs.sh | bash

Ipinapasa nito ang anumang kasalukuyang ibinibigay ng URL nang direkta sa shell. I-download muna ito, basahin, saka patakbuhin.

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

Inilalagay ang flags pagkatapos ng -s -- kapag gumagamit ng pipe, o direktang pagkatapos ng filename kapag lokal na kopya ang pinapatakbo. Ang mga kapaki-pakinabang na flag ay ang sumusunod: nilalaktawan ng -f ang disk test, nilalaktawan ng -i ang network test, nilalaktawan ng -g ang Geekbench, nililimitahan ng -r sa dalawa ang mga iperf3 location, ipinapakita ng -j ang resulta bilang JSON, at isinusulat ng -w results.json ang JSON sa isang file.

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

May dalawang bagay na dapat malaman bago ang unang run. Ina-upload ng Geekbench ang iyong resulta at nagpi-print ng public browser.geekbench.com URL, kaya mababasa ng sinumang may hawak ng link na iyon ang CPU model at scores mo. Ganap na nilalaktawan ng -g ang test na iyon. Ikalawa, ang iperf3 stage ay nagpapadala ng totoong traffic sa mga server sa ilang region, at ibinabawas ito sa iyong buwanang bandwidth allowance. Sa 1 Gbit/s link, maaaring umabot sa sampu-sampung gigabytes ang naililipat ng buong network stage, kaya gamitin ang -r kung maliit ang allowance at ang -i kung metered ang link.

Ano ang ibig sabihin ng bawat bahagi ng yabs output

Ang disk section ay nagpapatakbo ng fio gamit ang 50/50 na halo ng read at write sa apat na block size: 4k, 64k, 512k at 1m. Iniuulat nito ang IOPS (input/output operations per second) at bandwidth para sa bawat isa. Ang 4k row ang dapat pagtuunan ng pansin para sa database, mail server, o anumang gumagawa ng maraming maliliit na write, dahil karaniwang maliit at magkakahiwalay ang karamihan ng server IO. Ang 1m row naman ang mahalaga para sa backups at video, kung saan naglilipat ka ng mahahabang sunod-sunod na byte.

Ang network section ay nagpapatakbo ng iperf3 laban sa mga public server sa ilang region, sa parehong direksyon, gamit ang parallel streams. Ituring ang mababang resulta rito bilang tanong, hindi bilang tiyak na sagot, dahil shared at madalas saturated ang mga public iperf3 server. Maaaring sa kabilang dulo nagmula ang mahinang resulta.

Ang Geekbench section ay nagbibigay ng single core score at multi core score. Ipinapakita ng single core kung gaano kabilis matatapos ang isang request, isang compile, o isang query. Pangunahing ipinapakita ng multi core kung ilang core talaga ang nakuha mo.

Disk: patakbuhin ang fio mismo

Ang fio (flexible IO tester) ang tool sa likod ng disk section ng yabs. Kapag direkta mo itong pinatakbo, mas malinaw ang ibig sabihin ng mga flag.

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

Isang 4k random read test na may queue depth na 32, sa filesystem na aktuwal mong gagamitin:

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

Ganito ang summary line na dapat mong basahin mula sa output.

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

Sa ilalim nito, nagpi-print ang fio ng clat percentiles block. Ang 99.00th percentile ang dapat i-quote dahil ipinapakita nito kung gaano katagal naghintay ang pinakamabagal na request sa bawat 100 request. Itinatago ng average latency ang mismong mga stall na napapansin ng user.

• Binubuksan ng --direct=1 ang file gamit ang O_DIRECT, kaya nilalampasan ng reads ang kernel page cache. Kung wala ito, ang second pass sa 2G file sa machine na may 8G RAM ay magmumula sa memory, at mag-uulat ang fio ng IOPS na nasa milyon. Totoo ang numerong iyon, pero memory number ito.
• Nagsa-submit ang --ioengine=libaio ng asynchronous requests. Dahil dito, kayang panatilihin ng --iodepth=32 na may 32 request na in flight. Sa synchronous engine gaya ng psync, walang epekto ang iodepth na higit sa 1. Isang request lang bawat pagkakataon ang sinusukat mo.
• Tumatakbo ang --time_based --runtime=60 sa fixed na 60 seconds sa halip na sa fixed na dami ng work. Dahil dito, pareho ang wall clock time ng mabilis at mabagal na disk, kaya patas ang comparison.
• Itinatakda ng --size=2G ang laki ng test file. Panatilihin itong mas malaki kaysa sa anumang cache sa path, at tiyaking sapat muna ang free space.

Pareho ang command para sa random write, ngunit gamitin ang --rw=randwrite. Patakbuhin ito nang hiwalay, pagkatapos ay i-delete ang 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

Para sa mix na mas malapit sa aktuwal na traffic, gamitin ang --rw=randrw --rwmixread=70. Mas malaki ang epekto sa mga resultang ito ng storage class na ginagamit mo kaysa sa anumang flag. Tinalakay ang pagkakaibang ito sa pagkakaiba ng NVMe at SATA SSD storage sa isang VPS.

When fio stops with Unknown error -1

Direct IO is not available on every filesystem. overlay, the filesystem Docker gives a container by default, and several network filesystems do not support O_DIRECT, so libaio submits a request the kernel cannot complete and fio gives up:

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

Run df -hT . first. If the Type column says overlay, point --filename at a path on real storage such as a bind mounted volume, or run fio on the host instead of in the container. If real storage is out of reach, a buffered synchronous run at least proves the command itself is correct.

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

Be honest about what that run is. After the first pass the 256M file sits in the page cache, so the IOPS figure describes your RAM. Use it to confirm fio is installed and the flags parse. Never quote it as a disk result.

Bakit hindi disk benchmark ang dd

Madalas lumilitaw ang dd sa mga VPS thread, at isang makitid na tanong lamang ang sinasagot nito.

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

Sinusukat nito ang sequential write throughput gamit ang isang thread at isang request na in flight. Makatuwirang sanity check ito. Wala itong sinasabi tungkol sa random IO o tungkol sa mangyayari kapag sabay-sabay na dumating ang 32 request. Alisin ang oflag=direct, at karaniwan nitong sinusukat kung gaano kabilis tumanggap ang kernel mo ng mga write sa memory, kaya madalas katawa-tawa ang mga numerong dd na binabanggit sa mga forum post.

CPU: sysbench cpu

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

Ang dapat panatilihin ay events per second. Unang patakbuhin ito gamit ang isang thread. Ito ang bilang na tumutukoy kung gaano kabilis matatapos ang isang PHP request o isang compile job, at ito rin ang pinakamaraming nagkakaiba sa pagitan ng mga host na pareho ang presyo. Pagkatapos, patakbuhin ito gamit ang lahat ng thread. Ipinapakita nito kung magkakahiwalay na core ang iyong vCPU o mga slice lamang ng iisang core.

Maging malinaw sa sinusukat nito: paulit-ulit na naghahanap ang sysbench cpu ng mga prime number gamit ang 64-bit integer arithmetic. Hindi nito sinusubok ang memory bandwidth, vector unit, o cache sa paraang kahawig ng aktuwal na workload. Kaya mabuti ito para paghambingin ang dalawang host, pero hindi ito maaasahan sa pagtaya kung paano tatakbo ang iyong application.

Kasama sa Ubuntu 24.04 ang sysbench 1.0.20, kung saan nauuna ang pangalan ng test. Kapag kinopya mo ang command na may --test=cpu mula sa isang lumang post, makukuha mo ang WARNING: the --test option is deprecated. Hindi maihahambing ang mga score mula sa sysbench 0.4 at sysbench 1.0. Kaya huwag kailanman ihambing ang resulta mo sa isang inilathalang number na hindi nagsasaad ng bersyon nito.

Memory: 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

Ang resulta ay nasa MiB/sec, at mas mabilis ang read kaysa write sa bawat machine. Panatilihin ang --memory-block-size sa 1M, at tiyaking pareho ito sa bawat host na ikinukumpara. Sa 1K, bumabagsak nang malaki ang resulta dahil 1,000 beses na mas madalas mong binabayaran ang overhead ng bawat operation. Dahil dito, loop cost ang nasusukat sa halip na memory bandwidth. Ito ang flag na pinakamadalas magkaroon ng magkakaibang value sa mga na-publish na memory score.

Network: iperf3

Ang tapat na paraan ng pagsukat ng throughput ay gumamit ng pangalawang machine na kontrolado mo. Sa ganitong paraan, alam mo kung ano ang ginagawa ng magkabilang dulo.

Sa kabilang dulo:

iperf3 -s

Nakikinig ito sa TCP 5201. Buksan lamang ang port para sa address na pinanggagalingan ng test, at isara ito kapag tapos ka na. Sinasaklaw ng Mga basic ufw firewall rule sa isang VPS ang syntax.

Mula sa VPS na tine-test:

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

Sinusukat ng una ang upload mula sa machine na tine-test. Binabaligtad ng -R ang direksyon, kaya download ang sinusukat nito. Binubuksan ng -P 8 ang walong parallel stream.

Patakbuhin pareho ang single stream at ang parallel na bersyon, dahil magkaibang tanong ang sinasagot ng mga ito. Isang TCP connection lamang ang kayang magpanatili ng kasing daming unacknowledged data na pinapayagan ng window nito. Kaya ang limitasyon nito ay humigit-kumulang window size na hinati sa round trip time. Sa 80 ms na latency at 4 MB na window, nasa 400 Mbit/s ang limitasyong iyon, gaano man kabilis ang link sa ilalim nito. Ipinapakita ng single stream na resulta kung gaano karaming throughput ang makukuha ng isang download. Ipinapakita naman ng parallel na resulta ang capacity ng link.

Bantayan ang bandwidth allowance habang ginagawa mo ito. Sa loob ng 30 segundo sa 1 Gbit/s, humigit-kumulang 3.75 GB ang naililipat, at ilang beses mo itong patatakbuhin sa bawat direksyon.

Mga reference figure at kung paano basahin ang resulta mo

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

Ang local NVMe volume sa mga published result ay karaniwang nasa 180,000 4k random read IOPS. Ang local SATA SSD ay nasa humigit-kumulang 90,000. Ang network-attached block storage, kung saan dumadaan muna sa network ang bawat request bago makarating sa disk, ay mas malapit sa 12,000, habang ang spinning disk ay nakakakuha ng humigit-kumulang 180, dahil ginagalaw nito ang physical head sa bawat random request.

Mga karaniwang published figure ito para sa bawat storage class, hindi mga sukat mula sa iisang host. Gamitin ang mga ito para sa isang layunin: suriin kung nasa tamang order of magnitude ang sarili mong resulta. Kung ang planong ibinebenta bilang NVMe ay nagbe-benchmark sa mababang libo ng 4k IOPS, kumpirmahin muna na naka-on ang --direct=1. Kung naka-on ito, maaaring hindi tugma ang storage sa inilalarawan ng product page, o ginagamit mo ito kasama ng isang napakaabalang katabing tenant.

Bakit hindi benchmark ang isang run

Ang isang resulta ay snapshot lamang ng isang minuto sa isang shared machine. Ituring ito bilang isang sample.

• Patakbuhin ang bawat test nang hindi bababa sa limang beses, sa magkakaibang oras at sa hindi bababa sa dalawang magkaibang araw. Itago ang median at ang spread. Ang resultang inilathala nang walang spread ay marketing figure.
• Itala ang steal time kasabay ng bawat run. Itapon ang mga run kung mataas ang st, o itala man lang na mataas ito.
• Patakbuhin ang disk test sa dalawang duration. Maraming plan ang nagbibigay ng burst IOPS allowance na unti-unting napupunan muli, kaya sinusukat ng 60 second na fio run ang burst habang sinusukat ng --runtime=600 ang floor. Ang floor ang makukuha mo sa masamang araw.
• Tiyaking walang ibang tumatakbo. Kapag nagsimula ang unattended-upgrades ng apt transaction sa gitna ng CPU test, mababawasan talaga ang score mo, at isang segundo lamang ang kailangan ng ps -e -o comm= | grep -E 'apt|dpkg' bago ang bawat run.
• Isang variable lamang ang baguhin sa bawat pagkakataon. Ang magkakaibang tool version, block size, o thread count ay gumagawa ng mga numerong hindi maihahambing, gaano man sila magkamukha.

Kapag nagkumpara ka ng dalawang provider, patakbuhin ang mga ito sa parehong oras ng parehong araw. Kung hindi, oras ng araw ang nasukat mo.

Huling i-benchmark ang sarili mong workload

Nagre-rank ng mga machine ang mga synthetic tool. Sarili mong workload lang ang makapagsasabi kung sapat ang isang machine. I-time ang aktuwal mong ginagawa.

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

Kino-compress nito ang ilang daang megabyte, kaya sabay nitong sinusubok ang CPU at disk, at nagbabago ang resulta kapag nagbago ang alinman sa mga ito. Normal ang warning na Removing leading / from member names. Mas mabuti pa, i-time ang sarili mong build, ang sarili mong pinakamabagal na query, o ang sarili mong page render. Kung tumatagal ng 4 minuto ang build sa isang host at 7 minuto sa isa pa, malinaw na ang sagot, anuman ang naging resulta sa Geekbench. Ito rin ang measurement na magsasabi kung kailan hindi na sulit bayaran ang mas malakas na machine. Mahalagang malaman ito bago mo basahin kung magkano talaga ang halaga ng isang VPS bawat buwan o ilipat ang workload sa isang dedicated server.

FAQ

Bakit iba ang resulta ng benchmark sa bawat pagpapatakbo ko?

Nakikigamit ang isang VPS ng physical CPU, storage, at network sa iba pang tenant, kaya nakadepende ang resulta sa ginagawa nila sa oras na iyon. Patakbuhin ang vmstat 1 habang isinasagawa ang test at basahin ang column na st: kapag lampas 5 ang sustained steal time, abala ang host, at mababa ang CPU score mo dahil sa mga dahilang wala sa machine mo. Ang solusyon ay tamang method, hindi tuning. Patakbuhin ang bawat test nang lima o higit pang beses sa magkakaibang oras, pagkatapos ay iulat ang median kasama ang spread.

Bakit nag-uulat ang fio ng milyun-milyong IOPS?

Halos palagi itong nangyayari dahil nawawala ang --direct=1. Kung wala ito, nagbabasa ang fio sa kernel page cache. Kaya pagkatapos ng unang pass, mula sa RAM inihahatid ang 2G test file at memory bandwidth ang aktuwal mong nasusukat. Idagdag ang --direct=1 at tiyaking mas malaki ang test file kaysa sa anumang cache sa path. Kung mabigo ang --direct=1 gamit ang err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1, patakbuhin ang df -hT .: hindi sinusuportahan ng Type na overlay ang O_DIRECT, kaya ituro ang test sa aktuwal na storage.

Sapat na ba nang mag-isa ang yabs.sh?

Para sa paunang pagsusuri, oo. Pinapatakbo nito ang fio sa apat na block size, ang iperf3 sa parehong direksiyon, at ang Geekbench. Nagpi-print din ito ng isang summary na mababasa ng iba. Hindi na ito sapat kapag gusto mong malaman kung bakit ganoon ang isang number, dahil hindi mo maiaangkop ang mga flag nito sa bawat test. Kapag mukhang mali ang resulta ng yabs, ulitin ang test gamit ang fio o sysbench nang direkta at magpalit ng isang flag bawat pagkakataon.

Aling iisang number ang pinakamalinaw na nagpapakita kung ano ang magiging pakiramdam ng application ko?

Para sa karamihan ng web at database workload, ang single-core CPU speed at 4k random read latency, sa ganoong pagkakasunod-sunod. Kahanga-hanga tingnan ang throughput figures, pero bihira silang maging mapagpasya dahil maliit ang karaniwang request. Iulat ang 99th percentile mula sa fio clat percentiles block sa halip na average, dahil ang isang mabagal na request sa bawat sandaaan ang napapansin ng user.

Kailangan ko bang mag-install ng anuman bago mag-benchmark?

Nasa Ubuntu at Debian archive ang fio, sysbench, at iperf3: sudo apt install -y fio sysbench iperf3. yabs.sh ay nangangailangan lamang ng curl, dahil nagda-download ito ng static binaries para sa anumang nawawala. Burahin ang lahat ng test file kapag tapos ka na. Kung maiiwan ang 2G fio file sa 20G disk, maaari itong maging sanhi ng disk full alert pagkalipas ng ilang linggo.