Jinsi ya kupima utendaji wa VPS kwa usahihi

Maana ya kufanya benchmarking ya VPS

Ili kufanya benchmarking ya VPS, unapima mambo manne: kasi ya core moja ya CPU, kiasi cha bandwidth ya kumbukumbu (memory) iliyo kwenye mashine, idadi ya operesheni ndogo za diski (random disk operations) zinazotekelezwa kwa sekunde, na kiasi cha data kinachopita kwenye link ya mtandao. Uendeshaji mmoja wa yabs.sh hukupa vipimo vyote vinne ndani ya takriban dakika 10. Kusoma matokeo ndiyo sehemu ngumu, kwa sababu VPS (virtual private server) hushiriki vifaa vya kimwili (physical hardware) na watumiaji wengine, hivyo mashine hiyo hiyo inaweza kutoa namba moja saa 03:00 na namba tofauti kabisa saa 20:00.

Mpango hapa ni kuendesha yabs.sh ili kupata picha ya haraka, kisha kuendesha zana zilizomo ndani yake kwa mikono. Kuziendesha mwenyewe ndiko kunakokuwezesha kubadili flag moja, kuona namba ikibadilika, na kujifunza kile ambacho namba hiyo ilikuwa inapima hasa. Fanya hivi baada ya mashine kusanidiwa, si kabla. Hatua zilizo katika dakika kumi za kwanza kwenye VPS mpya lazima zifanyike kwanza, kwa sababu seva inayotekeleza raundi yake ya kwanza ya updates hutoa matokeo mabaya ya benchmarking kwa sababu zisizohusiana na hardware.

Ichunguze mashine kabla ya kuipima

Nusu ya kila benchmark mbaya 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 virtualisation kamili, kwa hivyo unaendesha kernel yako mwenyewe. systemd-detect-virt ikichapisha lxc au openvz inamaanisha virtualisation ya container badala yake: unashiriki kernel ya host, na mipaka yako ya CPU na memory ni mipangilio ya cgroup (control group) badala ya maunzi ya virtual. Kwenye mfumo wa cgroup v2 unaweza kusoma kikomo cha CPU moja kwa moja.

cat /sys/fs/cgroup/cpu.max

max 100000 inamaanisha hakuna quota. 200000 100000 inamaanisha unaweza kutumia microsecond 200000 za CPU katika kila kipindi cha microsecond 100000, ambayo ni sawa na quota ya cores mbili. Mpango uliotangazwa kama 4 vCPU wenye quota ya cores mbili hautawahi kupata alama kama cores nne, na hakuna zana ya benchmark inayochapisha mstari kukuambia kwa nini.

df -hT / ni muhimu kwa sababu tofauti: safu ya Type. Ikiwa inasoma overlay uko ndani ya container, na jaribio la disk hapa chini linahitaji mabadiliko. Iandike sasa.

Fuatilia steal time wakati wote

Steal time ni sehemu ya muda ambayo CPU yako ya mtandaoni ilikuwa tayari kufanya kazi lakini hypervisor ikatoa core ya kimwili kwa mtu mwingine. Hii ndiyo ishara muhimu zaidi kuonyesha kuwa matokeo yanatokana na majirani zako badala ya maunzi yako.

vmstat 1 10

Soma safu ya st upande wa kulia. Thamani ya 0 au 1 thabiti ni ya kawaida. Thamani endelevu zilizo juu ya 5 inamaanisha kuwa mwenyeji (host) amezidiwa uwezo kwa wakati huo, kwa hivyo kila nambari ya CPU unayorekodi katika kipindi hicho ni ya chini bila kosa la mashine yako. top inaonyesha takwimu sawa na %st kwenye mstari wa CPU. Endesha vmstat 1 katika kikao cha pili cha SSH wakati unafanya benchmark, na uandike takwimu ya steal kando ya kila matokeo.

Anza na yabs.sh

yabs.sh (Yet Another Bench Script) ni hati ya shell inayopakua binaries za fio, iperf3 na Geekbench, kuziendesha, na kutoa muhtasari mmoja. Hii ndiyo lugha ya kawaida katika mijadala ya benchmark ya VPS, kwa hivyo matokeo ya yabs ndiyo njia ya haraka zaidi ya kulinganisha utendaji na mtu mwingine.

Njia ya mstari mmoja ya mradi huu ni hii.

curl -sL yabs.sh | bash

Hii hupitisha chochote kinachotolewa na URL hiyo moja kwa moja kwenye shell. 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

