VPS benchmark சரியாக செய்வது எப்படி? yabs.sh, fio, iperf3

VPS-ஐ benchmark செய்வதன் பொருள்

VPS-ஐ benchmark செய்யும்போது 4 அம்சங்களை அளவிடுகிறீர்கள்: ஒரு CPU core எவ்வளவு வேகமாக இயங்குகிறது, machine-இன் memory bandwidth எவ்வளவு, storage ஒவ்வொரு வினாடியும் எத்தனை சிறிய random disk operations-ஐ வழங்குகிறது, network link எவ்வளவு throughput வழங்குகிறது என்பவை. yabs.sh-ஐ ஒரு முறை இயக்கினால், சுமார் 10 நிமிடங்களில் இந்த 4 அம்சங்களையும் பெறலாம். முடிவைப் புரிந்துகொள்வதே கடினமான பகுதி. VPS, பிற tenants உடன் physical hardware-ஐ பகிர்ந்து பயன்படுத்துவதால், அதே machine 03:00 மணிக்கு ஒரு எண்ணையும் 20:00 மணிக்கு முற்றிலும் வேறொரு எண்ணையும் காட்டக்கூடும்.

முதலில் விரைவான நிலவரத்தைப் பெற yabs.sh-ஐ இயக்குங்கள். பின்னர் அதன் கீழ் பயன்படுத்தப்படும் tools-ஐ கைமுறையாக இயக்குங்கள். நீங்களே அவற்றை இயக்கும்போதுதான் ஒரு flag-ஐ மாற்றி, எண்ணில் ஏற்படும் மாற்றத்தைக் கண்காணித்து, அந்த எண் உண்மையில் எதை அளந்தது என்பதைப் புரிந்துகொள்ள முடியும். Machine அமைக்கப்பட்ட பிறகு இதைச் செய்யுங்கள்; அதற்கு முன் செய்ய வேண்டாம். புதிய VPS-இல் முதல் 10 நிமிடங்கள் என்ற படிகள் முதலில் வருகின்றன. ஏனெனில், ஒரு box தனது முதல் updates தொகுப்பைப் பயன்படுத்திக்கொண்டிருக்கும்போது, hardware-க்கு எந்தத் தொடர்பும் இல்லாத காரணங்களால் benchmark முடிவுகள் தவறாக இருக்கும்.

அளவிடுவதற்கு முன் இயந்திரத்தைப் பாருங்கள்

ஒவ்வொரு மோசமான benchmark-இலும் பாதி, அதன் ஆசிரியர் புரிந்துகொள்ளாத இயந்திரத்தால் ஏற்படுகிறது.

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

Hypervisor vendor: KVM என்பது முழுமையான virtualisation என்பதைக் குறிக்கிறது. எனவே நீங்கள் உங்கள் சொந்த kernel-ஐ இயக்குகிறீர்கள். systemd-detect-virt இல் lxc அல்லது openvz அச்சிடப்பட்டிருந்தால், அது container virtualisation என்பதைக் குறிக்கிறது. இதில் host kernel-ஐப் பகிர்ந்து பயன்படுத்துகிறீர்கள். உங்கள் CPU மற்றும் memory வரம்புகள் virtual hardware-க்கு பதிலாக cgroup (control group) அமைப்புகளாகும். cgroup v2 system-இல் CPU வரம்பை நேரடியாகப் படிக்கலாம்.

cat /sys/fs/cgroup/cpu.max

max 100000 என்பது quota இல்லை என்பதைக் குறிக்கிறது. 200000 100000 என்பது ஒவ்வொரு 100000 microsecond காலப்பகுதியிலும் 200000 microseconds CPU-ஐப் பயன்படுத்தலாம் என்பதைக் குறிக்கிறது. இது இரண்டு cores அளவிலான quota ஆகும். இரண்டு cores quota கொண்ட 4 vCPU என விளம்பரப்படுத்தப்படும் plan, நான்கு cores போல ஒருபோதும் score பெறாது. இதற்கான காரணத்தை எந்த benchmark tool-மும் ஒரு வரியாக அச்சிடாது.

