VPS செயல்திறனை சரியாக benchmark செய்வது எப்படி?

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

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

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

அளவீடு செய்வதற்கு முன் இயந்திரத்தை ஆய்வு செய்தல்

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

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

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

cat /sys/fs/cgroup/cpu.max

max 100000 என்பது ஒதுக்கீடு (quota) இல்லை என்பதைக் குறிக்கிறது. 200000 100000 என்பது, ஒவ்வொரு 100000 மைக்ரோ விநாடி கால அளவிலும் நீங்கள் 200000 மைக்ரோ விநாடி CPU-ஐப் பயன்படுத்தலாம் என்பதைக் குறிக்கிறது, இது இரண்டு cores-க்கான ஒதுக்கீட்டிற்குச் சமம். 4 vCPU என்று விளம்பரப்படுத்தப்பட்டு, இரண்டு cores-க்கான ஒதுக்கீடு மட்டுமே கொண்ட ஒரு திட்டம், நான்கு cores-க்கு இணையான செயல்திறனை ஒருபோதும் தராது; எந்தவொரு benchmark கருவியும் இதற்கான காரணத்தை உங்களுக்குத் தெரிவிப்பதில்லை.

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

Steal time-ஐ எப்போதும் கண்காணிக்கவும்

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

vmstat 1 10

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

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

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

இந்தத் திட்டத்தின் ஒரு வரி கட்டளை இதுதான்.

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 செய்யும்போது -s ---க்கு பிறகும், அல்லது local copy-ஐ இயக்கும்போது கோப்பின் பெயருக்குப் பிறகும் flags-ஐச் சேர்க்கலாம். பயனுள்ள flags: -f வட்டுச் சோதனையைத் தவிர்க்கும், -i பிணையச் சோதனையைத் தவிர்க்கும், -g Geekbench-ஐத் தவிர்க்கும், -r iperf3 இடங்களை இரண்டாகக் குறைக்கும், -j முடிவுகளை JSON வடிவில் அச்சிடும், மற்றும் -w results.json அந்த JSON-ஐ ஒரு கோப்பில் எழுதும்.

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

முதல் முறை இயக்கும் முன் இரண்டு விஷயங்களை அறிந்து கொள்ள வேண்டும். Geekbench உங்கள் முடிவுகளைப் பதிவேற்றி, ஒரு பொதுவான browser.geekbench.com URL-ஐ வழங்கும், எனவே அந்த இணைப்பை வைத்திருக்கும் எவரும் உங்கள் CPU மாதிரி மற்றும் மதிப்பெண்களைப் பார்க்க முடியும். -g அந்தச் சோதனையை முழுமையாகத் தவிர்க்கும். இரண்டாவதாக, iperf3 நிலை பல்வேறு பகுதிகளில் உள்ள server-களுக்கு உண்மையான traffic-ஐ அனுப்பும், இது உங்கள் மாதாந்திர bandwidth ஒதுக்கீட்டைக் குறைக்கும். 1 Gbit/s இணைப்பில், முழுமையான பிணையச் சோதனை பல gigabytes தரவை மாற்றக்கூடும், எனவே குறைந்த ஒதுக்கீடு இருந்தால் -r-ஐயும், அளவிடப்பட்ட (metered) இணைப்பில் -i-ஐயும் பயன்படுத்தவும்.

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

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

Network பகுதி, பல பிராந்தியங்களில் உள்ள பொது server-களுக்கு எதிராக, இரு திசைகளிலும் parallel streams-ஐப் பயன்படுத்தி iperf3-ஐ இயக்குகிறது. இங்கு கிடைக்கும் குறைந்த மதிப்பை ஒரு முடிவாகக் கருதாமல், ஒரு கேள்வியாகக் கருதவும். ஏனெனில் பொது iperf3 server-கள் பகிரப்பட்டவை மற்றும் பெரும்பாலும் அதிக பயன்பாட்டில் இருப்பவை, எனவே மோசமான முடிவு அந்த server-ன் பக்கத்தில் இருக்கலாம்.

Geekbench பகுதி single core score மற்றும் multi core score ஆகியவற்றை வழங்குகிறது. ஒரு request, ஒரு compile அல்லது ஒரு query எவ்வளவு வேகமாக முடிகிறது என்பதை single core score கணிக்கிறது. உங்களிடம் உண்மையில் எத்தனை core-கள் உள்ளன என்பதை multi core score பெரும்பாலும் தெரிவிக்கும்.

Disk: fio-வை நீங்களே இயக்குதல்

