Jinsi ya kupima utendaji wa VPS kwa usahihi

Maana ya kufanya benchmark ya VPS

Ili kufanya benchmark ya VPS, unapima mambo manne: kasi ya kiini kimoja cha CPU, upana wa bendi ya kumbukumbu ambayo mashine inayo, idadi ya operesheni ndogo za nasibu za diski ambazo hifadhi inaweza kuhudumia kwa sekunde, na throughput inayotolewa na kiungo cha mtandao. Uendeshaji mmoja wa yabs.sh hukupa vipimo vyote vinne kwa takribani dakika kumi. Kusoma matokeo ndiyo sehemu ngumu zaidi, kwa sababu VPS (virtual private server) hushiriki maunzi halisi na wapangaji wengine. Kwa hiyo, mashine hiyo hiyo inaweza kuripoti thamani moja saa 03:00 na thamani tofauti sana saa 20:00.

Mpango hapa ni kuendesha yabs.sh ili kupata picha ya haraka, kisha kuendesha zana zilizo chini yake wewe mwenyewe. Kuzifanya mwenyewe ndiko kunakokuwezesha kubadilisha flag moja, kufuatilia namba inapobadilika, na kuelewa namba hiyo ilikuwa inapima nini hasa. Fanya hivi baada ya mashine kusanidiwa, si kabla. Hatua zilizo katika dakika kumi za kwanza kwenye VPS mpya zinatangulia, kwa sababu mashine ambayo bado inatumia sasisho zake za kwanza hutoa benchmark isiyo sahihi kwa sababu zisizohusiana na maunzi.

Kagua mashine kabla ya kuipima

Nusu ya kila kipimo-basi kisicho sahihi husababishwa na mashine ambayo mwandishi hakuielewa.

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

Hypervisor vendor: KVM inamaanisha uhalisia kamili, kwa hiyo unaendesha kernel yako mwenyewe. Kuchapisha lxc au openvz kwa kutumia systemd-detect-virt kunamaanisha uhalisia wa kontena badala yake: unashiriki kernel ya mwenyeji, na mipaka yako ya CPU na kumbukumbu ni mipangilio ya cgroup (control group), si maunzi ya uhalisia. Kwenye mfumo wa cgroup v2, unaweza kusoma kikomo cha CPU moja kwa moja.

cat /sys/fs/cgroup/cpu.max

max 100000 inamaanisha hakuna kiwango cha juu kilichowekwa. 200000 100000 inamaanisha unaweza kutumia mikrosekunde 200000 za CPU katika kila kipindi cha mikrosekunde 100000, sawa na kiwango cha matumizi cha cores mbili. Mpango unaotangazwa kuwa na 4 vCPU lakini wenye kiwango cha cores mbili hautawahi kupata matokeo sawa na cores nne, na zana yoyote ya kupima utendaji haichapishi mstari unaoeleza sababu.

df -hT / ni muhimu kwa sababu nyingine: safu wima ya Type. Ikiisoma overlay, uko ndani ya kontena, na jaribio la diski lililo hapa chini linahitaji mabadiliko. Izingatie sasa.

Fuatilia muda wa kuibiwa wakati wote

Muda wa kuibiwa ni sehemu ya muda ambao CPU yako pepe ilikuwa tayari kuendesha, lakini hypervisor ilikabidhi msingi halisi kwa mchakato mwingine. Hiki ndicho kiashiria kimoja muhimu zaidi kinachoonyesha kuwa matokeo yanatokana na majirani wako, si maunzi.

vmstat 1 10

Soma safu ya st upande wa kulia. Thamani thabiti ya 0 au 1 ni ya kawaida. Thamani zinazoendelea kuwa zaidi ya 5 zinaonyesha kuwa mwenyeji ana mzigo wa ziada kwa wakati huo. Kwa hiyo, kila nambari ya CPU utakayorekodi katika kipindi hicho itakuwa ndogo bila kosa lolote kutoka kwa mashine yako. top inaonyesha takwimu hiyo hiyo kama %st kwenye mstari wa CPU. Endelea kuendesha vmstat 1 katika kipindi cha pili cha SSH unapopima utendaji, na uandike thamani ya muda wa kuibiwa karibu na kila matokeo.