df -hT / வேறு காரணத்திற்காக முக்கியமானது: Type column. அதில் overlay என இருந்தால், நீங்கள் container-க்குள் இருக்கிறீர்கள். அப்போது கீழே உள்ள disk test-இல் மாற்றம் தேவைப்படும். இதை இப்போது குறித்துக்கொள்ளுங்கள்.

தொடர்ந்து steal time-ஐ கண்காணிக்கவும்

Steal time என்பது உங்கள் virtual CPU இயக்கத்திற்குத் தயாராக இருந்தபோது, hypervisor physical core-ஐ வேறு ஒருவருக்கு வழங்கிய நேரத்தின் விகிதமாகும். ஒரு முடிவு உங்கள் hardware-ஐப் பற்றியதல்ல, அருகிலுள்ள virtual machine-களைப் பற்றியது என்பதை காட்டும் மிகப் பயனுள்ள தனிப்பட்ட குறியீடு இதுவாகும்.

vmstat 1 10

வலப்புறத்தில் உள்ள st column-ஐப் படிக்கவும். தொடர்ந்து 0 அல்லது 1 காணப்படுவது இயல்பானது. 5-ஐ விட அதிகமான மதிப்புகள் தொடர்ந்து காணப்பட்டால், அந்த நேரத்தில் host-ல் தேவைக்கு அதிகமான workload உள்ளது. எனவே, அந்தக் காலப்பகுதியில் நீங்கள் பதிவு செய்யும் ஒவ்வொரு CPU எண்ணும் உங்கள் machine-ன் குறைபாடு இல்லாமலேயே குறைவாக இருக்கும். top, CPU line-ல் %st காட்டும் அதே மதிப்பைக் காட்டுகிறது. benchmark இயக்கும்போது, இரண்டாவது SSH session-ல் vmstat 1-ஐ இயக்கத்தில் வைத்திருக்கவும். ஒவ்வொரு முடிவுக்கும் அருகில் steal figure-ஐ எழுதவும்.

yabs.sh உடன் தொடங்குதல்

yabs.sh (Yet Another Bench Script) என்பது static fio, iperf3 மற்றும் Geekbench binaries-ஐ download செய்து, அவற்றை இயக்கி, ஒரே summary-ஐ காட்டும் shell script ஆகும். VPS benchmark விவாதங்களில் இது பொதுவாகப் பயன்படுத்தப்படும் மொழியாகும். எனவே, மற்றொருவரின் முடிவுகளுடன் ஒப்பிட yabs output-ஐப் பயன்படுத்துவது மிக விரைவான வழியாகும்.

Project வழங்கும் one-line வடிவம் இதுதான்.

curl -sL yabs.sh | bash

இது URL தற்போது வழங்கும் உள்ளடக்கத்தை நேரடியாக shell-க்கு pipe செய்கிறது. முதலில் அதை download செய்து, படித்து, பின்னர் இயக்கவும்.

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

Pipe செய்யும்போது -s ---க்குப் பிறகு flags-ஐ இடவும். Local copy-ஐ இயக்கும்போது filename-க்குப் பிறகு நேரடியாக இடவும். பயனுள்ள options: -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

முதல் run-க்கு முன் தெரிந்திருக்க வேண்டிய 2 விஷயங்கள் உள்ளன. Geekbench உங்கள் result-ஐ upload செய்து, public browser.geekbench.com URL-ஐக் காட்டும். அந்த link வைத்திருக்கும் எவரும் உங்கள் CPU model மற்றும் scores-ஐப் பார்க்க முடியும். -g இந்த test-ஐ முழுமையாகத் தவிர்க்கும். இரண்டாவதாக, iperf3 stage பல regions-ல் உள்ள servers-க்கு உண்மையான network traffic-ஐ அனுப்பும். இது உங்கள் மாதாந்திர bandwidth allowance-ல் கணக்கிடப்படும். 1 Gbit/s link-ல் முழு network stage பத்துக்கணக்கான gigabytes அளவிலான traffic-ஐ நகர்த்தக்கூடும். எனவே, குறைந்த allowance இருந்தால் -r-ஐயும், metered link இருந்தால் -i-ஐயும் பயன்படுத்தவும்.