fio (flexible IO tester) என்பது yabs disk பகுதியின் பின்னணியில் இயங்கும் கருவியாகும். இதை நேரடியாக இயக்கும்போதுதான், இதில் உள்ள flags-ன் உண்மையான பயன் உங்களுக்குப் புரியும்.

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

நீங்கள் பயன்படுத்தும் filesystem-ல், 32 queue depth கொண்ட 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

வெளியீட்டில் (output) கவனிக்க வேண்டிய சுருக்கமான வரி இதோ.

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

இதற்குக் கீழே fio ஒரு clat percentiles தொகுதியை அச்சிடும். இதில் 99.00th percentile மதிப்பைக் குறிப்பிடுவதுதான் சிறந்தது, ஏனெனில் நூறு கோரிக்கைகளில் மிக மெதுவான ஒரு கோரிக்கை எவ்வளவு நேரம் காத்திருந்தது என்பதை இது காட்டுகிறது. சராசரி latency (average latency) என்பது பயனர் உணரும் தாமதங்களை மறைத்துவிடும்.

• --direct=1 கோப்பை O_DIRECT முறையில் திறக்கிறது, இதனால் kernel page cache தவிர்க்கப்பட்டு நேரடியாக reads நடைபெறும். இது இல்லையென்றால், 8G RAM கொண்ட கணினியில் 2G கோப்பை இரண்டாவது முறை படிக்கும்போது, அது நினைவகத்திலிருந்து (memory) எடுக்கப்படும்; அப்போது fio மில்லியன் கணக்கான IOPS-ஐக் காட்டும். அந்த எண் உண்மையானதுதான், ஆனால் அது நினைவகத்தின் வேகத்தைக் குறிக்கும்.
• --ioengine=libaio asynchronous கோரிக்கைகளைச் சமர்ப்பிக்கிறது, இதுதான் --iodepth=32 மூலம் ஒரே நேரத்தில் 32 கோரிக்கைகளைச் செயல்படுத்த உதவுகிறது. psync போன்ற synchronous engine-ஐப் பயன்படுத்தினால், iodepth 1-க்கு மேல் இருந்தால் எந்த மாற்றமும் இருக்காது, எனவே ஒரு நேரத்தில் ஒரு கோரிக்கை மட்டுமே அளவிடப்படும்.
• --time_based --runtime=60 ஒரு குறிப்பிட்ட அளவு வேலைக்கு பதிலாக 60 வினாடிகள் வரை இயங்கும். இதனால் வேகமான மற்றும் மெதுவான disk-கள் ஒரே கால அளவில் சோதிக்கப்பட்டு, ஒப்பீடு சரியாக அமையும்.
• --size=2G சோதனைக்கான கோப்பின் அளவை அமைக்கிறது. இதை வழியில் உள்ள எந்த cache-ஐ விடவும் பெரியதாக வைத்திருங்கள், மேலும் போதுமான இடம் இருப்பதை முதலில் உறுதிப்படுத்திக் கொள்ளுங்கள்.

Random write சோதனைக்கும் இதே கட்டளையைப் பயன்படுத்தலாம், ஆனால் --rw=randwrite flag-ஐச் சேர்க்கவும். இதைத் தனித்தனியாக இயக்கிவிட்டு, பிறகு கோப்பை நீக்கிவிடவும்.

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

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

fio Unknown error -1 பிழையுடன் நின்றால்

அனைத்து filesystem-களிலும் Direct IO வசதி இருப்பதில்லை. Docker இயல்பாக container-க்கு வழங்கும் filesystem-ஆன overlay மற்றும் பல network filesystem-கள் 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-ஐ bind mounted volume போன்ற உண்மையான storage பாதையில் அமைக்கவும், அல்லது container-க்கு பதிலாக host-ல் fio-வை இயக்கவும். உண்மையான storage வசதி இல்லையென்றால், buffered synchronous முறையில் இயக்குவது கட்டளை சரியாக உள்ளதா என்பதை உறுதிப்படுத்தும்.

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

அந்த இயக்கத்தின் முடிவுகளைக் குறிப்பிடும்போது உண்மையாக இருக்கவும். முதல் முறை இயக்கிய பிறகு, 256M கோப்பு page cache-ல் தங்கிவிடும். எனவே, கிடைக்கும் IOPS அளவு உங்கள் RAM-ன் வேகத்தையே குறிக்கும். fio நிறுவப்பட்டுள்ளதா மற்றும் flags சரியாக உள்ளதா என்பதை உறுதிப்படுத்த மட்டுமே இதைப் பயன்படுத்தவும். இதை ஒருபோதும் disk-ன் செயல்திறன் முடிவாகக் குறிப்பிட வேண்டாம்.

dd ஏன் ஒரு disk benchmark கிடையாது