Anza na yabs.sh

yabs.sh (Yet Another Bench Script) ni hati ya shell inayopakua faili tuli za -s --, -f na Geekbench, kuziendesha, kisha kuchapisha muhtasari mmoja. Ni lugha inayotumiwa kwa kawaida katika mijadala ya vipimo vya VPS, hivyo matokeo ya yabs ndiyo njia ya haraka zaidi ya kulinganisha matokeo na mtu mwingine.

Amri ya mstari mmoja kutoka kwa mradi wenyewe ni hii.

curl -sL yabs.sh | bash

Hii hupitisha moja kwa moja kwenye shell chochote ambacho URL inatoa leo. Pakua, isome, kisha uiendeshe.

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

Chaguo huwekwa baada ya -s -- unapopitisha amri kupitia pipe, au moja kwa moja baada ya jina la faili unapotekeleza nakala ya ndani. Chaguo muhimu ni hizi: -f huruka jaribio la diski, -i huruka jaribio la mtandao, -g huruka Geekbench, -r hupunguza maeneo ya -f kuwa mawili, -j huchapisha matokeo katika JSON, na -w results.json huandika JSON hiyo kwenye faili.

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

Kuna mambo mawili ya kujua kabla ya utekelezaji wa kwanza. Geekbench hupakia matokeo yako na kuchapisha URL ya umma ya browser.geekbench.com, hivyo mtu yeyote aliye na kiungo hicho anaweza kusoma mfano wa CPU yako na alama zako. -g huruka jaribio hilo kabisa. Pili, hatua ya -f huhamisha trafiki halisi kwenye seva zilizo katika maeneo kadhaa, na kiasi hicho huhesabiwa kwenye kikomo chako cha kila mwezi cha bandwidth. Kwenye kiungo cha 1 Gbit/s, hatua kamili ya mtandao inaweza kuhamisha makumi ya gigabaiti, kwa hiyo tumia -r ikiwa kikomo chako ni kidogo na -i kwenye kiungo kinachotoza kulingana na matumizi.

Maana ya kila sehemu ya matokeo ya yabs

Sehemu ya diski huendesha fio kwa mchanganyiko wa kusoma na kuandika wa 50/50, kwa ukubwa wa block 4k, 64k, 512k na 1m. Huripoti IOPS (idadi ya shughuli za uingizaji/tokeo kwa sekunde) na bandwidth kwa kila ukubwa. Safu ya 4k ndiyo muhimu kwa database, mail server au mfumo wowote unaofanya uandishi mwingi wa data ndogo, kwa sababu IO nyingi za server ni ndogo na zimetawanyika. Safu ya 1m inafaa kwa nakala rudufu na video, ambapo unasogeza mfululizo mrefu wa bytes.

Sehemu ya mtandao huendesha iperf3 dhidi ya server za umma katika maeneo kadhaa, kwa pande zote mbili, kwa kutumia streams zinazotumika sambamba. Chukulia nambari ndogo hapa kama swali, si jibu, kwa sababu server za umma za iperf3 hushirikishwa na mara nyingi huwa zimeelemewa. Kwa hiyo, matokeo duni yanaweza kusababishwa na upande wa mbali.

Sehemu ya Geekbench hutoa alama ya core moja na alama ya cores nyingi. Alama ya core moja hukadiria kasi ya kukamilika kwa ombi moja, compile moja au query moja. Alama ya cores nyingi hukusaidia hasa kujua idadi halisi ya cores ulizopata.

Diski: endesha fio mwenyewe

fio (flexible IO tester) ni zana inayotumika chini ya sehemu ya diski ya yabs. Kuiendesha moja kwa moja hufanya chaguo za flags zianze kuwa na maana.

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

