Paano Mag-benchmark ng VPS nang Tama

Ano ang ibig sabihin ng pag-benchmark ng isang 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 na random disk operation ang naihahatid ng storage bawat segundo, at kung gaano kalaking throughput ang naihahatid ng network link. Isang run ng yabs.sh ang nagbibigay sa iyo ng lahat ng ito sa loob ng humigit-kumulang sampung minuto. Mas mahirap basahin ang resulta, dahil nakikihati 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 rito ay patakbuhin muna ang yabs.sh para sa mabilis na pangkalahatang larawan, at pagkatapos ay manu-manong patakbuhin ang mga tool na ginagamit nito. Kapag ikaw mismo ang nagpapatakbo sa mga ito, maaari mong baguhin ang isang flag, obserbahan kung paano nagbabago ang value, at matutuhan kung ano talaga ang sinusukat ng value na iyon. Gawin ito pagkatapos ma-set up ang machine, hindi bago. Unahin ang mga hakbang sa unang sampung minuto sa bagong VPS, dahil hindi maayos ang resulta ng benchmark ng isang machine na inilalapat pa ang unang batch ng updates. Ang mga dahilan nito ay walang kinalaman sa hardware.

Suriin ang machine bago ito sukatin

Ang kalahati ng bawat hindi maaasahang benchmark ay dulot ng machine na hindi naunawaan ng sumulat.

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 lxc o openvz ng systemd-detect-virt ay nangangahulugang container virtualisation naman: ginagamit mo ang kernel ng host, at ang CPU at memory limit mo ay mga setting ng cgroup (control group), hindi virtual hardware. Sa cgroup v2 system, direktang mababasa 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 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 linyang nagsasabi kung bakit.

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

Bantayan ang steal time sa buong oras

Ang steal time ay bahagi ng oras kung kailan handang tumakbo ang iyong virtual CPU, pero ipinagamit ng hypervisor ang physical core sa ibang virtual machine. Ito ang pinakamalinaw na signal na nagpapakitang ang resulta ay dulot ng ibang gumagamit ng host, hindi ng hardware.

vmstat 1 10

Basahin ang column na st sa kanan. Normal ang tuloy-tuloy na 0 o 1. Ibig sabihin ng mga value na lampas 5 nang tuloy-tuloy na overloaded ang host sa sandaling iyon. Kaya mababa ang bawat CPU number na maire-record mo sa window na iyon, kahit walang problema ang iyong machine. Ipinapakita ng top ang kaparehong figure ng %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

Ang yabs.sh (Yet Another Bench Script) ay isang shell script na nagda-download ng static na 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 benchmark, kaya ang yabs output ang pinakamabilis na paraan upang maikumpara ang resulta mo sa resulta ng iba.

Ito ang one-line form mula mismo sa project.

curl -sL yabs.sh | bash

Direktang ipinapasa nito sa shell ang anumang kasalukuyang inihahatid ng URL. I-download muna ito, basahin, at 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 mga flag pagkatapos ng -s -- kapag gumagamit ka ng pipe, o direktang pagkatapos ng filename kapag lokal na kopya ang pinapatakbo mo. 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 resulta mo at nagpi-print ng public na URL sa browser.geekbench.com, kaya mababasa ng sinumang may link ang CPU model at mga score mo. Ganap na nilalaktawan ng -g ang test na iyon. Ikalawa, ang iperf3 stage ay naglilipat ng aktuwal na network traffic sa mga server sa ilang region, at ibinabawas ito sa buwanang bandwidth allowance mo. Sa 1 Gbit/s na link, maaaring umabot sa sampu-sampung gigabyte 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

Gumagamit ang disk section ng fio na may 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 maliit at magkakahiwalay ang karamihan sa server IO. Ang 1m row naman ang para sa mga backup at video, kung saan mahahabang sunod-sunod na byte ang inililipat.

Gumagamit ang network section ng iperf3 laban sa mga public server sa ilang rehiyon, sa parehong direksyon, gamit ang parallel stream. Ituring ang mababang resulta rito bilang tanong, hindi bilang tiyak na sagot, dahil shared at madalas saturated ang mga public iperf3 server. Kaya maaaring ang malayong endpoint ang sanhi ng mahinang resulta.