yabs வெளியீட்டின் ஒவ்வொரு பகுதியும் குறிக்கும் பொருள்

Disk பகுதி, 4k, 64k, 512k மற்றும் 1m ஆகிய நான்கு block sizes-இல், 50/50 read மற்றும் write கலவையுடன் fio-ஐ இயக்குகிறது. ஒவ்வொன்றிற்குமான IOPS (input/output operations per second) மற்றும் bandwidth மதிப்புகளை இது அறிக்கையிடுகிறது. Database, mail server அல்லது பல சிறிய writes செய்யும் வேறு எந்தப் பயன்பாட்டிற்கும் 4k row முக்கியமானது. காரணம், பெரும்பாலான server IO சிறியதாகவும் சிதறியதாகவும் இருக்கும். Backup மற்றும் video பயன்பாடுகளுக்கு 1m row பொருத்தமானது. இவற்றில் நீண்ட byte தொடர்களை நகர்த்துகிறீர்கள்.

Network பகுதி, பல regions-இல் உள்ள public servers-க்கு எதிராக, இரு திசைகளிலும் parallel streams பயன்படுத்தி iperf3-ஐ இயக்குகிறது. இங்கு கிடைக்கும் குறைந்த மதிப்பை இறுதி முடிவாக அல்ல, விசாரிக்க வேண்டிய அறிகுறியாகக் கருதுங்கள். Public iperf3 servers பகிர்ந்து பயன்படுத்தப்படுவதுடன், அவை அடிக்கடி saturation நிலையில் இருக்கும். எனவே மோசமான முடிவு far 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 பிரிவுக்குப் பின்னால் இயங்கும் tool ஆகும். இதை நேரடியாக இயக்கும்போது அதன் flags-ன் பொருள் தெளிவாகும்.

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

நீங்கள் உண்மையில் பயன்படுத்தும் filesystem-ல், queue depth 32 உடன் 4k random read test:

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

Output-ல் கவனிக்க வேண்டிய summary line இதுபோல் இருக்கும்.

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

அதன் கீழ் fio ஒரு clat percentiles block-ஐ அச்சிடும். குறிப்பிடத்தக்க மதிப்பு 99.00th percentile ஆகும். 100 requests-ல் மெதுவான 1 request எவ்வளவு நேரம் காத்திருந்தது என்பதை இது காட்டுகிறது. Average latency, பயனர் கவனிக்கும் stalls-ஐ மறைத்துவிடும்.

• --direct=1 மூலம் file, O_DIRECT உடன் திறக்கப்படுகிறது. அதனால் reads, kernel page cache-ஐத் தவிர்க்கின்றன. இது இல்லையெனில், 8G RAM கொண்ட machine-ல் 2G file-ஐ இரண்டாவது முறையாகப் படிக்கும்போது data memory-யிலிருந்து வழங்கப்படும். fio, IOPS மதிப்பை millions எனக் காட்டும். அந்த எண்ணிக்கை உண்மையானது, ஆனால் அது memory-யின் எண்ணிக்கை.
• --ioengine=libaio asynchronous requests-ஐ submit செய்கிறது. இதனால் --iodepth=32 ஒரே நேரத்தில் 32 requests-ஐ in flight நிலையில் வைத்திருக்க முடியும். psync போன்ற synchronous engine பயன்படுத்தும்போது, 1-ஐத் தாண்டிய iodepth எந்த விளைவையும் ஏற்படுத்தாது. அப்போது ஒரு நேரத்தில் 1 request மட்டுமே அளவிடப்படும்.
• --time_based --runtime=60, குறிப்பிட்ட அளவு work-க்கு பதிலாக நிர்ணயிக்கப்பட்ட 60 seconds காலத்திற்கு test-ஐ இயக்குகிறது. எனவே fast disk மற்றும் slow disk இரண்டுக்கும் ஒரே wall clock time கிடைக்கும். Comparison நியாயமாக இருக்கும்.
• --size=2G test file-ன் அளவை அமைக்கிறது. Path-ல் உள்ள எந்த cache-ஐவிடவும் file-ஐப் பெரிதாக வைத்திருங்கள். முதலில் போதுமான free space உள்ளதா எனச் சரிபார்க்கவும்.

