VPS benchmark योग्य प्रकारे कसा करावा?

VPS चे बेंचमार्क करणे म्हणजे काय

VPS चे बेंचमार्क करण्यासाठी चार गोष्टी मोजल्या जातात: एक CPU core किती वेगाने कार्य करतो, मशीनची memory bandwidth किती आहे, storage प्रत्येक सेकंदाला किती लहान random disk operations पूर्ण करते, आणि network link किती throughput देते. yabs.sh ची एक run ही चारही मोजमापे सुमारे दहा मिनिटांत देते. निकाल समजून घेणे अधिक कठीण असते, कारण VPS इतर tenants सोबत physical hardware सामायिक करतो. त्यामुळे त्याच मशीनवर 03:00 वाजता एक आकडा आणि 20:00 वाजता पूर्णपणे वेगळा आकडा दिसू शकतो.

येथे प्रथम झटपट चित्र मिळवण्यासाठी yabs.sh चालवायचे आहे. त्यानंतर त्यामागील tools स्वतः हाताने चालवायची आहेत. हे स्वतः केल्यामुळे एक flag बदलून आकडा कसा बदलतो ते पाहता येते आणि त्या आकड्याने प्रत्यक्षात काय मोजले ते समजते. हे मशीन setup झाल्यानंतर करा, त्यापूर्वी नाही. नवीन VPS वरील पहिल्या दहा मिनिटांतील पायऱ्या आधी पूर्ण करा, कारण मशीनवर updates ची पहिली फेरी अद्याप लागू होत असल्यास hardware शी संबंध नसलेल्या कारणांमुळे benchmark चे निकाल खराब येतात.

मोजमाप करण्यापूर्वी मशीन तपासा

प्रत्येक खराब बेंचमार्कपैकी निम्म्या समस्या लेखकाला मशीनची माहिती नसल्यामुळे निर्माण होतात.

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

Hypervisor vendor: KVM म्हणजे पूर्ण वर्च्युअलायझेशन. त्यामुळे तुमचा स्वतःचा कर्नल चालतो. systemd-detect-virt मध्ये lxc किंवा openvz छापले असल्यास, ते कंटेनर वर्च्युअलायझेशन असते. यात तुम्ही होस्ट कर्नल सामायिक करता. तुमच्या CPU आणि मेमरीवरील मर्यादा वर्च्युअल हार्डवेअरऐवजी cgroup (control group) सेटिंग्ज असतात. cgroup v2 प्रणालीवर CPU मर्यादा थेट वाचता येते.

cat /sys/fs/cgroup/cpu.max

max 100000 म्हणजे कोणताही कोटा नाही. 200000 100000 म्हणजे प्रत्येक 100000 मायक्रोसेकंदांच्या कालावधीत तुम्ही CPU चे 200000 मायक्रोसेकंद वापरू शकता. हा दोन कोअरच्या कोटाइतका आहे. दोन कोअरचा कोटा असलेला 4 vCPU म्हणून जाहिरात केलेला प्लॅन चार कोअरप्रमाणे कधीही गुण मिळवणार नाही. याचे कारण सांगणारी ओळ कोणतेही बेंचमार्क साधन छापत नाही.

df -hT / दुसऱ्या कारणासाठी महत्त्वाचे आहे: Type स्तंभ. त्यात overlay वाचले असल्यास, तुम्ही कंटेनरमध्ये आहात. त्यामुळे खालील डिस्क चाचणीत बदल करावा लागेल. हे आत्ताच नोंदवा.

सतत steal time निरीक्षण करा

steal time म्हणजे तुमचा virtual CPU चालण्यासाठी तयार असताना hypervisor ने physical core दुसऱ्याला दिलेल्या वेळेचा हिस्सा. एखादा निकाल hardware मुळे नसून शेजारील वापरकर्त्यांमुळे आहे का, हे दर्शवणारा हा सर्वात उपयुक्त एकल संकेत आहे.

vmstat 1 10

उजवीकडील st स्तंभ वाचा. सातत्याने 0 किंवा 1 असणे सामान्य आहे. 5 पेक्षा जास्त मूल्ये सतत दिसत असल्यास, त्या क्षणी host वर क्षमतेपेक्षा जास्त भार आहे. त्यामुळे त्या कालावधीत नोंदवलेली प्रत्येक CPU संख्या तुमच्या मशीनच्या चुकीमुळे नव्हे, तर या परिस्थितीमुळे कमी असेल. top मध्ये CPU ओळीवरील %st प्रमाणेच आकडा दिसतो. benchmark चालू असताना दुसऱ्या SSH session मध्ये vmstat 1 सुरू ठेवा आणि प्रत्येक निकालाच्या शेजारी steal आकडा लिहा.