Nagbibigay ang Geekbench section ng single core score at multi core score. Tinatantiya 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 ilalim ng disk section ng yabs. Kapag direkta mo itong pinatakbo, mas mauunawaan ang kahulugan 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 halagang dapat banggitin, dahil ipinapakita nito kung gaano katagal naghintay ang pinakamabagal na 1 request sa bawat 100. Itinatago ng average latency ang mismong mga pagkaantala na napapansin ng user.

• Binubuksan ng --direct=1 ang file gamit ang O_DIRECT, kaya hindi dumaraan ang reads sa kernel page cache. Kung wala ito, ang second pass sa isang 2G file sa machine na may 8G RAM ay manggagaling sa memory at magrereport ang fio ng IOPS na nasa millions. 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 kasalukuyang tumatakbo. Sa synchronous engine gaya ng psync, walang epekto ang iodepth na higit sa 1, kaya isang request lang bawat pagkakataon ang sinusukat.
• Pinapatakbo ng --time_based --runtime=60 ang test sa nakapirming 60 segundo sa halip na sa nakapirming dami ng work. Dahil dito, pareho ang wall clock time para sa 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 may sapat na free space muna.

Pareho ang command para sa random write, pero 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 totoong traffic, gamitin ang --rw=randrw --rwmixread=70. Mas malaki ang epekto sa mga resultang ito ng uri ng storage na ginagamit mo kaysa sa alinmang flag. Saklaw ng pagkakaiba ng NVMe at SATA SSD storage sa isang VPS ang split na iyon.

Kapag huminto ang fio dahil sa Unknown error -1

Hindi available ang direct IO sa bawat filesystem. Hindi sinusuportahan ng overlay, ang filesystem na ibinibigay ng Docker sa isang container bilang default, at ng ilang network filesystem ang O_DIRECT. Dahil dito, nagsusumite ang libaio ng request na hindi makumpleto ng kernel, kaya sumusuko 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 na nasa 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, makapagpapatunay man lang ang buffered synchronous run na tama ang command mismo.

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 malinaw sa ipinapakita ng run na iyon. Pagkatapos ng unang pass, nasa page cache na ang 256M file, kaya RAM mo ang inilalarawan ng IOPS figure. Gamitin ito upang kumpirmahing naka-install ang fio at tama ang pag-parse sa mga flag. Huwag itong iulat bilang resulta ng disk.

Bakit hindi disk benchmark ang dd

dd ay madalas lumalabas sa mga thread tungkol sa VPS, at isang tiyak 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 kasalukuyang pinoproseso. Makatuwiran itong sanity check. Wala itong sinasabi tungkol sa random IO, at wala rin tungkol sa mangyayari kapag sabay-sabay na dumating ang 32 request. Alisin ang oflag=direct, at kadalasan ay sinusukat lamang nito kung gaano kabilis tumanggap ang kernel ng mga write sa memory, kaya madalas katawa-tawa ang mga halagang 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 figure ay events per second. Patakbuhin muna ito gamit ang isang thread. Ito ang nagsasabi kung gaano kabilis matatapos ang isang PHP request o isang compile job, at ito ang pinakamadalas magkaiba 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 mga vCPU o mga slice 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 isang tunay na workload. Kaya mahusay ito para paghambingin ang dalawang host, ngunit hindi ito maaasahan para hulaan kung paano tatakbo ang iyong application.

May sysbench 1.0.20 ang Ubuntu 24.04, 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 talaga maihahambing ang mga score mula sa sysbench 0.4 at sysbench 1.0. Kaya huwag kailanman ihambing ang resulta mo sa isang published na 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 read kaysa write sa bawat machine. Panatilihin ang --memory-block-size sa 1M, at tiyaking pareho ito sa lahat ng host na ikinukumpara mo. Sa 1K, bumabagsak ang resulta dahil 1,000 beses na mas madalas mong binabayaran ang per-operation overhead. Kaya ang nasusukat mo ay loop cost sa halip na memory bandwidth. Ito ang flag na pinakamadalas hindi nagtutugma sa mga inilalathalang memory score.

Network: iperf3

Ang maaasahang paraan para subukan ang throughput ay gumamit ng pangalawang machine na kontrolado mo. Sa ganitong paraan, alam mo kung ano ang nangyayari sa magkabilang dulo.

Sa remote end:

iperf3 -s