Random write-க்கு அதே command-ஐ --rw=randwrite உடன் பயன்படுத்தவும். அதைத் தனியாக இயக்கிய பிறகு 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

Real traffic-க்கு நெருக்கமான mix-க்கு --rw=randrw --rwmixread=70 பயன்படுத்தவும். நீங்கள் பயன்படுத்தும் storage வகை, flags எதையும் விட இந்த results-ஐ அதிகமாக மாற்றும். அந்த வேறுபாடு VPS-ல் NVMe மற்றும் SATA SSD storage இடையிலான வேறுபாடு பகுதியில் விளக்கப்பட்டுள்ளது.

fio Unknown error -1 என நிறுத்தப்படும்போது

Direct IO அனைத்து filesystem-களிலும் கிடைக்காது. overlay என்பது Docker இயல்பாக container-க்கு வழங்கும் filesystem ஆகும்; பல network filesystem-களும் O_DIRECT-ஐ ஆதரிக்காது. எனவே libaio, kernel நிறைவேற்ற முடியாத request-ஐ சமர்ப்பிக்கிறது; 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 column-ல் overlay என்று இருந்தால், --filename-ஐ bind mounted volume போன்ற உண்மையான storage-ல் உள்ள path-க்கு மாற்றவும் அல்லது container-க்குள் அல்லாமல் 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 file page cache-ல் இருக்கும். எனவே IOPS மதிப்பு உங்கள் RAM-ஐக் குறிக்கிறது. fio நிறுவப்பட்டுள்ளதா மற்றும் flags சரியாக parse ஆகிறதா என்பதை உறுதிப்படுத்த இதைப் பயன்படுத்தவும். இதை disk முடிவாக ஒருபோதும் குறிப்பிட வேண்டாம்.

dd disk benchmark அல்ல

பல 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 பதிவுகளில் குறிப்பிடப்படும் 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 request எவ்வளவு விரைவாக நிறைவடையும் அல்லது ஒரு compile job எவ்வளவு விரைவாக முடியும் என்பதை நிர்ணயிக்கும் எண் இதுவாகும். ஒரே விலையில் உள்ள hosts-க்கு இடையே இது மிக அதிகமாக மாறுபடும். அதன் பிறகு அனைத்து threads-ஐ பயன்படுத்தி இயக்கவும். இதன் மூலம் உங்கள் vCPUs தனித்தனி cores-ஆக உள்ளனவா அல்லது ஒரே core-இன் slices-ஆக உள்ளனவா என்பதை அறியலாம்.

இது எதை அளவிடுகிறது என்பதைத் தெளிவாகப் புரிந்துகொள்ளவும்: 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-ஐ copy செய்தால், உங்களுக்கு WARNING: the --test option is deprecated கிடைக்கும். sysbench 0.4 மற்றும் sysbench 1.0 ஆகியவற்றின் scores ஒன்றுக்கொன்று ஒப்பிட முடியாதவை. ஆகவே அதன் 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 அலகில் வழங்கப்படுகிறது. ஒவ்வொரு machine-இலும் writes-ஐவிட reads வேகமாக இருக்கும். --memory-block-size மதிப்பை 1M ஆக வைத்திருங்கள். நீங்கள் ஒப்பிடும் ஒவ்வொரு host-இலும் அதே மதிப்பைப் பயன்படுத்துங்கள். 1K மதிப்பில், ஒவ்வொரு operation-க்குமான overhead ஆயிரம் மடங்கு அதிகமாக ஏற்படுவதால், எண் மிகவும் குறைகிறது. எனவே memory bandwidth-ஐ அல்லாமல் loop செலவையே அளவிடுகிறீர்கள். வெளியிடப்பட்ட memory scores-இல் மிகவும் அடிக்கடி பொருந்தாமல் இருக்கும் flag இதுவாகும்.

Network: iperf3