Flags huwekwa baada ya -s -- unapopitisha (pipe), au moja kwa moja baada ya jina la faili unapoendesha nakala ya ndani. Zile muhimu ni: -f huruka jaribio la diski, -i huruka jaribio la mtandao, -g huruka Geekbench, -r hupunguza maeneo ya iperf3 hadi mawili, -j huchapisha matokeo kama JSON, na -w results.json huandika JSON hiyo kwenye faili.

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

Mambo mawili ya kuzingatia kabla ya kuanza. Geekbench hupakia matokeo yako na kuchapisha URL ya public browser.geekbench.com, kwa hivyo mtu yeyote aliye na kiungo hicho anaweza kusoma modeli ya CPU yako na alama zako. -g huruka jaribio hilo kabisa. Pili, hatua ya iperf3 husafirisha trafiki halisi kwenda kwenye seva katika maeneo mbalimbali, na hiyo huhesabiwa dhidi ya kiasi chako cha bandwidth cha kila mwezi. Kwenye link ya 1 Gbit/s, hatua kamili ya mtandao inaweza kutumia makumi ya gigabytes, kwa hivyo tumia -r ukiwa na kiasi kidogo cha data na -i kwenye link yenye kipimo cha matumizi (metered link).

Maana ya kila sehemu ya matokeo ya yabs

Sehemu ya disk huendesha fio kwa mchanganyiko wa 50/50 wa kusoma na kuandika katika ukubwa wa block nne: 4k, 64k, 512k na 1m. Inatoa taarifa za IOPS (input/output operations per second) na bandwidth kwa kila moja. Safu ya 4k ndiyo ya kuzingatia kwa database, seva ya barua pepe, au chochote kinachofanya uandikaji mwingi mdogo, kwa sababu IO nyingi za seva ni ndogo na zimetawanyika. Safu ya 1m ni ya backups na video, ambapo unasafirisha data nyingi mfululizo.

Sehemu ya network huendesha iperf3 dhidi ya seva za umma katika maeneo kadhaa, kwa pande zote mbili, ikitumia parallel streams. Hesabu namba ya chini hapa kama swali badala ya jibu, kwa sababu seva za umma za iperf3 zinashirikiwa na mara nyingi huwa zimejaa, hivyo matokeo mabaya yanaweza kusababishwa na upande wa pili.

Sehemu ya Geekbench inatoa alama ya single core na alama ya multi core. Single core inatabiri jinsi ombi moja, compile moja au query moja inavyokamilika haraka. Multi core inakuambia hasa una cores ngapi ulizonazo.

Disk: endesha fio mwenyewe

fio (flexible IO tester) ndicho zana inayotumika nyuma ya sehemu ya disk ya yabs, na kuitumia moja kwa moja ndipo unapoanza kuelewa maana ya flags zake.

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

Jaribio la 4k random read kwenye queue depth ya 32, kwenye filesystem unayoiangalia:

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 unaopaswa kuusoma kutoka kwenye matokeo unaonekana hivi.

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

Chini yake, fio huchapisha block ya clat percentiles. Asilimia 99.00 (99.00th percentile) ndiyo takwimu inayofaa kunukuliwa, kwa sababu inaonyesha muda ambao ombi moja kati ya mia moja lilisubiri. Wastani wa latency huficha vipindi vya kukwama (stalls) ambavyo mtumiaji huviona.

• --direct=1 hufungua faili kwa kutumia O_DIRECT, hivyo usomaji hupita pembeni ya kernel page cache. Bila hii, jaribio la pili kwenye faili ya 2G kwenye mashine yenye 8G ya RAM litahudumiwa kutoka kwenye kumbukumbu na fio itaripoti IOPS katika mamilioni. Namba hiyo ni ya kweli, lakini ni namba ya kumbukumbu (memory).
• --ioengine=libaio hutuma maombi kwa njia ya asynchronous, jambo linaloruhusu --iodepth=32 kuweka maombi 32 kwa wakati mmoja. Kwa kutumia engine ya synchronous kama psync, iodepth inayozidi 1 haifanyi kazi yoyote, hivyo utapima ombi moja kwa wakati mmoja.
• --time_based --runtime=60 huendeshwa kwa sekunde 60 kamili badala ya kiasi cha kazi kilichopangwa, hivyo disk ya haraka na disk ya polepole hupata muda sawa wa kupima na kulinganisha kunakuwa kwa haki.
• --size=2G huweka ukubwa wa faili ya jaribio. Iweke kubwa kuliko cache yoyote iliyopo kwenye njia, na hakikisha una nafasi ya kutosha kwanza.

