Paano mag-benchmark ng VPS nang tama

Ano ang ibig sabihin ng pag-benchmark ng VPS

Para mag-benchmark ng VPS, sinusukat mo ang apat na bagay: kung gaano kabilis tumakbo ang isang CPU core, kung gaano kalaki ang memory bandwidth ng machine, kung ilang maliliit at random na disk operation ang kayang ihatid ng storage bawat segundo, at kung gaano kalaking throughput ang naihahatid 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 ang isang VPS (virtual private server) ay nakikibahagi sa physical hardware sa iba pang tenant. Dahil dito, maaaring mag-ulat ang parehong machine ng isang numero sa 03:00 at ibang-iba naman sa 20:00.

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

Suriin ang machine bago ito sukatin

Ang kalahati ng bawat maling benchmark ay dulot ng 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 lxc o openvz ay nangangahulugang container virtualisation naman: ginagamit mo ang kernel ng host, at ang mga limitasyon sa CPU at memory ay mga setting ng cgroup (control group), hindi virtual hardware. Sa system na may cgroup v2, mababasa mo nang direkta ang limitasyon sa CPU.

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 katumbas ng apat na core, at walang benchmark tool na magpi-print ng linya na nagpapaliwanag kung bakit.

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

Patuloy na subaybayan ang steal time

Ang steal time ay bahagi ng oras kung kailan handa nang tumakbo ang iyong virtual CPU ngunit ipinagamit ng hypervisor ang physical core sa ibang user. Ito ang pinakamainam na iisang signal para matukoy kung ang resulta ay sanhi ng ibang tenant at hindi ng hardware.

vmstat 1 10

Basahin ang column na st sa kanan. Normal ang tuloy-tuloy na 0 o 1. Ang mga value na tuloy-tuloy na lampas 5 ay nangangahulugang overloaded ang host sa oras na iyon. Kaya mababa ang bawat CPU number na makukuha mo sa panahong iyon, at hindi ito kasalanan ng iyong machine. Ipinapakita ng top ang kaparehong figure ng %st sa CPU line. Panatilihing tumatakbo ang vmstat 1 sa pangalawang SSH session habang nagsasagawa ka ng benchmark, at itala ang steal figure sa tabi ng bawat resulta.

Magsimula sa yabs.sh

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

Ito ang one-line form na ginagamit mismo ng proyekto.

curl -sL yabs.sh | bash

Ipinapasa nito sa shell ang anumang kasalukuyang inihahatid ng URL. I-download 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

Ilagay ang mga flag pagkatapos ng -s -- kapag nagpi-pipe, o direktang pagkatapos ng filename kapag nagpapatakbo ng lokal na kopya. Ang mga kapaki-pakinabang na flag ay: nilalaktawan ng -f ang disk test, nilalaktawan ng -i ang network test, nilalaktawan ng -g ang Geekbench, binabawasan ng -r sa dalawa ang mga lokasyon ng iperf3, ipinapakita ng -j ang mga 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 pagtakbo. Ina-upload ng Geekbench ang iyong resulta at nagpi-print ng pampublikong browser.geekbench.com URL, kaya mababasa ng sinumang may hawak ng link na iyon ang modelo ng iyong CPU at ang mga score. Nilalaktawan nang buo ng -g ang test na ito. Ikalawa, naglilipat ang iperf3 stage ng aktuwal na network traffic sa mga server sa ilang rehiyon, at ibinabawas ito sa iyong buwanang bandwidth allowance. Sa 1 Gbit/s na link, maaaring umabot sa sampu-sampung gigabyte ang network stage, kaya gamitin ang -r kung maliit ang allowance at ang -i sa metered link.

Kahulugan ng bawat bahagi ng output ng yabs

Pinapatakbo ng disk section ang fio gamit ang 50/50 na kombinasyon 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 bigyang-pansin para sa database, mail server, o anumang gumagawa ng maraming maliliit na write, dahil maliit at kalat-kalat ang karamihan ng server IO. Ang 1m row naman ang para sa mga backup at video, kung saan inililipat ang mahahabang sunod-sunod na byte.

Pinapatakbo ng network section ang iperf3 laban sa mga public server sa ilang region, sa parehong direksiyon, gamit ang parallel stream. Ituring ang mababang resulta rito bilang tanong at hindi bilang tiyak na sagot, dahil pinaghahatian ang mga public iperf3 server at madalas na saturated. Kaya maaaring sa kabilang dulo nagmula ang mahinang resulta.

Nagbibigay ang Geekbench section 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 naman ng multi core kung ilang core ang aktuwal mong nakuha.

Disk: patakbuhin mismo ang fio

Ang fio (flexible IO tester) ang tool sa likod ng disk section ng yabs. Kapag direktang pinatakbo ito, mas mauunawaan ang ibig sabihin ng mga flag.

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