yabs.sh ने सुरुवात करा

yabs.sh (Yet Another Bench Script) ही shell script आहे. ती static fio, iperf3 आणि Geekbench binaries डाउनलोड करून चालवते आणि एक सारांश छापते. VPS benchmark चर्चांमध्ये ही सर्वसाधारण भाषा आहे. त्यामुळे दुसऱ्या व्यक्तीच्या निकालांशी तुलना करण्याचा yabs output हा सर्वात जलद मार्ग आहे.

प्रकल्पाने दिलेला one-line प्रकार असा आहे.

curl -sL yabs.sh | bash

यामुळे URL सध्या जे उपलब्ध करून देते ते थेट shell कडे पाठवले जाते. ते आधी डाउनलोड करा, वाचा आणि त्यानंतर चालवा.

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

Pipe वापरताना flags -s -- नंतर द्या. Local copy चालवताना ते filename नंतर थेट द्या. उपयुक्त flags पुढीलप्रमाणे आहेत: -f disk test वगळतो, -i network test वगळतो, -g Geekbench वगळतो, -r iperf3 locations ची संख्या दोनपर्यंत कमी करतो, -j निकाल JSON म्हणून छापतो आणि -w results.json ते JSON file मध्ये लिहितो.

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

पहिल्यांदा चालवण्यापूर्वी दोन गोष्टी लक्षात ठेवा. Geekbench तुमचा निकाल upload करतो आणि सार्वजनिक browser.geekbench.com URL छापतो. त्यामुळे ती link असलेली कोणतीही व्यक्ती तुमचा CPU model आणि scores पाहू शकते. हा test पूर्णपणे वगळण्यासाठी -g वापरा. दुसरे म्हणजे, iperf3 stage अनेक regions मधील servers कडे प्रत्यक्ष network traffic पाठवतो. हा traffic तुमच्या monthly bandwidth allowance मधून वजा होतो. 1 Gbit/s link वर पूर्ण network stage मध्ये tens of gigabytes traffic जाऊ शकतो. त्यामुळे कमी allowance असल्यास -r वापरा आणि metered link असल्यास -i वापरा.

yabs आउटपुटमधील प्रत्येक भागाचा अर्थ

डिस्क विभाग 4k, 64k, 512k आणि 1m या चार ब्लॉक आकारांसह 50/50 read आणि write मिश्रण वापरून fio चालवतो. प्रत्येक ब्लॉक आकारासाठी तो IOPS (input/output operations per second) आणि bandwidth नोंदवतो. डेटाबेस, mail server किंवा अनेक लहान write करणाऱ्या कोणत्याही प्रणालीसाठी 4k ही ओळ महत्त्वाची आहे, कारण बहुतेक server IO लहान आणि विखुरलेले असते. 1m ही ओळ backups आणि video साठी महत्त्वाची आहे, कारण त्यात bytes चे मोठे सलग संच हलवले जातात.

नेटवर्क विभाग अनेक regions मधील public servers विरुद्ध, दोन्ही दिशांनी आणि parallel streams वापरून iperf3 चालवतो. येथे कमी आकड्याकडे अंतिम निष्कर्ष म्हणून नव्हे, तर तपासण्यासारखा संकेत म्हणून पाहा. Public iperf3 servers सामायिक असतात आणि त्यांच्यावर अनेकदा जास्त भार असतो. त्यामुळे खराब निकाल remote end मुळे मिळालेला असू शकतो.

Geekbench विभाग single core score आणि multi core score देतो. Single core score मुळे एक request, एक compile किंवा एक query किती वेगाने पूर्ण होईल याचा अंदाज येतो. Multi core score वरून तुम्हाला प्रत्यक्षात किती cores मिळाले हे प्रामुख्याने समजते.

Disk: fio स्वतः चालवा

fio (flexible IO tester) हे yabs च्या disk विभागामागील साधन आहे. ते थेट चालवल्यावर flags चा प्रत्यक्ष अर्थ स्पष्ट होतो.

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