Random write ni amri ileile yenye --rw=randwrite. Iendeshe kivyake, kisha ufute faili hiyo.

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 traffic ya kweli, tumia --rw=randrw --rwmixread=70. Aina ya hifadhi (storage) uliyopo hubadilisha matokeo haya zaidi ya flag yoyote, na mgawanyo huo umeelezwa katika tofauti kati ya hifadhi ya NVMe na SATA SSD kwenye VPS.

Wakati fio inaposimama na Unknown error -1

Direct IO haipatikani kwenye kila mfumo wa faili (filesystem). overlay, mfumo wa faili ambao Docker huupa kontena kwa chaguo-msingi, na mifumo mingi ya faili ya mtandao haiauni O_DIRECT, kwa hivyo libaio hutuma ombi ambalo kernel haiwezi kulikamilisha na fio hukata tamaa:

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

Tekeleza df -hT . kwanza. Ikiwa safu ya Type inasema overlay, elekeza --filename kwenye njia (path) iliyo kwenye hifadhi halisi kama vile bind mounted volume, au tekeleza fio kwenye host badala ya ndani ya kontena. Ikiwa hifadhi halisi haipatikani, utekelezaji wa buffered synchronous angalau unathibitisha 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

Kuwa mkweli kuhusu utekelezaji huo. Baada ya mzunguko wa kwanza, faili ya 256M hukaa kwenye page cache, kwa hivyo takwimu ya IOPS inaelezea RAM yako. Itumie kuthibitisha kuwa fio imesakinishwa na flag zinasomeka vizuri. Usiitumie kamwe kama matokeo ya diski.

Kwa nini dd si kipimo sahihi cha utendaji wa diski

dd hutumiwa mara nyingi katika mijadala ya VPS, na inajibu swali moja dogo tu.

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

Amri hiyo hupima kasi ya uandishi wa mfululizo (sequential write throughput) kwa kutumia thread moja na ombi moja linalotekelezwa kwa wakati mmoja. Ni njia nzuri ya kufanya ukaguzi wa haraka wa mfumo. Haielezi chochote kuhusu utendaji wa random IO, wala haionyeshi nini kitatokea wakati maombi 32 yanapofika kwa wakati mmoja. Ukiondoa oflag=direct, amri hiyo hupima zaidi kasi ya kernel yako katika kupokea data kwenye kumbukumbu (memory), ndiyo maana takwimu za dd zinazotajwa kwenye majukwaa ya mtandaoni mara nyingi huwa hazina mantiki.

CPU: sysbench cpu

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

Namba ya kuzingatia ni events per second. Endesha kwanza kwa thread moja. Hii ndiyo namba inayotathmini kasi ya kukamilika kwa ombi moja la PHP au kazi moja ya compile, na ndiyo inayotofautiana zaidi kati ya seva zenye bei sawa. Kisha endesha kwa kutumia thread zote, jambo linaloonyesha kama vCPU zako ni cores tofauti au vipande vya core moja.

Elewa vyema kile ambacho kipimo hiki kinachunguza: sysbench cpu hutafuta namba tasa mara kwa mara kwa kutumia hesabu za 64 bit integer. Kipimo hiki hakijaribu bandwidth ya kumbukumbu, vector units, au cache kwa namna yoyote inayofanana na mzigo halisi wa kazi, kwa hivyo ni kizuri kwa kulinganisha seva mbili lakini ni kibaya kwa kutabiri jinsi programu yako itakavyofanya kazi.

Ubuntu 24.04 inakuja na sysbench 1.0.20, ambapo jina la jaribio huwekwa mwanzoni. Ukinakili amri yenye --test=cpu kutoka kwenye chapisho la zamani, utapata WARNING: the --test option is deprecated. Alama kutoka sysbench 0.4 na sysbench 1.0 haziwezi kulinganishwa hata kidogo, kwa hivyo usijipime kamwe dhidi ya namba 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 huonyeshwa kwa MiB/sec, na kasi ya kusoma huwa kubwa kuliko kasi ya kuandika kwenye kila mashine. Weka --memory-block-size katika 1M, na uihifadhi ikiwa sawa kwenye kila host unayolinganisha. Katika 1K namba huporomoka, kwa sababu unalipia gharama ya ziada ya kila operesheni mara elfu zaidi, hivyo unaishia kupima gharama ya loop badala ya bandwidth ya kumbukumbu. Hii ndiyo flag inayokosewa mara nyingi zaidi katika matokeo ya kumbukumbu yaliyochapishwa.