dd பல VPS விவாதங்களில் இடம்பெறுகிறது, இது ஒரு குறுகிய கேள்விக்கு மட்டுமே பதிலளிக்கிறது.

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

இது ஒரு thread மற்றும் ஒரு request-ஐக் கொண்டு sequential write throughput-ஐ அளவிடுகிறது. இது ஒரு அடிப்படைச் சோதனையாக (sanity check) மட்டுமே உதவும். இது random IO பற்றியோ அல்லது ஒரே நேரத்தில் 32 requests வரும்போது என்ன நடக்கும் என்பது பற்றியோ எதையும் கூறாது. oflag=direct-ஐ நீக்கினால், இது உங்கள் kernel எவ்வளவு வேகமாக memory-க்குள் write-களை ஏற்றுக்கொள்கிறது என்பதை மட்டுமே அளவிடும். இதனால்தான் 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-களையும் பயன்படுத்தி இயக்கவும்; இது உங்கள் vCPU-கள் தனித்தனி 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 முதலில் வரும். பழைய பதிவிலிருந்து --test=cpu கொண்ட கட்டளையை நகலெடுத்தால், உங்களுக்கு WARNING: the --test option is deprecated என்ற பிழை கிடைக்கும். sysbench 0.4 மற்றும் sysbench 1.0 ஆகியவற்றின் மதிப்பெண்களை ஒப்பிட முடியாது. எனவே, பதிப்பு எண் குறிப்பிடப்படாத எந்தவொரு வெளியீட்டு மதிப்பெண்ணுடனும் உங்கள் முடிவுகளை ஒப்பிட வேண்டாம்.

நினைவகம்: 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-ல் அமையும். அனைத்து கணினிகளிலும் எழுதுவதை விட வாசிப்பு (reads) வேகமாகவே இருக்கும். --memory-block-size-ஐ 1M அளவில் வைத்திருக்கவும்; நீங்கள் ஒப்பிடும் அனைத்து host-களிலும் இதை ஒரே மாதிரியாகப் பராமரிக்கவும். 1K அளவில் இந்த எண் சரிந்துவிடும். ஏனெனில், ஒவ்வொரு செயல்பாட்டிற்கும் ஏற்படும் கூடுதல் சுமை (overhead) ஆயிரம் மடங்கு அதிகரிக்கிறது. இதனால், நினைவக அலைவரிசைக்கு (memory bandwidth) பதிலாக, loop-ன் செலவையே நீங்கள் அளவிடுகிறீர்கள். வெளியிடப்படும் நினைவக செயல்திறன் மதிப்பெண்களில் (memory scores), தவறாகப் பயன்படுத்தப்படும் மிக முக்கியமான flag இதுவாகும்.

Network: iperf3

throughput-ஐச் சோதிக்க மிகவும் நம்பகமான வழி, உங்கள் கட்டுப்பாட்டில் உள்ள மற்றொரு machine-ஐப் பயன்படுத்துவதாகும். அப்போதுதான் இரு முனைகளிலும் என்ன நடக்கிறது என்பது உங்களுக்குத் தெரியும்.

தொலைதூர முனையில் (far end):

iperf3 -s