Throughput-ஐ சோதிப்பதற்கான சரியான முறை, நீங்கள் நிர்வகிக்கும் இரண்டாவது machine-க்கு எதிராகச் சோதிப்பதாகும். அப்போது இரு முனைகளிலும் என்ன நடக்கிறது என்பதை நீங்கள் அறிந்திருப்பீர்கள்.

தொலைநிலை முனையில்:

iperf3 -s

இது TCP 5201-ல் listen செய்யும். நீங்கள் சோதனை நடத்தும் 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

முதல் command, சோதிக்கப்படும் machine-லிருந்து upload-ஐ அளக்கும். -R திசையை மாற்றி download-ஐ அளக்கும். -P 8 எட்டு parallel streams-ஐத் திறக்கும்.

Single stream மற்றும் parallel version இரண்டையும் இயக்கவும். அவை வெவ்வேறு கேள்விகளுக்குப் பதிலளிக்கும். ஒரு TCP connection, அதன் window அனுமதிக்கும் அளவு unacknowledged data-வை மட்டுமே வைத்திருக்க முடியும். எனவே அதன் அதிகபட்ச வேகம், சுமார் window size-ஐ round trip time-ஆல் வகுத்த அளவாக இருக்கும். 80 ms latency மற்றும் 4 MB window இருந்தால், அடிப்படை link எவ்வளவு வேகமாக இருந்தாலும், அந்த வரம்பு சுமார் 400 Mbit/s ஆகும். Single stream அளவு, ஒரு download பெறும் வேகத்தைத் தெரிவிக்கும். Parallel அளவு, link-ன் capacity-ஐத் தெரிவிக்கும்.

இந்தச் சோதனையை நடத்தும்போது உங்கள் bandwidth allowance-ஐக் கண்காணிக்கவும். 1 Gbit/s வேகத்தில் 30 seconds இயக்கினால் சுமார் 3.75 GB data நகரும். ஒவ்வொரு திசையிலும் இதை பல முறை இயக்குவீர்கள்.

குறிப்பு அளவீடுகள் மற்றும் உங்கள் முடிவை எவ்வாறு புரிந்துகொள்வது

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

வெளியிடப்பட்ட முடிவுகளில் local NVMe volume பொதுவாக 180,000 4k random read IOPS அளவை நெருங்கும். local SATA SSD பொதுவாக 90,000 அளவில் இருக்கும். Network attached block storage-இல் ஒவ்வொரு request-உம் disk-ஐ அடையும் முன் network வழியாகச் செல்ல வேண்டும். எனவே அது 12,000 அளவை நெருங்கும். Spinning disk சுமார் 180 அளவை வழங்கும். காரணம், ஒவ்வொரு random request-க்கும் அது physical head-ஐ நகர்த்த வேண்டும்.

இவை ஒவ்வொரு storage வகுப்பிற்குமான வழக்கமான வெளியிடப்பட்ட அளவீடுகள். இவை ஒரு host-இலிருந்து பெறப்பட்ட அளவீடுகள் அல்ல. உங்கள் சொந்த முடிவு சரியான அளவுவரம்பில் உள்ளதா என்பதைச் சரிபார்ப்பதற்காக மட்டுமே இவற்றைப் பயன்படுத்தவும். NVMe என விற்கப்படும் plan, 4k IOPS-ல் சில ஆயிரங்களாக benchmark ஆகுமானால், முதலில் --direct=1 இயக்கப்பட்டிருந்ததா என்பதை உறுதிப்படுத்தவும். அது இயக்கப்பட்டிருந்தால், storage என்பது product page விவரிப்பதல்ல, அல்லது மிகப் busy-ஆன neighbour உடன் அதை நீங்கள் பகிர்ந்து பயன்படுத்துகிறீர்கள்.

ஒரு run benchmark அல்ல என்பதற்கான காரணம்

ஒரே result என்பது shared machine-இல் ஒரு நிமிடத்தின் snapshot மட்டுமே. அதை ஒரு sample ஆகக் கருதுங்கள்.