Jaribio la kusoma bila mpangilio la 4k, lenye kina cha foleni 32, kwenye mfumo wa faili unaoujali:

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

Mstari wa muhtasari wa kusoma kutoka kwenye matokeo unaonekana hivi.

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

Chini yake, fio huchapisha kizuizi cha clat percentiles. Percentile ya 99.00 ndiyo takwimu inayofaa kutajwa, kwa sababu inaonyesha muda ambao ombi moja lililosubiri kwa muda mrefu zaidi kati ya maombi mia moja lilisubiri. Wastani wa muda wa kusubiri huficha ucheleweshaji ambao mtumiaji huutambua.

• --direct=1 hufungua faili kwa O_DIRECT, kwa hiyo usomaji hupita cache ya kurasa ya kernel. Bila hiyo, kupita kwa pili kwenye faili la 2G kwenye mashine yenye 8G ya RAM hutolewa kutoka kwenye kumbukumbu, na fio huripoti IOPS kwa mamilioni. Nambari hiyo ni halisi, lakini ni kipimo cha kumbukumbu.
• --ioengine=libaio hutuma maombi yasiyosawazisha, ambayo huwezesha --iodepth=32 kuweka maombi 32 yakiwa yanaendelea. Kwa engine inayosawazisha kama psync, iodepth iliyo juu ya 1 haifanyi chochote, kwa hiyo unapima ombi moja kwa wakati.
• --time_based --runtime=60 huendesha jaribio kwa sekunde 60 zilizowekwa badala ya kiasi maalumu cha kazi, kwa hiyo diski yenye kasi na diski yenye polepole hupata muda sawa wa saa ya ukutani, na ulinganisho hubaki wa haki.
• --size=2G huweka ukubwa wa faili la jaribio. Liweke kubwa kuliko cache yoyote iliyo kwenye njia, na uhakikishe kwanza kuwa una nafasi ya kutosha ya bure.

Uandishi wa nasibu hutumia amri ileile pamoja na --rw=randwrite. Iendeshe kando, kisha ufute faili.

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

Kwa mchanganyiko unaokaribia zaidi trafiki halisi, tumia --rw=randrw --rwmixread=70. Aina ya hifadhi unayotumia hubadilisha matokeo haya zaidi kuliko flag yoyote, na tofauti hiyo imeelezwa katika tofauti kati ya hifadhi ya NVMe na SATA SSD kwenye VPS.

Wakati fio inaposimama kwa Unknown error -1

Direct IO haipatikani kwenye kila filesystem. overlay, ambayo ni filesystem ambayo Docker huipa container kwa chaguo-msingi, pamoja na filesystems kadhaa za mtandao, hazitumii O_DIRECT. Kwa hiyo, libaio hutuma ombi ambalo kernel haiwezi kukamilisha, na fio huacha kazi:

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

Kwanza endesha df -hT .. Ikiwa safu wima ya Type inaonyesha overlay, elekeza --filename kwenye njia iliyo kwenye hifadhi halisi, kama vile volume iliyowekwa kwa bind mount, au endesha fio kwenye host badala ya container. Ikiwa hifadhi halisi haipatikani, endesha jaribio la buffered synchronous. Hii angalau inathibitisha kuwa amri yenyewe ni sahihi.

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

Eleza kwa usahihi maana ya jaribio hilo. Baada ya mzunguko wa kwanza, faili la 256M hubaki kwenye page cache. Kwa hiyo, thamani ya IOPS inaeleza kasi ya RAM yako. Litumie kuthibitisha kuwa fio imesakinishwa na kwamba flags zimetafsiriwa kwa usahihi. Usilitaje kamwe kama matokeo ya diski.

Kwa nini dd si kipimo cha utendaji wa diski

dd huonekana katika mijadala mingi kuhusu VPS, na hujibu swali moja mahususi.

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