Mtandao: iperf3

Njia sahihi ya kupima kasi ya mtandao (throughput) ni dhidi ya mashine nyingine unayoimiliki, kwa sababu hapo utajua kinachoendelea pande zote mbili.

Upande wa pili (far end):

iperf3 -s

Hii inasikiliza kwenye TCP 5201. Fungua port hiyo kwa ajili ya anwani unayotumia kupima pekee, na uifunge ukimaliza. Kanuni za msingi za firewall ya ufw kwenye VPS inaelezea sintaksia hiyo.

Kutoka kwenye VPS inayopimwa:

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

Amri ya kwanza inapima kasi ya kupakia (upload) kutoka kwenye mashine inayopimwa. -R inageuza mwelekeo, jambo linalopima kasi ya kupakua (download). -P 8 inafungua mitiririko (streams) minane kwa wakati mmoja.

Endesha mtiririko mmoja na ule wa mitiririko mingi, kwa sababu yanajibu maswali tofauti. Muunganisho mmoja wa TCP unaweza kubeba data isiyothibitishwa kulingana na ukubwa wa window yake, hivyo ukomo wake ni takriban ukubwa wa window hiyo ukigawanywa kwa muda wa round trip. Kwa latency ya 80 ms na window ya 4 MB, ukomo huo ni takriban 400 Mbit/s, hata kama link ya msingi ni ya kasi zaidi. Takwimu ya mtiririko mmoja inakuonyesha kasi utakayopata kwenye download moja. Takwimu ya mitiririko mingi inakuonyesha uwezo kamili wa link hiyo.

Fuatilia kiasi cha bandwidth ulichotengewa wakati unafanya hivi. Sekunde thelathini kwa kasi ya 1 Gbit/s huhamisha takriban 3.75 GB, na utaiendesha mara kadhaa kwa kila mwelekeo.

Takwimu za marejeleo, 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"
  }
]

Volume ya ndani ya NVMe katika matokeo yaliyochapishwa kwa kawaida hufikia karibu 180,000 IOPS za kusoma kwa nasibu (random read) za 4k. SSD ya ndani ya SATA hufikia karibu 90,000. Hifadhi ya block iliyounganishwa kwenye mtandao (network attached block storage), ambapo kila ombi huvuka mtandao kabla ya kufika kwenye diski, huwa karibu na 12,000, na diski inayozunguka (spinning disk) hufikia takriban 180, kwa sababu husogeza kichwa cha kusomea (physical head) kwa kila ombi la nasibu.

Hizi ni takwimu za kawaida zilizochapishwa kwa kila darasa la hifadhi, si vipimo kutoka kwa seva moja. Zitumie kwa kusudi moja: kuhakikisha kuwa matokeo yako yapo katika kiwango sahihi cha ukubwa. Ikiwa mpango unaouzwa kama NVMe unatoa matokeo ya benchmark ya maelfu machache ya IOPS za 4k, kwanza thibitisha kuwa --direct=1 ilikuwa imewashwa. Ikiwa ilikuwa imewashwa, basi ama hifadhi hiyo si ile inayoelezwa kwenye ukurasa wa bidhaa, au unashiriki rasilimali hizo na mtumiaji mwingine mwenye shughuli nyingi.

Kwa nini jaribio moja si kipimo cha utendaji (benchmark)

Matokeo ya mara moja ni picha ya dakika moja kwenye mashine inayoshirikiwa. Ichukulie kama sampuli moja tu.

• Fanya kila jaribio angalau mara tano, kwa nyakati tofauti za siku na kwa angalau siku mbili tofauti. Hifadhi thamani ya wastani (median) na mtawanyiko wa matokeo. Matokeo yaliyochapishwa bila kuonyesha mtawanyiko ni takwimu za masoko tu.
• Rekodi steal time kando ya kila jaribio. Ondoa majaribio ambapo st ilikuwa juu, au angalau iweke kama kumbukumbu.
• Fanya jaribio la diski kwa muda wa aina mbili. Mipango mingi hutoa kiasi cha burst IOPS kinachojijaza baada ya muda, kwa hivyo jaribio la fio la sekunde 60 hupima uwezo wa burst, wakati --runtime=600 hupima uwezo wa chini kabisa (floor). Uwezo wa chini ndio unaopata siku mambo yanapokuwa mabaya.
• Hakikisha hakuna kitu kingine kinachoendelea. unattended-upgrades kuanzisha transaction ya apt katikati ya jaribio la CPU hupunguza alama zako, na ps -e -o comm= | grep -E 'apt|dpkg' kabla ya kila jaribio huchukua sekunde.
• Badilisha kigezo kimoja kwa wakati mmoja. Matoleo tofauti ya zana, ukubwa wa block, au idadi ya thread huzalisha namba ambazo haziwezi kulinganishwa, hata kama zinaonekana kufanana.

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