तुम्हाला महत्त्वाच्या असलेल्या filesystem वर, queue depth 32 सह 4k random read चाचणी:

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

आउटपुटमधील वाचायची summary line अशी दिसते.

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

याखाली fio एक clat percentiles block दाखवते. 99.00th percentile हा नमूद करण्यास योग्य आकडा आहे, कारण 100 पैकी सर्वात धीम्या 1 request ला किती वेळ प्रतीक्षा करावी लागली हे तो दाखवतो. Average latency मुळे वापरकर्त्याला जाणवणारे stalls लपतात.

• --direct=1 मुळे file O_DIRECT सह उघडली जाते. त्यामुळे reads kernel page cache ला वगळतात. हे नसल्यास, 8G RAM असलेल्या machine वर 2G file वरची दुसरी pass memory मधून पूर्ण होते आणि fio लाखोंमध्ये IOPS दाखवते. तो आकडा खरा आहे, पण तो memory चा आकडा आहे.
• --ioengine=libaio asynchronous requests submit करते. त्यामुळे --iodepth=32 32 requests in flight ठेवू शकते. psync सारख्या synchronous engine सह iodepth 1 पेक्षा जास्त ठेवून काहीही साध्य होत नाही. त्यामुळे तुम्ही एका वेळी एकच request मोजता.
• --time_based --runtime=60 ठरावीक कामाच्या प्रमाणाऐवजी निश्चित 60 seconds चालते. त्यामुळे fast disk आणि slow disk साठी wall clock time समान राहतो आणि तुलना निष्पक्ष राहते.
• --size=2G test file चा size सेट करते. तो path मधील कोणत्याही cache पेक्षा मोठा ठेवा आणि आधी free space उपलब्ध आहे का ते तपासा.

Random write साठी --rw=randwrite वापरून हीच command चालवा. ती स्वतंत्रपणे चालवल्यानंतर file delete करा.

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

प्रत्यक्ष network traffic शी अधिक जवळचा mix वापरण्यासाठी --rw=randrw --rwmixread=70 वापरा. तुम्ही वापरत असलेल्या storage च्या class मुळे हे results कोणत्याही flag पेक्षा अधिक बदलतात. हा फरक VPS वरील NVMe आणि SATA SSD storage मधील फरक येथे स्पष्ट केला आहे.

fio Unknown error -1 ने थांबल्यास

Direct IO प्रत्येक filesystem वर उपलब्ध नसते. overlay, म्हणजे Docker कंटेनरला डीफॉल्टने देत असलेले filesystem, तसेच अनेक network filesystems, O_DIRECT ला समर्थन देत नाहीत. त्यामुळे libaio अशी विनंती सादर करते जी kernel पूर्ण करू शकत नाही आणि 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

प्रथम df -hT . चालवा. Type स्तंभात overlay असल्यास, --filename ला वास्तविक storage वरील path कडे निर्देशित करा, उदाहरणार्थ bind mounted volume वरील path. किंवा कंटेनरऐवजी host वर fio चालवा. वास्तविक storage उपलब्ध नसल्यास, buffered synchronous run किमान command स्वतः योग्य आहे हे सिद्ध करते.

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

त्या run चे स्वरूप स्पष्टपणे लक्षात घ्या. पहिल्या pass नंतर 256M फाइल page cache मध्ये राहते. त्यामुळे IOPS आकडा तुमच्या RAM चे कार्यप्रदर्शन दर्शवतो. fio स्थापित आहे आणि flags योग्यरीत्या parse होतात याची खात्री करण्यासाठी त्याचा वापर करा. तो disk result म्हणून कधीही उद्धृत करू नका.

dd डिस्क बेंचमार्क का पर्याय का नाही

VPS वरील अनेक चर्चांमध्ये dd दिसते. ते एका मर्यादित प्रश्नाचे उत्तर देते.

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

हे एका thread आणि एकाच वेळी प्रक्रियेत असलेल्या एका request सह sequential write throughput मोजते. ही एक योग्य प्राथमिक तपासणी आहे. यामुळे random IO बद्दल काहीही समजत नाही. तसेच एकाच वेळी 32 requests आल्यावर काय होते, हेही समजत नाही. oflag=direct वगळल्यास, हे मुख्यतः तुमचा kernel memory मध्ये writes किती जलद स्वीकारतो, ते मोजते. म्हणूनच forum posts मध्ये दिलेली dd ची आकडेवारी अनेकदा अवास्तव असते.