• ஒவ்வொரு test-ஐயும் குறைந்தது ஐந்து முறை run செய்யுங்கள். வெவ்வேறு hours-களிலும், குறைந்தது இரண்டு வெவ்வேறு days-களிலும் அவற்றை நடத்துங்கள். median மற்றும் spread-ஐ வைத்திருங்கள். spread இல்லாமல் வெளியிடப்படும் result ஒரு marketing figure ஆகும்.
• ஒவ்வொரு run-க்கும் அருகில் steal time-ஐ பதிவு செய்யுங்கள். st அதிகமாக இருந்த runs-ஐ நீக்குங்கள். குறைந்தபட்சம், அது அதிகமாக இருந்தது என்று குறிப்பிடுங்கள்.
• disk test-ஐ இரண்டு durations-இல் run செய்யுங்கள். பல plans, காலப்போக்கில் மீண்டும் நிரம்பும் burst IOPS allowance-ஐ வழங்குகின்றன. எனவே, 60 second fio run burst-ஐ அளவிடுகிறது; --runtime=600 floor-ஐ அளவிடுகிறது. மோசமான நாளில் நீங்கள் பெறுவது அந்த floor ஆகும்.
• வேறு எதுவும் run ஆகவில்லை என்பதைச் சரிபார்க்குங்கள். CPU test நடுவில் unattended-upgrades apt transaction-ஐ தொடங்கினால், உண்மையான points இழக்கப்படும். ஒவ்வொரு run-க்கும் முன் ps -e -o comm= | grep -E 'apt|dpkg' செய்ய ஒரு second ஆகும்.
• ஒரே நேரத்தில் ஒரு variable-ஐ மட்டும் மாற்றுங்கள். வேறுபட்ட tool versions, block sizes அல்லது thread counts ஒப்பிட முடியாத numbers-ஐ உருவாக்கும். அவை தோற்றத்தில் எவ்வளவு ஒத்திருந்தாலும் இது மாறாது.

இரண்டு providers-ஐ ஒப்பிடும்போது, ஒரே நாளின் ஒரே hour-இல் அவற்றை run செய்யுங்கள். இல்லையெனில், நீங்கள் அளந்தது நாளின் நேரத்தை மட்டுமே.

உங்கள் சொந்த workload-ஐ இறுதியில் benchmark செய்யுங்கள்

Synthetic tools இயந்திரங்களை தரவரிசைப்படுத்துகின்றன. ஒரு இயந்திரம் போதுமானதா என்பதை உங்கள் சொந்த workload மட்டுமே தெரிவிக்கும். நீங்கள் உண்மையில் செய்வதற்கு நேரத்தை அளவிடுங்கள்.

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

இது சில நூறு megabytes-ஐ compress செய்வதால், CPU மற்றும் disk இரண்டையும் ஒன்றாகச் சோதிக்கிறது. இரண்டில் ஏதேனும் ஒன்று மாறும்போது இதன் முடிவும் மாறும். Removing leading / from member names warning இயல்பானது. இன்னும் சிறந்த முறையாக, உங்கள் சொந்த build, உங்கள் சொந்த slowest query அல்லது உங்கள் சொந்த page render-க்கு நேரத்தை அளவிடுங்கள். ஒரு host-ல் build 4 minutes எடுத்தும், மற்றொன்றில் 7 எடுத்தும் இருந்தால், Geekbench என்ன நினைத்தாலும் கேள்விக்கான பதில் தெளிவாகிவிடும். அதிக machine-க்கு பணம் செலுத்துவது இனி பயனுள்ளதாக இல்லாத நேரத்தையும் இந்த அளவீடு தெரிவிக்கும். நீங்கள் ஒரு VPS-க்கு மாதத்திற்கு உண்மையில் எவ்வளவு செலவாகும் என்பதைப் படிப்பதற்கு முன்போ அல்லது workload-ஐ dedicated server-க்கு மாற்றுவதற்கு முன்போ இதை அறிந்திருப்பது பயனுள்ளதாகும்.

FAQ

ஒவ்வொரு முறையும் இயக்கும்போது ஏன் வேறுபட்ட benchmark முடிவு கிடைக்கிறது?