Isang 4k random read test sa queue depth na 32, gamit ang filesystem na aktuwal mong sinusuri:

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 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 ikalawang pass sa 2G file sa machine na may 8G RAM ay manggagaling sa memory, at magrereport ang fio ng IOPS na milyon-milyon. Totoo ang numerong iyon, pero numero iyon ng memory.
• Nagsusumite ang --ioengine=libaio ng asynchronous requests. Dahil dito, napapanatili ng --iodepth=32 na may 32 request na kasalukuyang ginagawa. Sa synchronous engine gaya ng psync, walang epekto ang iodepth na lampas sa 1, kaya isang request lang bawat pagkakataon ang sinusukat.
• Pinapatakbo ng --time_based --runtime=60 ang test sa fixed na 60 segundo sa halip na sa fixed na dami ng trabaho. Dahil dito, pareho ang wall-clock time para sa mabilis at mabagal na disk, kaya patas ang paghahambing.
• Itinatakda ng --size=2G ang laki ng test file. Panatilihin itong mas malaki kaysa sa anumang cache sa path, at tiyaking may sapat na libreng space bago magsimula.

Pareho ang command para sa random write, ngunit gamitin ang --rw=randwrite. Patakbuhin ito nang hiwalay, pagkatapos ay burahin 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 network traffic, gamitin ang --rw=randrw --rwmixread=70. Mas malaki ang epekto sa mga resultang ito ng klase ng storage na ginagamit mo kaysa sa anumang flag. Saklaw ang pagkakaibang iyon sa pagkakaiba ng NVMe at SATA SSD storage sa isang VPS.

Kapag huminto ang fio na may Unknown error -1

Hindi available ang Direct IO sa bawat filesystem. Hindi sinusuportahan ng overlay, ang filesystem na awtomatikong ibinibigay ng Docker sa isang container, at ng ilang network filesystem ang O_DIRECT. Dahil dito, nagsusumite ang libaio ng request na hindi kayang kumpletuhin ng kernel, kaya humihinto ang 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

Patakbuhin muna ang df -hT .. Kung overlay ang nakalagay sa column na Type, ituro ang --filename sa path sa aktuwal na storage, gaya ng bind mounted volume, o patakbuhin ang fio sa host sa halip na sa container. Kung hindi maabot ang aktuwal na storage, sapat na pansamantalang patunay sa pagiging tama ng command ang buffered synchronous run.

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

Maging tumpak sa paglalarawan sa run na iyon. Pagkatapos ng unang pass, nananatili ang 256M file sa page cache, kaya inilalarawan ng IOPS figure ang RAM mo. Gamitin ito para kumpirmahing naka-install ang fio at tama ang pag-parse sa mga flag. Huwag itong banggitin bilang resulta ng disk.

Bakit hindi disk benchmark ang dd

Madalas lumitaw ang dd sa mga thread tungkol sa VPS, at sinasagot nito ang isang partikular na tanong.

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 nasa flight. Makatuwiran itong sanity check. Wala itong sinasabi tungkol sa random IO o tungkol sa nangyayari kapag 32 request ang sabay-sabay na dumarating. Alisin ang oflag=direct, at kadalasan ay sinusukat lang nito kung gaano kabilis tumatanggap ang iyong kernel ng mga write papunta sa memory, kaya madalas na katawa-tawa ang mga numerong dd na binabanggit sa mga post sa forum.

CPU: sysbench cpu

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

Ang dapat tandaan na resulta ay events per second. Patakbuhin muna gamit ang isang thread. Ito ang bilang na tumutukoy kung gaano kabilis makumpleto ang isang PHP request o isang compile job. Ito rin ang resultang pinakamadalas magkaiba sa mga host na pareho ang presyo. Pagkatapos, patakbuhin gamit ang lahat ng thread. Ipinapakita nito kung magkakahiwalay na core ang iyong vCPU o mga bahagi lamang ng iisang core.

Linawin kung ano ang 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 kapaki-pakinabang ito sa pagraranggo ng dalawang host, ngunit hindi ito maaasahan para hulaan kung paano tatakbo ang iyong application.

Ang Ubuntu 24.04 ay may sysbench 1.0.20, kung saan nauuna ang pangalan ng test. Kung kokopya ka ng command na may --test=cpu mula sa 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 sarili mong resulta sa isang inilathalang numero kung hindi nakasaad ang 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 pagbasa kaysa pagsusulat sa bawat machine. Panatilihing 1M ang --memory-block-size, at tiyaking pareho ito sa bawat host na ikinukumpara mo. Sa 1K, bumabagsak ang resulta dahil 1,000 beses na mas madalas mong binabayaran ang overhead sa bawat operation. Dahil dito, ang nasusukat mo ay ang loop cost sa halip na memory bandwidth. Ito ang flag na pinakamadalas magkaroon ng hindi tugmang value sa mga inilalathalang memory score.

Network: iperf3