CPU: sysbench cpu

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

लक्षात ठेवायचा आकडा events per second आहे. प्रथम single threaded चाचणी चालवा. एका PHP विनंतीला पूर्ण होण्यासाठी किंवा एका compile job ला पूर्ण होण्यासाठी लागणारा वेळ यावर हा आकडा परिणाम करतो. समान किमतीच्या होस्टमधील फरक या बाबतीत सर्वाधिक दिसतो. त्यानंतर प्रत्येक thread वापरून चाचणी चालवा. यावरून तुमचे vCPUs स्वतंत्र cores आहेत की एकाच core चे भाग आहेत, हे समजते.

ही चाचणी नेमके काय मोजते, हे स्पष्ट असू द्या: sysbench cpu 64 bit integer arithmetic वापरून वारंवार prime numbers शोधते. यामुळे memory bandwidth, vector units किंवा cache वर वास्तविक workload सारखा कोणताही ताण येत नाही. त्यामुळे दोन hosts ची क्रमवारी ठरवण्यासाठी ही चाचणी उपयुक्त आहे; मात्र तुमचे application प्रत्यक्षात कसे चालेल, याचा अंदाज घेण्यासाठी ती उपयुक्त नाही.

Ubuntu 24.04 मध्ये sysbench 1.0.20 येते. या आवृत्तीत test name प्रथम लिहावे लागते. जुन्या post मधील --test=cpu असलेली command कॉपी केल्यास WARNING: the --test option is deprecated मिळते. sysbench 0.4 आणि sysbench 1.0 मधील scores एकमेकांशी अजिबात comparable नाहीत. त्यामुळे version नमूद नसलेल्या published number शी स्वतःच्या मोजमापाची तुलना करू नका.

मेमरी: 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

निकाल MiB/sec मध्ये आहे आणि प्रत्येक मशीनवर लेखनापेक्षा वाचनाचा वेग अधिक असतो. --memory-block-size चे मूल्य 1M ठेवा आणि तुलना करत असलेल्या प्रत्येक host वर ते समान ठेवा. 1K वर संख्या मोठ्या प्रमाणात कमी होते, कारण प्रत्येक operation चा overhead हजारपट अधिक वेळा भरावा लागतो. त्यामुळे मेमरी bandwidth ऐवजी loop चा खर्च मोजला जातो. प्रकाशित मेमरी गुणांकनांमध्ये हा सर्वाधिक वेळा विसंगत असलेला flag आहे.

नेटवर्क: iperf3

थ्रूपुट तपासण्याची योग्य पद्धत म्हणजे तुमच्या नियंत्रणाखालील दुसऱ्या मशीनविरुद्ध चाचणी घेणे. त्यामुळे दोन्ही टोकांवर काय सुरू आहे हे तुम्हाला माहीत असते.

दूरच्या टोकावर:

iperf3 -s

हा TCP 5201 वर ऐकतो. तुम्ही ज्या address वरून चाचणी घेणार आहात त्यासाठीच हा port उघडा. चाचणी पूर्ण झाल्यावर तो बंद करा. VPS वरील मूलभूत ufw firewall नियम याची syntax स्पष्ट करते.

चाचणीच्या VPS वरून:

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

पहिली कमांड चाचणी होत असलेल्या मशीनकडून होणारे upload मोजते. -R दिशानिर्देश उलटते आणि download मोजते. -P 8 आठ समांतर streams उघडते.

एकल stream आणि समांतर आवृत्ती, दोन्ही चालवा. कारण त्या वेगवेगळ्या प्रश्नांची उत्तरे देतात. एका TCP connection मध्ये त्याच्या window ने परवानगी दिलेल्या मर्यादेइतकाच unacknowledged data ठेवता येतो. त्यामुळे त्याची कमाल गती साधारणपणे window size भागिले round trip time इतकी असते. 80 ms latency आणि 4 MB window असल्यास ही कमाल गती सुमारे 400 Mbit/s असते, जरी त्यामागील link कितीही वेगवान असली तरी. एकल stream मधून एका download ला मिळणारी गती समजते. समांतर आवृत्तीतून link ची capacity समजते.