VPS, பிற tenants உடன் physical CPU, storage மற்றும் network வளங்களைப் பகிர்கிறது. எனவே, அந்த நேரத்தில் அவர்கள் என்ன செய்கிறார்கள் என்பதன் அடிப்படையில் உங்கள் முடிவு மாறும். சோதனையின்போது vmstat 1 ஐ இயக்கி, st column-ஐப் பாருங்கள்: 5-க்கு அதிகமான தொடர்ச்சியான steal time இருந்தால் host busy ஆக இருந்தது. உங்கள் machine-க்கு வெளியிலுள்ள காரணங்களால் CPU score குறைவாக இருக்கும். இதற்கான தீர்வு tuning அல்ல; முறையான சோதனை நடைமுறையே. ஒவ்வொரு சோதனையையும் வெவ்வேறு நேரங்களில் ஐந்து அல்லது அதற்கு மேற்பட்ட முறை இயக்குங்கள். பின்னர் median-ஐ spread உடன் அறிக்கையிடுங்கள்.

fio ஏன் millions of IOPS எனக் காட்டுகிறது?

கிட்டத்தட்ட எப்போதும் --direct=1 இல்லை என்பதே காரணம். அது இல்லாமல் fio, kernel page cache வழியாகப் படிக்கும். எனவே, முதல் pass-க்குப் பிறகு 2G test file RAM-இலிருந்து வழங்கப்படும். அப்போது நீங்கள் memory bandwidth-ஐ அளந்திருக்கிறீர்கள். --direct=1 ஐச் சேர்த்து, test file பாதையில் உள்ள எந்த cache-ஐவிடவும் பெரியதாக வைத்திருங்கள். பின்னர் --direct=1, err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1 உடன் தோல்வியடைந்தால், df -hT . ஐ இயக்குங்கள்: overlay இன் Type, O_DIRECT ஐ ஆதரிக்காது. எனவே சோதனையை உண்மையான storage-க்கு மாற்றுங்கள்.

yabs.sh மட்டும் போதுமா?

முதல் பார்வைக்கு, ஆம். இது நான்கு block sizes-இல் fio-ஐ இயக்குகிறது. மேலும் இரு திசைகளிலும் iperf3-ஐ இயக்கி, பிறர் படிக்கக்கூடிய ஒரு summary-ஐ அச்சிடுகிறது. ஆனால் ஒரு எண்ணுக்கான காரணத்தை அறிய விரும்பும்போது இது போதாது. ஏனெனில் ஒவ்வொரு test-க்கும் அதன் flags-ஐ தனித்தனியாக மாற்ற முடியாது. yabs முடிவு தவறாகத் தோன்றும்போது, அதை fio அல்லது sysbench மூலம் நேரடியாக மீண்டும் உருவாக்குங்கள். ஒவ்வொரு முறையும் ஒரு flag-ஐ மட்டும் மாற்றுங்கள்.

என் application எவ்வாறு செயல்படும் என்பதை முன்கணிக்கும் ஒரே எண் எது?

பெரும்பாலான web மற்றும் database workloads-க்கு, முதலில் single core CPU speed, அடுத்து 4k random read latency முக்கியமானவை. Throughput figures கவர்ச்சியாகத் தோன்றினாலும், அவை அரிதாகவே முடிவை நிர்ணயிக்கும். காரணம், ஒரு வழக்கமான request சிறியதாக இருக்கும். fio clat percentiles block-இலிருந்து average-க்கு பதிலாக 99th percentile-ஐக் குறிப்பிடுங்கள். 100 requests-இல் மெதுவான ஒரு request-ஐத்தான் user கவனிப்பார்.

benchmarking-க்கு முன் ஏதேனும் install செய்ய வேண்டுமா?

fio, sysbench மற்றும் iperf3 ஆகியவை Ubuntu மற்றும் Debian archives-இல் உள்ளன: sudo apt install -y fio sysbench iperf3. yabs.sh க்கு curl மட்டும் தேவை. இல்லாதவற்றுக்கான static binaries-ஐ அது download செய்கிறது. முடித்ததும் ஒவ்வொரு test file-ஐயும் நீக்குங்கள். 20G disk-இல் விடப்படும் 2G fio file, சில வாரங்களுக்குப் பிறகு disk full alert-க்கு காரணமாகலாம்.