Hupima kasi ya uandishi mfululizo kwa thread moja na ombi moja linalosubiri kushughulikiwa. Ni ukaguzi unaofaa wa msingi. Haisemi chochote kuhusu IO ya nasibu, wala kuhusu kinachotokea maombi 32 yanapowasili kwa wakati mmoja. Ondoa oflag=direct, na kwa kiasi kikubwa hupima kasi ambayo kernel yako inapokea uandishi kwenye kumbukumbu. Ndiyo maana takwimu za dd zinazonukuliwa katika machapisho ya mijadala mara nyingi huwa zisizo za kawaida.

CPU: sysbench cpu

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

Kipimo muhimu ni events per second. Anza kwa kuendesha uzi mmoja. Hii ndiyo thamani inayoamua ombi moja la PHP linakamilika kwa kasi gani au kazi moja ya compilation inakamilika kwa kasi gani. Pia hutofautiana zaidi kati ya seva zenye bei sawa. Kisha endesha kwa kutumia kila uzi. Hii huonyesha ikiwa vCPU zako ni core tofauti au sehemu za core moja.

Elewa kinachopimwa hapa: sysbench cpu hutafuta nambari tasa mara kwa mara kwa kutumia hesabu za integer za biti 64. Haipimi kipimo cha memory bandwidth, vector units au cache kwa namna inayofanana na mzigo halisi wa kazi. Kwa hiyo inafaa kulinganisha seva mbili, lakini haifai kutabiri jinsi programu yako itakavyoendesha.

Ubuntu 24.04 inasambaza sysbench 1.0.20, ambapo jina la jaribio huwekwa kwanza. Ukicopy amri yenye --test=cpu kutoka chapisho la zamani, utapata WARNING: the --test option is deprecated. Alama kutoka sysbench 0.4 na sysbench 1.0 hazilinganishwi kabisa. Kwa hiyo usijilinganishe kamwe na nambari iliyochapishwa ambayo haitaji toleo lake.

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

Matokeo yanaonyeshwa kwa MiB/sec, na usomaji huwa wa kasi zaidi kuliko uandishi kwenye kila mashine. Weka --memory-block-size kuwa 1M, na iwe sawa kwenye kila host unayolinganisha. Kwa 1K, thamani hushuka sana kwa sababu unalipa gharama ya kila operesheni mara elfu zaidi. Hivyo, unapima gharama ya kitanzi badala ya kipimo data cha kumbukumbu. Hii ndiyo flag inayotofautiana mara nyingi zaidi katika alama za kumbukumbu zilizochapishwa.

Mtandao: iperf3

Njia sahihi ya kupima throughput ni kupima dhidi ya mashine ya pili unayoidhibiti, kwa sababu hapo unajua kinachofanywa na ncha zote mbili.

Kwenye ncha ya mbali:

iperf3 -s

Hii husikiliza kwenye TCP 5201. Fungua port hiyo kwa anwani unayotumia kufanya jaribio pekee, kisha uifunge ukimaliza. Kanuni za msingi za firewall ya ufw kwenye VPS inaeleza sintaksia hiyo.

Kutoka kwenye VPS inayofanyiwa jaribio:

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

Ya kwanza hupima upload kutoka kwenye mashine inayofanyiwa jaribio. -R hubadilisha mwelekeo, na hivyo hupima download. -P 8 hufungua streams nane zinazofanya kazi kwa wakati mmoja.

Tumia stream moja na toleo la parallel, kwa sababu yanajibu maswali tofauti. Muunganisho mmoja wa TCP unaweza kuhifadhi data ambayo haijathibitishwa kwa kiasi kinachoruhusiwa na window yake pekee. Kwa hiyo, kikomo chake ni takriban ukubwa wa window ukigawanywa kwa round trip time. Kwa latency ya 80 ms na window ya 4 MB, kikomo hicho ni takriban 400 Mbit/s, bila kujali kasi ya link iliyo chini yake. Kipimo cha stream moja hukuonyesha kile ambacho download moja itapata. Kipimo cha parallel hukuonyesha capacity ya link.