ही चाचणी घेताना तुमच्या bandwidth allowance वर लक्ष ठेवा. 1 Gbit/s वेगाने 30 सेकंदांत सुमारे 3.75 GB data transfer होतो. प्रत्येक दिशेने ही चाचणी अनेकदा चालवावी लागेल.

संदर्भ आकडे आणि तुमचे आकडे कसे समजून घ्यावेत

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

प्रकाशित निकालांमध्ये स्थानिक NVMe volume ला साधारणपणे 180,000 4k random read IOPS मिळतात. स्थानिक SATA SSD चा निकाल साधारण 90,000 असतो. Network attached block storage मध्ये प्रत्येक विनंती disk पर्यंत पोहोचण्यापूर्वी network मधून जाते. त्यामुळे त्याचा निकाल साधारण 12,000 असतो. Spinning disk ला साधारण 180 मिळतात, कारण प्रत्येक random विनंतीसाठी त्याला physical head हलवावा लागतो.

हे प्रत्येक storage वर्गासाठी प्रकाशित केलेले सामान्य आकडे आहेत. ते एका host वरील मोजमाप नाहीत. त्यांचा एकाच कारणासाठी वापर करा: तुमचा स्वतःचा निकाल योग्य order of magnitude मध्ये आहे का, हे तपासण्यासाठी. NVMe म्हणून विकल्या जाणाऱ्या plan च्या benchmark मध्ये 4k IOPS चे आकडे काही हजारांच्या पातळीवर असल्यास, प्रथम --direct=1 सुरू होते का ते तपासा. ते सुरू असल्यास, storage हे product page मध्ये वर्णन केल्याप्रमाणे नाही किंवा तुम्ही ते अतिशय व्यस्त शेजारी असलेल्या इतर ग्राहकांसोबत share करत आहात.

एक रन म्हणजे बेंचमार्क नाही

एकच निकाल सामायिक मशीनवरील एका मिनिटाचे स्थितिचित्र असतो. त्याला एक नमुना म्हणून घ्या.

• प्रत्येक चाचणी किमान पाच वेळा चालवा. त्या वेगवेगळ्या तासांत आणि किमान दोन वेगवेगळ्या दिवसांत चालवा. मध्यक आणि प्रसरण नोंदवा. प्रसरणाशिवाय प्रकाशित केलेला निकाल ही विपणनासाठी वापरलेली आकडेवारी असते.
• प्रत्येक रनसोबत steal time नोंदवा. st जास्त असलेले रन काढून टाका किंवा किमान तसे स्पष्टपणे नमूद करा.
• disk चाचणी दोन कालावधींवर चालवा. अनेक plans मध्ये burst IOPS allowance असतो, जो कालांतराने पुन्हा भरतो. त्यामुळे 60 second fio run burst मोजतो, तर --runtime=600 किमान कामगिरी मोजतो. खराब दिवशी तुम्हाला मिळणारी कामगिरी हीच किमान कामगिरी असते.
• इतर कोणतीही प्रक्रिया चालू नाही याची खात्री करा. CPU चाचणीच्या मध्यावर unattended-upgrades apt transaction सुरू केल्यास प्रत्यक्ष गुण कमी होतात आणि प्रत्येक रनपूर्वी ps -e -o comm= | grep -E 'apt|dpkg' करण्यासाठी एक सेकंद लागतो.
• एका वेळी एकच variable बदला. वेगवेगळ्या tool versions, block sizes किंवा thread counts मुळे मिळणाऱ्या संख्यांची तुलना करता येत नाही, त्या दिसायला कितीही सारख्या असल्या तरी.

दोन providers ची तुलना करताना, दोन्ही चाचण्या त्याच दिवशी त्याच तासाला चालवा. अन्यथा तुम्ही दिवसातील वेळेचे मोजमाप केलेले असेल.

तुमच्या स्वतःच्या वर्कलोडचे शेवटी बेंचमार्क करा

सिंथेटिक साधने मशीनची क्रमवारी ठरवतात. मशीन पुरेसे आहे की नाही हे फक्त तुमचे स्वतःचे वर्कलोड सांगते. तुम्ही प्रत्यक्षात करत असलेल्या कामाचा वेळ मोजा.

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