Nakikinig ito sa TCP 5201. Buksan ang port para lamang sa address na gagamitin mo sa pag-test, at isara ito kapag tapos ka na. Saklaw ng Mga pangunahing ufw firewall rule sa isang 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 pareho ang single stream at ang parallel version dahil magkaibang tanong ang sinasagot ng mga ito. Isang TCP connection lang ang kayang magpanatili ng dami ng unacknowledged data na pinapayagan ng window nito. Kaya ang limit 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 limit na iyon, gaano man kabilis ang link sa ilalim nito. Ipinapakita ng single stream figure kung ano ang makukuha ng isang download. Ipinapakita naman ng parallel figure ang capacity ng link.

Bantayan ang iyong bandwidth allowance habang ginagawa ito. Sa loob ng 30 segundo sa 1 Gbit/s, humigit-kumulang 3.75 GB ang maililipat, at patatakbuhin mo ito nang ilang beses 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 sa network ang bawat request bago ito makarating sa disk, ay mas malapit sa 12,000, at ang spinning disk ay karaniwang nakakakuha ng humigit-kumulang 180, dahil gumagalaw ito ng physical head para sa bawat random request.

Karaniwang published figure ang mga ito para sa bawat klase ng storage, hindi mga measurement mula sa iisang host. Gamitin ang mga ito para sa isang layunin: tiyaking nasa tamang order of magnitude ang sarili mong resulta. Kung ang isang plan na ibinebenta bilang NVMe ay nag-benchmark sa mababang libo ng 4k IOPS, tiyakin muna na naka-on ang --direct=1. Kung naka-on ito, maaaring hindi tumutugma ang storage sa inilalarawan ng product page, o ginagamit mo ito kasabay 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. Itala 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 unti-unting napupuno muli, kaya sinusukat ng 60 second na fio run ang burst samantalang 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 lang ang kailangan para sa 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 gumagawa ng mga numerong hindi maihahambing, gaano man sila magkahawig.

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

Huling i-benchmark ang sarili mong workload

Nagbibigay ng ranggo sa mga machine ang 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

Kino-compress nito ang ilang daang megabyte, kaya sabay nitong ginagamit ang CPU at disk. Nagbabago ang resulta kapag nagbago ang alinman sa mga ito. Normal ang babalang Removing leading / from member names. Mas mainam pa ring 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 minuto sa isa pa, malinaw na ang sagot, anuman ang naging resulta sa Geekbench. Ito rin ang sukat na magsasabi kung kailan hindi na sulit bayaran ang mas makapangyarihang machine. Mahalagang malaman ito bago mo basahin kung magkano talaga ang VPS bawat buwan o ilipat ang workload sa dedicated server.

FAQ

Bakit iba-iba ang resulta ng benchmark sa bawat pag-run ko?

Nakikibahagi ang isang VPS ng physical CPU, storage, at network sa iba pang tenant, kaya nakadepende ang resulta sa ginagawa nila sa sandaling 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 salik na wala sa iyong machine. Paraan ang dapat ayusin, hindi tuning. Patakbuhin ang bawat test nang limang beses o higit pa sa magkakaibang oras, pagkatapos ay iulat ang median kasama ang spread.

Bakit milyun-milyong IOPS ang iniuulat ng fio?

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

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

Para sa unang 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 ibang tao. Hindi na ito sapat kapag gusto mong malaman kung bakit ganoon ang isang resulta, dahil hindi mo mababago ang mga flag nito bawat test. Kapag mukhang mali ang resulta ng yabs, kopyahin ang test gamit ang fio o sysbench nang direkta at isang flag lang ang baguhin sa bawat pagkakataon.

Aling iisang numero ang pinakamainam na prediktor sa magiging pakiramdam ng application ko?

Para sa karamihan ng web at database workload, ang bilis ng single-core CPU at ang 4k random read latency, ayon sa pagkakasunod na iyon. Mukhang kahanga-hanga ang throughput figure, pero bihira itong maging mapagpasya dahil maliit ang karaniwang request. Iulat ang 99th percentile mula sa fio clat percentiles block sa halip na average, dahil ang mabagal na isang request sa bawat 100 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. Ang yabs.sh ay nangangailangan lamang ng curl dahil nagda-download ito ng static binary para sa anumang nawawala. Tanggalin ang bawat test file kapag tapos ka na, dahil ang 2G fio file na naiwan sa 20G disk ay maaaring maging alerto na puno na ang disk pagkalipas ng ilang linggo.