இது TCP 5201 port-ல் listening நிலையில் இருக்கும். நீங்கள் சோதனையை மேற்கொள்ளும் முகவரிக்கு (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

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

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

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

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

[
  {
    "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-ல், ஒவ்வொரு கோரிக்கையும் வட்டை அடைவதற்கு முன்பு network வழியாகச் செல்வதால், அது 12,000 அளவிற்கு அருகில் இருக்கும். ஒரு spinning disk, ஒவ்வொரு random கோரிக்கைக்கும் அதன் physical head-ஐ நகர்த்த வேண்டியிருப்பதால், தோராயமாக 180 அளவை மட்டுமே கையாளும்.

இவை ஒவ்வொரு வகை சேமிப்பகத்திற்கும் வெளியிடப்பட்ட பொதுவான புள்ளிவிவரங்கள்; ஒரே host-லிருந்து எடுக்கப்பட்ட அளவீடுகள் அல்ல. உங்கள் சொந்த முடிவு சரியான வரிசையில் (order of magnitude) உள்ளதா என்பதைச் சரிபார்க்க மட்டுமே இவற்றை பயன்படுத்தவும். NVMe என்று விற்கப்படும் ஒரு திட்டம் 4k IOPS-ல் சில ஆயிரங்களை மட்டுமே காட்டினால், முதலில் --direct=1 இயக்கப்பட்டிருப்பதை உறுதி செய்யவும். அது இயக்கப்பட்டிருந்தும் இந்த நிலை இருந்தால், ஒன்று அந்தச் சேமிப்பகம் தயாரிப்பு பக்கத்தில் விவரிக்கப்பட்டபடி இல்லை, அல்லது நீங்கள் அதை மிகவும் பிஸியான ஒரு அண்டை பயனருடன் (busy neighbour) பகிர்ந்து கொள்கிறீர்கள் என்று அர்த்தம்.

ஒரு முறை மட்டும் இயக்கும் சோதனை ஏன் அளவுகோலாகாது

ஒரே ஒரு முடிவு என்பது பகிரப்பட்ட machine-ல் ஒரு நிமிடத்தின் நிலையை மட்டுமே குறிக்கும். இதை ஒரு மாதிரியாக மட்டுமே கருத வேண்டும்.

• ஒவ்வொரு சோதனையையும் குறைந்தது ஐந்து முறை இயக்கவும். வெவ்வேறு நேரங்களிலும், குறைந்தது இரண்டு நாட்களிலும் சோதனைகளை மேற்கொள்ளவும். அதன் median மதிப்பையும், பரவலையும் (spread) குறித்துக் கொள்ளவும். பரவல் குறிப்பிடப்படாத முடிவு என்பது ஒரு சந்தைப்படுத்தல் புள்ளிவிவரம் மட்டுமே.
• ஒவ்வொரு முறை இயக்கும்போதும் steal time-ஐப் பதிவு செய்யவும். st அதிகமாக இருந்த சோதனைகளைத் தவிர்க்கவும், அல்லது குறைந்தபட்சம் அதைக் குறித்து வைக்கவும்.
• disk சோதனையை இரண்டு கால அளவுகளில் இயக்கவும். பல திட்டங்கள் burst IOPS வசதியை வழங்குகின்றன, இது காலப்போக்கில் மீண்டும் நிரம்பும். எனவே, 60 வினாடி fio சோதனை burst அளவை மட்டுமே காட்டும், ஆனால் --runtime=600 அதன் குறைந்தபட்ச நிலையான அளவை (floor) காட்டும். மோசமான நாட்களில் உங்களுக்குக் கிடைக்கும் செயல்திறன் இதுவே.
• வேறு எந்தச் செயலியும் இயங்கவில்லை என்பதை உறுதிப்படுத்தவும். 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-ல் 4 நிமிடங்களும், மற்றொன்றில் 7 நிமிடங்களும் எடுக்கும் build, Geekbench என்ன சொன்னாலும் அந்த விவாதத்தை முடிவுக்குக் கொண்டுவரும். மேலும், எப்போது அதிக திறன் கொண்ட இயந்திரத்திற்குப் பணம் செலுத்துவது தேவையற்றது என்பதையும் இந்த அளவீடுதான் உங்களுக்குத் தெரிவிக்கும். ஒரு VPS-ன் மாதந்திர உண்மையான செலவு என்ன என்பதைப் படிப்பதற்கு முன்போ அல்லது பணிச்சுமையை dedicated server-க்கு மாற்றுவதற்கு முன்போ இதைத் தெரிந்துகொள்வது அவசியம்.

FAQ

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

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

fio ஏன் மில்லியன் கணக்கான IOPS-ஐக் காட்டுகிறது?

பெரும்பாலான நேரங்களில் --direct=1 விடுபட்டிருப்பதே இதற்குக் காரணம். அது இல்லையெனில், fio kernel page cache வழியாக வாசிக்கும். எனவே, முதல் முறைக்கு பிறகு 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 .-ஐ இயக்கவும். Type-ன் overlay, O_DIRECT-ஐ ஆதரிக்காது. எனவே, உண்மையான storage-ஐ நோக்கி சோதனையைச் சுட்டிக்காட்டவும்.

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

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

எனது application-ன் வேகத்தை எந்த ஒற்றை எண் சரியாகக் கணிக்கும்?

பெரும்பாலான web மற்றும் database workloads-க்கு, single core CPU வேகம் மற்றும் 4k random read latency ஆகியவையே முக்கியம். Throughput எண்கள் பார்ப்பதற்கு ஈர்க்கக்கூடியதாக இருந்தாலும், அவை எதையும் தீர்மானிப்பதில்லை, ஏனெனில் ஒரு சாதாரண request சிறியதாகவே இருக்கும். சராசரி மதிப்பை விட, fio clat percentiles block-ல் உள்ள 99th percentile மதிப்பை கவனிக்கவும். ஏனெனில், நூறு requests-ல் மெதுவாகச் செல்லும் அந்த ஒரு request-ஐத்தான் பயனர் உணர்வார்.

benchmark செய்வதற்கு முன் நான் எதையாவது நிறுவ வேண்டுமா?

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