Fuatilia allowance yako ya bandwidth unapofanya jaribio hili. Sekunde 30 kwa 1 Gbit/s huhamisha takriban 3.75 GB, na utaendesha jaribio hilo mara kadhaa katika kila mwelekeo.

Takwimu za marejeo na jinsi ya kusoma zako

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

Juzuu ya NVMe ya ndani katika matokeo yaliyochapishwa kwa kawaida hupata takriban 180,000 IOPS za usomaji wa nasibu wa 4k. SSD ya ndani ya SATA hupata karibu 90,000. Hifadhi ya vizuizi iliyounganishwa kwenye mtandao, ambapo kila ombi hupitia mtandao kabla ya kufikia diski, hupata karibu 12,000, huku diski inayozunguka ikipata takriban 180, kwa sababu husogeza kichwa halisi kwa kila ombi la nasibu.

Hizi ni takwimu za kawaida zilizochapishwa kwa kila aina ya hifadhi, si vipimo kutoka kwa hosti moja. Zitumie kwa madhumuni haya pekee: kuthibitisha kuwa matokeo yako yako katika kiwango sahihi cha ukubwa. Ikiwa mpango unaouzwa kama NVMe unapata chini ya maelfu ya IOPS za 4k katika benchmark, kwanza thibitisha kuwa --direct=1 ilikuwa imewashwa. Ikiwa ilikuwa imewashwa, basi huenda hifadhi si ile iliyoelezwa kwenye ukurasa wa bidhaa, au unaishiriki na jirani mwenye shughuli nyingi sana.

Kwa nini uendeshaji mmoja si kipimo cha kulinganisha

Matokeo moja ni picha ya dakika moja kwenye mashine inayotumiwa pamoja. Yachukulie kama sampuli moja.

• Fanya kila jaribio angalau mara tano, katika saa tofauti na angalau siku mbili tofauti. Hifadhi thamani ya kati na mtawanyiko. Matokeo yaliyochapishwa bila mtawanyiko ni takwimu ya uuzaji.
• Rekodi muda wa steal pamoja na kila uendeshaji. Ondoa uendeshaji ambapo st ulikuwa juu, au angalau bainisha kwamba ulikuwa juu.
• Fanya jaribio la diski kwa muda wa vipindi viwili. Mipango mingi hutoa kiwango cha muda cha IOPS za mlipuko ambacho hujaza tena baada ya muda, kwa hiyo uendeshaji wa fio wa sekunde 60 hupima mlipuko, ilhali --runtime=600 hupima kiwango cha chini. Kiwango cha chini ndicho unachopata siku mbaya.
• Hakikisha hakuna kitu kingine kinachoendeshwa. unattended-upgrades kuanzisha muamala wa apt katikati ya jaribio la CPU kunakupunguzia pointi halisi, na ps -e -o comm= | grep -E 'apt|dpkg' kabla ya kila uendeshaji huchukua sekunde moja.
• Badilisha kigezo kimoja kwa wakati mmoja. Toleo tofauti za zana, ukubwa wa vitalu au idadi ya nyuzi hutoa namba zisizoweza kulinganishwa, bila kujali jinsi zinavyofanana.

Unapolinganisha watoa huduma wawili, wafanyie majaribio katika saa ileile ya siku ileile. Vinginevyo utakuwa umepima muda wa siku.

Pima mzigo wako mwenyewe mwishoni

Zana za majaribio ya sintetiki hupanga mashine. Mzigo wako mwenyewe pekee ndio unaokuambia ikiwa mashine inatosha. Pima muda wa kazi unayofanya kwa kweli.

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