यामुळे काहीशे मेगाबाइट्सचे संकुचन होते. त्यामुळे CPU आणि डिस्क या दोन्हींची एकत्र चाचणी होते आणि त्यापैकी कोणत्याही घटकात बदल झाल्यास निकाल बदलतो. Removing leading / from member names चेतावणी सामान्य आहे. त्याहून चांगले म्हणजे तुमच्या स्वतःच्या build चा, सर्वाधिक वेळ घेणाऱ्या query चा किंवा page render चा वेळ मोजा. एका host वर build पूर्ण होण्यासाठी 4 मिनिटे आणि दुसऱ्यावर 7 मिनिटे लागत असतील, तर Geekbench ने काहीही निष्कर्ष दिला असला तरी प्रश्नाचे उत्तर स्पष्ट झाले आहे. अधिक क्षमतेच्या मशीनसाठी पैसे देणे कधी थांबवावे हेही याच मोजमापातून समजते. VPS ची दरमहा प्रत्यक्ष किंमत किती असते हे वाचण्यापूर्वी किंवा वर्कलोड dedicated server वर हलवण्यापूर्वी हे जाणून घेणे उपयुक्त आहे.

FAQ

मी बेंचमार्क प्रत्येक वेळी चालवल्यावर वेगळा परिणाम का मिळतो?

VPS इतर भाडेकरूंसोबत भौतिक CPU, storage आणि network सामायिक करते. त्यामुळे त्या क्षणी ते काय करत आहेत यावर तुमचा परिणाम अवलंबून असतो. चाचणीदरम्यान vmstat 1 चालवा आणि st स्तंभ वाचा: 5 पेक्षा जास्त सातत्यपूर्ण steal time असल्यास host व्यस्त होता आणि तुमचा CPU score तुमच्या machine बाहेरील कारणांमुळे कमी आहे. याचे उत्तर tuning नसून पद्धतशीर चाचणी आहे. प्रत्येक चाचणी वेगवेगळ्या वेळांमध्ये पाच किंवा अधिक वेळा चालवा. त्यानंतर spread सोबत median नोंदवा.

fio लाखो IOPS का दाखवते?

बहुतेक वेळा --direct=1 नसल्यामुळे असे होते. ते नसल्यास fio kernel page cache मधून वाचते. त्यामुळे पहिल्या pass नंतर 2G चाचणी file RAM मधून दिली जाते आणि तुम्ही memory bandwidth मोजलेली असते. --direct=1 जोडा आणि चाचणी file path मधील कोणत्याही cache पेक्षा मोठी ठेवा. --direct=1 नंतर err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1 त्रुटी आल्यास df -hT . चालवा: overlay चे Type O_DIRECT support करत नाही. त्यामुळे चाचणी वास्तविक storage वर निर्देशित करा.

yabs.sh स्वतःपुरते पुरेसे आहे का?

प्राथमिक आढाव्यासाठी, होय. ते चार block sizes वर fio, दोन्ही दिशांमध्ये iperf3 आणि Geekbench चालवते. तसेच इतर लोक वाचू शकतील असा एक summary छापते. एखादा number असा का आहे हे जाणून घ्यायचे असल्यास ते अपुरे ठरते, कारण प्रत्येक test साठी त्याचे flags बदलता येत नाहीत. yabs चा result चुकीचा वाटल्यास तो fio किंवा sysbench थेट वापरून पुन्हा तयार करा. एका वेळी एकच flag बदला.

माझ्या application चा प्रत्यक्ष अनुभव कोणता एक number दर्शवतो?

बहुतेक web आणि database workloads साठी, प्रथम single core CPU speed आणि त्यानंतर 4k random read latency महत्त्वाची असते. Throughput चे आकडे प्रभावी दिसतात, परंतु ते क्वचितच निर्णायक ठरतात, कारण सामान्य request लहान असते. fio च्या clat percentiles block मधील average ऐवजी 99th percentile नोंदवा. शंभरपैकी एक धीमी request वापरकर्त्याच्या लक्षात येते.

बेंचमार्क करण्यापूर्वी काही install करणे आवश्यक आहे का?

fio, sysbench आणि iperf3 हे Ubuntu आणि Debian archives मध्ये उपलब्ध आहेत: sudo apt install -y fio sysbench iperf3. yabs.sh साठी फक्त curl आवश्यक आहे, कारण ते उपलब्ध नसलेल्या घटकांसाठी static binaries download करते. काम पूर्ण झाल्यावर प्रत्येक test file delete करा. 20G disk वर ठेवलेली 2G fio file काही आठवड्यांनी disk full alert निर्माण करू शकते.