Ang tamang paraan para subukan ang throughput ay gumamit ng pangalawang machine na kontrolado mo, dahil alam mo kung ano ang ginagawa ng magkabilang dulo.

Sa remote na dulo:

iperf3 -s

Nakikinig ito sa TCP 5201. Buksan lang ang port para sa address na gagamitin mo sa test, at isara ito kapag tapos ka na. Saklaw ng Mga pangunahing ufw firewall rule sa VPS ang syntax.

Mula sa VPS na sinusuri:

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 sinusuri. Binabaligtad ng -R ang direksyon, kaya download ang sinusukat nito. Nagbubukas ang -P 8 ng walong parallel stream.

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

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

Mga reference figure at kung paano basahin ang iyo

[
  {
    "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 isang local NVMe volume sa mga inilathalang resulta ay karaniwang nasa humigit-kumulang 180,000 4k random read IOPS. Ang local SATA SSD ay nasa paligid ng 90,000. Ang network attached block storage, kung saan dumadaan sa network ang bawat request bago ito makarating sa disk, ay mas malapit sa 12,000, habang ang spinning disk ay karaniwang nakakamit ng humigit-kumulang 180, dahil ginagalaw nito ang physical head para sa bawat random request.

Karaniwang published figures ang mga ito para sa bawat klase ng storage, hindi mga sukat mula sa isang host. Gamitin ang mga ito para sa isang layunin: tiyaking nasa tamang order of magnitude ang sarili mong resulta. Kung ang plan na ibinebentang NVMe ay nagbe-benchmark sa mababang libo ng 4k IOPS, kumpirmahin muna kung 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 kapitbahay.

Bakit hindi benchmark ang isang run

Ang isang resulta ay snapshot 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 sa tabi ng bawat run. Alisin 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 muling napupunan sa paglipas ng panahon, 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 tumatagal ng isang segundo ang ps -e -o comm= | grep -E 'apt|dpkg' bago ang bawat run.
• Isang variable lang ang baguhin sa bawat pagkakataon. Ang magkakaibang tool version, block size o thread count ay nagbubunga ng mga numerong hindi maihahambing, gaano man sila magkamukha.

Kapag naghambing ka ng dalawang provider, patakbuhin sila sa parehong oras ng parehong araw. Kung hindi, oras ng araw ang nasukat mo.

Huling i-benchmark ang sarili mong workload

Nagra-rank ng mga machine ang mga synthetic tool. Ang sarili mong workload lang ang makapagsasabi kung sapat ang isang machine. Sukatin ang oras ng aktuwal mong ginagawa.

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

Iko-compress nito ang ilang daang megabytes, kaya sabay nitong sinusubok ang CPU at disk, at nagbabago ang resulta kapag nagbago ang alinman sa mga ito. Normal ang babalang Removing leading / from member names. Mas mabuti pa, sukatin ang oras ng sarili mong build, ng pinakamabagal mong query, o ng sarili mong page render. Kung tumatagal ng 4 minuto ang build sa isang host at 7 sa isa pa, nasagot na nito ang tanong, anuman ang naging resulta sa Geekbench. Ito rin ang sukat 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?

Nakikibahagi ang isang VPS sa physical CPU, storage at network kasama ng ibang 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 tuloy-tuloy na lampas sa 5 ang steal time, abala ang host at mababa ang CPU score mo dahil sa mga salik na wala sa iyong machine. Ang tamang solusyon ay wastong 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 na inihahatid ang 2G test file at memory bandwidth ang nasusukat mo. Idagdag ang --direct=1 at tiyaking mas malaki ang test file kaysa sa anumang cache sa path. Kung mabigo ang --direct=1 kasama ang err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1, patakbuhin ang df -hT .: hindi sinusuportahan ng isang Type ng 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, at nagpi-print ito ng isang summary na mababasa ng ibang tao. Hindi na ito sapat kapag nais mong malaman kung bakit ganoon ang isang numero, dahil hindi mo mababago ang mga flag nito para sa bawat test. Kapag mukhang mali ang resulta ng yabs, ulitin ito nang direkta gamit ang fio o sysbench at baguhin ang isang flag bawat pagkakataon.

Aling iisang numero ang pinakamahusay na naghuhula kung ano ang magiging karanasan ko sa application?

Ang single core CPU speed at 4k random read latency, sa ganitong pagkakasunod-sunod, para sa karamihan ng web at database workload. Mukhang kahanga-hanga ang throughput figure ngunit bihira itong maging mapagpasya, dahil maliit ang karaniwang request. Iulat ang 99th percentile mula sa clat percentiles block ng fio sa halip na average, dahil ang isang mabagal na request sa bawat 100 ang napapansin ng user.

Kailangan ko bang mag-install muna 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. Tanggalin ang bawat test file kapag tapos ka na, dahil ang naiwan na 2G fio file sa 20G disk ay maaaring maging alert na puno na ang disk pagkalipas ng ilang linggo.