Hiyo hubana megabaiti mia kadhaa, kwa hiyo hujaribu CPU na diski kwa pamoja, na matokeo hubadilika moja wapo inapobadilika. Onyo la Removing leading / from member names ni la kawaida. Bora zaidi, pima muda wa build yako mwenyewe, query yako yenye mwendo wa polepole zaidi, au uonyeshaji wa ukurasa wako mwenyewe. Build inayochukua dakika 4 kwenye host moja na dakika 7 kwenye host nyingine imeshamaliza swali hilo, bila kujali Geekbench ilifikiri nini. Hiki pia ndicho kipimo kinachokuambia wakati mashine yenye uwezo zaidi haifai tena gharama ya kulipia, jambo ambalo ni muhimu kulijua kabla ya kusoma gharama halisi ya VPS kwa mwezi au kuhamisha mzigo kwenye server maalumu.

FAQ

Kwa nini ninapata matokeo tofauti ya kipimo kila ninapokiendesha?

VPS hushiriki CPU halisi, hifadhi na mtandao na wapangaji wengine. Kwa hiyo, matokeo yako yanategemea wanachofanya wakati huo. Endesha vmstat 1 wakati wa kipimo na usome safu ya st: muda wa steal unaoendelea kuzidi 5 unaonyesha kuwa mwenyeji alikuwa na shughuli nyingi, na alama yako ya CPU ni ndogo kwa sababu zilizo nje ya mashine yako. Suluhisho ni kutumia mbinu thabiti badala ya kufanya tuning. Endesha kila kipimo mara tano au zaidi katika saa tofauti. Kisha ripoti mediani pamoja na mtawanyiko wa matokeo.

Kwa nini fio huripoti mamilioni ya IOPS?

Karibu kila mara ni kwa sababu --direct=1 haipo. Bila hiyo, fio husoma kupitia page cache ya kernel. Kwa hiyo, baada ya mzunguko wa kwanza, faili ya kipimo ya 2G husomwa kutoka RAM, na umepima bandwidth ya kumbukumbu. Ongeza --direct=1 na uweke faili ya kipimo kubwa kuliko cache yoyote iliyo kwenye njia hiyo. Ikiwa --direct=1 itashindwa kwa err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1, endesha df -hT .: Type ya overlay haitumii O_DIRECT, kwa hiyo elekeza kipimo kwenye hifadhi halisi.

Je, yabs.sh inatosha peke yake?

Kwa ukaguzi wa awali, ndiyo. Huendesha fio kwa ukubwa wa block nne, iperf3 katika mielekeo yote miwili na Geekbench. Pia huchapisha muhtasari mmoja ambao watu wengine wanaweza kuusoma. Haitoshi unapohitaji kujua kwa nini namba fulani imepatikana, kwa sababu huwezi kubadilisha flags zake kwa kila kipimo. Matokeo ya yabs yakionekana kuwa si sahihi, yarudie moja kwa moja kwa fio au sysbench. Badilisha flag moja kwa wakati mmoja.

Ni namba ipi moja inayotabiri jinsi programu yangu itakavyohisi?

Kasi ya CPU ya core moja na latency ya usomaji wa bila mpangilio ya 4k, kwa mpangilio huo, ndizo muhimu kwa mizigo mingi ya kazi ya wavuti na hifadhidata. Takwimu za throughput huonekana kuvutia, lakini mara chache huamua utendaji, kwa sababu ombi la kawaida huwa dogo. Nukuu percentile ya 99 kutoka block ya clat percentiles ya fio badala ya wastani. Ombi moja kati ya mia linapochelewa ndilo mtumiaji hulitambua.

Je, ninahitaji kusakinisha kitu kabla ya kufanya kipimo?

fio, sysbench na iperf3 zote zinapatikana katika hazina za Ubuntu na Debian: sudo apt install -y fio sysbench iperf3. yabs.sh inahitaji curl pekee, kwa sababu hupakua binary tuli kwa kila kitu kinachokosekana. Futa kila faili ya kipimo unapomaliza. Faili ya fio ya 2G iliyoachwa kwenye diski ya 20G inaweza kusababisha arifa ya diski kujaa wiki kadhaa baadaye.