Pima mzigo wako wa kazi mwishoni

Zana za usanifu (synthetic tools) hupanga mashine kulingana na viwango fulani. Mzigo wako wa kazi pekee ndio unaoweza kukuambia kama mashine inatosha. Pima muda wa kitu unachokifanya kihalisi.

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

Hiyo inafanya compression ya megabytes mia chache, kwa hivyo inatumia CPU na diski kwa pamoja na hubadilika wakati mojawapo ikibadilika. Onyo la Removing leading / from member names ni la kawaida. Ni bora zaidi kupima muda wa build yako mwenyewe, query yako ya polepole zaidi, au uonyeshaji wa ukurasa (page render) wako. Build inayochukua dakika 4 kwenye host moja na 7 kwenye nyingine imetatua swali hilo, bila kujali Geekbench ilifikiria nini. Hii pia ndiyo kipimo kinachokuambia wakati mashine kubwa zaidi inapoacha kuwa na thamani ya kulipiwa, jambo ambalo ni muhimu kujua kabla ya kusoma gharama halisi ya VPS kwa mwezi au kuhamisha mzigo wa kazi kwenye seva iliyojitolea (dedicated server).

FAQ

Kwa nini ninapata matokeo tofauti ya benchmark kila ninapoiendesha?

VPS inashiriki CPU, hifadhi, na mtandao wa kimwili na watumiaji wengine, kwa hivyo matokeo yako yanategemea kile wanachokifanya wakati huo. Endesha vmstat 1 wakati wa jaribio na usome safu ya st: steal time endelevu inayozidi 5 inamaanisha kuwa host ilikuwa na shughuli nyingi, na alama yako ya CPU ni ndogo kwa sababu zilizo nje ya mashine yako. Jibu ni kutumia mbinu badala ya kurekebisha mipangilio. Endesha kila jaribio mara tano au zaidi kwa nyakati tofauti, kisha ripoti wastani (median) pamoja na tofauti zilizojitokeza.

Kwa nini fio inaripoti mamilioni ya IOPS?

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

Je, yabs.sh inatosha yenyewe?

Kwa mtazamo wa kwanza, ndiyo. Inaendesha fio kwa ukubwa wa block nne, iperf3 katika pande zote mbili, na Geekbench, kisha inachapisha muhtasari mmoja ambao watu wengine wanaweza kuusoma. Inakoma kutosha unapotaka kujua kwa nini namba fulani ni ile ilivyo, kwa sababu huwezi kubadilisha flag zake kwa kila jaribio. Matokeo ya yabs yakionekana kuwa si sahihi, yanakili kwa kutumia fio au sysbench moja kwa moja na ubadilishe flag moja kwa wakati mmoja.

Ni namba gani moja inayotabiri jinsi programu yangu itakavyofanya kazi?

Kasi ya CPU ya core moja na latency ya 4k random read, kwa mpangilio huo, kwa mizigo mingi ya kazi ya wavuti na database. Takwimu za throughput zinaonekana kuvutia lakini mara chache huamua chochote, kwa sababu ombi la kawaida ni dogo. Taja 99th percentile kutoka kwenye block ya clat percentiles ya fio badala ya wastani, kwa sababu ombi moja la polepole kati ya mia moja ndilo mtumiaji analoliona.

Je, ninahitaji kusakinisha kitu chochote kabla ya kufanya benchmarking?

fio, sysbench, na iperf3 zote zipo kwenye hazina za Ubuntu na Debian: sudo apt install -y fio sysbench iperf3. yabs.sh inahitaji curl pekee, kwa sababu inapakua binaries tuli kwa chochote kinachokosekana. Futa kila faili ya jaribio unapomaliza, kwa sababu faili ya 2G ya fio iliyoachwa kwenye diski ya 20G inaweza kusababisha tahadhari ya diski kujaa kwa mtu mwingine wiki kadhaa baadaye.