SSD Nodes Learn Hosting plans →
கல்வி வழிகாட்டிகள் Matt Connorஆல் Matt Connor

VPS benchmark செய்வது எப்படி: yabs.sh, fio, sysbench

VPS-ஐச் சரியாக அளவிட yabs.sh-ஐ முதலில் இயக்கி, பின்னர் fio, sysbench, iperf3-ஐத் தனித்தனியாகச் சோதியுங்கள். ஒரே run ஏன் போதாது என்பதையும் அறியுங்கள்.

Verified Every command ran end-to-end on a fresh Ubuntu 24.04 server, July 30, 2026.

VPS-ஐ benchmark செய்வது என்றால் என்ன

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

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

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

ஒவ்வொரு தவறான தரப்படுத்தல் (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 மெய்நிகராக்கத்தைக் குறிக்கிறது: இதில் நீங்கள் host kernel-ஐப் பகிர்ந்து கொள்கிறீர்கள், மேலும் உங்கள் CPU மற்றும் memory வரம்புகள் மெய்நிகர் வன்பொருளுக்குப் பதிலாக cgroup (control group) அமைப்புகளாக இருக்கும். ஒரு cgroup v2 அமைப்பில், உங்கள் container-ன் cgroup-லிருந்து CPU வரம்பை நீங்கள் படிக்கலாம்; அந்த cgroup /sys/fs/cgroup-ல் mount செய்யப்பட்டிருக்கும்போது பின்வரும் பாதை பொருந்தும்.

cat /sys/fs/cgroup/cpu.max

max 100000 என்பது இந்த cgroup-க்கு என்று தனியாக ஒதுக்கீடு (quota) இல்லை என்பதைக் குறிக்கிறது; இருப்பினும், முந்தைய (ancestor) cgroup-கள் வரம்புகளை விதிக்கலாம். 200000 100000 என்பது ஒவ்வொரு 100000 மைக்ரோ விநாடி காலத்திலும் நீங்கள் 200000 மைக்ரோ விநாடி CPU-வைப் பயன்படுத்தலாம் என்பதைக் குறிக்கிறது, இது இரண்டு cores-க்கான ஒதுக்கீட்டிற்குச் சமம். 4 vCPU என்று விளம்பரப்படுத்தப்பட்ட ஒரு திட்டம், இரண்டு cores ஒதுக்கீட்டைக் கொண்டிருந்தால், அது ஒருபோதும் நான்கு cores-க்கு இணையான செயல்திறனைத் தராது. தரப்படுத்தல் கருவிகள் (benchmark tools) இந்த கட்டுப்பாட்டை அடையாளம் காண முடியும்: VoxelBench, CPU ஒதுக்கீடுகளைப் புகாரளிக்கிறது மற்றும் host இயந்திரம் வழங்கக்கூடிய மொத்த CPU-களை விட, server பயன்படுத்தக்கூடிய CPU குறைவாக இருக்கும்போது, அது பகிரப்பட்ட அல்லது கட்டுப்படுத்தப்பட்ட (throttled) CPU என்று கொடியிடுகிறது (flags).

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

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

Steal time என்பது உங்கள் virtual CPU, hypervisor-ஆல் திட்டமிடப்படாமல் (schedule) கட்டாயமாக காத்திருந்த நேரத்தின் பங்காகும். இது கிடைக்காத CPU நேரத்தைக் குறிக்கும் ஒரு பயனுள்ள சமிக்ஞையாகும், ஆனால் இது busy neighbours-ஆல் ஏற்பட்டதா அல்லது provider உங்கள் CPU quota-வை அமல்படுத்துவதால் ஏற்பட்டதா என்பதை வேறுபடுத்திக் காட்டாது.

vmstat 1 10

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

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

yabs.sh (Yet Another Bench Script) என்பது fio, iperf3 மற்றும் Geekbench ஆகியவற்றை இயக்கி, ஒரு சுருக்கமான அறிக்கையை வழங்கும் shell script ஆகும். இவை ஏற்கனவே நிறுவப்பட்டிருந்தால், அந்த script அவற்றைப் பயன்படுத்தும்; இல்லையெனில், static binaries-ஐத் தரவிறக்கம் செய்து கொள்ளும். 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 disk சோதனையைத் தவிர்க்கும், -i network சோதனையைத் தவிர்க்கும், -g Geekbench-ஐத் தவிர்க்கும், -r iperf3 இடங்களை மூன்றாகக் குறைக்கும், -j முடிவுகளை JSON வடிவில் அச்சிடும், மற்றும் -w results.json அந்த JSON-ஐ ஒரு கோப்பில் எழுதும்.

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

முதல்முறை இயக்கும் முன் இரண்டு விஷயங்களை அறிந்து கொள்ள வேண்டும். Geekbench உங்கள் முடிவுகளைப் பதிவேற்றி, public browser.geekbench.com URL-ஐ வழங்கும்; எனவே அந்த link-ஐ வைத்திருக்கும் எவரும் உங்கள் CPU மாதிரி மற்றும் மதிப்பெண்களைப் பார்க்க முடியும். -g அந்தச் சோதனையை முழுமையாகத் தவிர்க்கும். இரண்டாவதாக, iperf3 நிலை பல்வேறு பிராந்தியங்களில் உள்ள server-களுக்கு உண்மையான traffic-ஐ அனுப்பும், இது உங்கள் மாதந்திர bandwidth ஒதுக்கீட்டைக் குறைக்கும். 1 Gbit/s இணைப்பில், முழுமையான network சோதனையானது பல 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 உடன் நின்றுவிட்டால்

Direct IO எல்லா filesystem-களிலும் கிடைக்காது. எனவே, --direct=1 அமைக்கப்பட்டிருக்கும்போது fio முதல் கோரிக்கையிலேயே தோல்வியடைந்தால், முதலில் Direct IO-வைச் சோதிக்க வேண்டும். இந்தத் தோல்வி பின்வருமாறு இருக்கலாம்:

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 .-ஐ இயக்கவும். Docker இயல்பாக container-க்கு வழங்கும் filesystem ஆன overlay-ன் Type, தானாகவே இந்தத் தோல்விக்குக் காரணமாகாது. overlayfs, O_DIRECT-ஐ அதன் கீழ் உள்ள filesystem-க்குக் கடத்தும்; அந்த filesystem-ஆல் Direct IO செய்ய முடியாவிட்டால் மட்டுமே அது மறுக்கும். எனவே, ext4 அல்லது xfs மீதுள்ள overlay-ல் --direct=1 --ioengine=libaio வேலை செய்யும். சோதனை செய்யப்படும் கோப்பின் கீழ் உள்ள filesystem-ஆல் உண்மையில் Direct IO செய்ய முடியாவிட்டால், கோப்பைத் திறக்கும்போதே fio வழக்கமாக இவ்வாறு தெரிவிக்கும்: fio: looks like your file system does not support direct=1/buffered=0. அத்தகைய சூழலில், bind mounted volume போன்ற உண்மையான local storage-ல் உள்ள ஒரு பாதையை --filename-க்குக் குறிப்பிடவும் அல்லது container-க்கு உள்ளே இயக்காமல் host-லேயே fio-வை இயக்கவும். உண்மையான storage கிடைக்கவில்லை என்றால், buffered synchronous முறையில் இயக்குவது, அந்த 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

அந்த இயக்கம் எதைக் குறிக்கிறது என்பதில் தெளிவாக இருக்கவும். முதல் முறை இயக்கிய பிறகு, 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-ஐ நீக்கினால், writes அனைத்தும் page cache வழியாகச் செல்லும், ஆனால் conv=fdatasync இன்னும் கட்டளையை முடிப்பதற்கு முன்பே output தரவை storage-க்கு அனுப்பும். அதையும் நீக்கிவிட்டால், உங்கள் 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-களில் throughput எவ்வாறு அமைகிறது என்பதைக் காட்டும்.

இது எதை அளவிடுகிறது என்பதில் தெளிவாக இருக்கவும்: sysbench cpu என்பது trial division முறை மூலம் மீண்டும் மீண்டும் prime numbers-ஐக் கண்டறியும். ஒவ்வொரு candidate-க்கும் இது double precision square root-ஐ எடுத்து, பின் 64 bit integer modulo மூலம் divisors-ஐச் சோதிக்கும். ஒவ்வொரு divisor-ஐயும் அந்த floating point limit-உடன் ஒப்பிடும். எனவே, இது integer மற்றும் floating point வேலைகளைக் கலந்தே செய்கிறது. இது memory bandwidth, vector units அல்லது cache-ஐ எந்த வகையிலும் ஒரு நிஜமான workload-ஐப் போல அழுத்தம் தருவதில்லை. எனவே, இரண்டு hosts-களைத் தரவரிசைப்படுத்த இது உதவும், ஆனால் உங்கள் application எவ்வாறு இயங்கும் என்பதை முன்கூட்டியே கணிக்க இது உதவாது.

Ubuntu 24.04-ல் sysbench 1.0.20 உள்ளது, இதில் test பெயர் முதலில் வரும். பழைய பதிவுகளில் உள்ள --test=cpu கட்டளையை அப்படியே நகலெடுத்தால், உங்களுக்கு WARNING: the --test option is deprecated என்ற பிழை கிடைக்கும். sysbench 0.4 மற்றும் sysbench 1.0 ஆகியவற்றின் மதிப்பெண்களை ஒப்பிட முடியாது. எனவே, பதிப்பின் பெயர் குறிப்பிடப்படாத எந்தவொரு பொதுவான அளவீட்டுடனும் உங்கள் முடிவுகளை ஒப்பிட வேண்டாம்.

Memory: 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 ஆயிரம் மடங்கு அதிகமாகிறது; இதனால் நீங்கள் memory bandwidth-ஐ அளவிடுவதற்குப் பதிலாக loop-ன் செலவையே அளவிடுகிறீர்கள். வெளியிடப்பட்ட memory மதிப்பெண்களில் தவறாகப் பயன்படுத்தப்படும் மிக முக்கியமான 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 தரவு பரிமாற்றப்படும்; ஒவ்வொரு திசையிலும் இதை நீங்கள் பலமுறை இயக்க வேண்டியிருக்கும்.

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

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

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

ஏன் ஒரு முறை மட்டும் இயக்கும் சோதனை benchmark ஆகாது

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

  • ஒவ்வொரு சோதனையையும் குறைந்தது ஐந்து முறை இயக்கவும்; வெவ்வேறு நேரங்களிலும், குறைந்தது இரண்டு நாட்களிலும் இதைச் செய்யவும். அதன் median மதிப்பையும், பரவலையும் (spread) குறித்துக் கொள்ளவும். பரவல் குறிப்பிடப்படாத முடிவு என்பது ஒரு marketing புள்ளிவிவரம் மட்டுமே.
  • ஒவ்வொரு முறை இயக்கும்போதும் steal time-ஐப் பதிவு செய்யவும். st அதிகமாக இருக்கும் சோதனைகளைத் தக்கவைத்து, அவை resource contention-ஆ அல்லது plan-ன் CPU quota-வா என்பதை ஆராயவும்; அவற்றை நீக்குவது உங்களுக்குக் கிடைக்கும் உண்மையான செயல்திறனை மறைத்துவிடும்.
  • disk சோதனையை இரண்டு கால அளவுகளில் இயக்கவும். பல plans ஒரு குறிப்பிட்ட burst IOPS அளவை வழங்குகின்றன, அது காலப்போக்கில் மீண்டும் நிரம்பும். ஆனால் 60 வினாடி fio சோதனை அல்லது --runtime=600 ஆகிய எதுவுமே நீங்கள் குறைந்தபட்ச செயல்திறனை (floor) அளந்துவிட்டீர்கள் என்பதற்கு உத்தரவாதம் அளிக்காது. AWS gp2 credits முழு இருப்பு இருக்கும்போது குறைந்தது 30 நிமிடங்களுக்கு 3,000 IOPS-ஐத் தக்கவைக்க முடியும், எனவே இரண்டு சோதனைகளுமே burst செயல்திறனை மட்டுமே அளவிடக்கூடும். provider-ன் credit மாதிரியைச் சரிபார்த்து, ஒரு முடிவை sustained performance என்று அழைக்கும் முன் credit balance-ஐக் கண்காணிக்கவும்.
  • வேறு எந்தச் செயலியும் இயங்கவில்லை என்பதை உறுதிப்படுத்தவும். CPU சோதனையின் நடுவில் unattended-upgrades ஒரு apt transaction-ஐத் தொடங்குவது உங்கள் மதிப்பெண்களைக் குறைக்கும், மேலும் ஒவ்வொரு சோதனைக்கு முன்பும் ps -e -o comm= | grep -E 'apt|dpkg' செய்வது ஒரு வினாடியை எடுத்துக்கொள்ளும்.
  • ஒரு நேரத்தில் ஒரு மாறியை (variable) மட்டும் மாற்றவும். வெவ்வேறு tool பதிப்புகள், block sizes அல்லது thread counts மூலம் கிடைக்கும் எண்களை, அவை பார்ப்பதற்கு ஒரே மாதிரியாக இருந்தாலும், ஒப்பிட முடியாது.

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

உங்கள் சொந்த பணிச்சுமையை கடைசியாக அளவிடுங்கள்

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

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 என்பது கிடைக்காத CPU நேரத்தைப் பதிவு செய்கிறது; இது உங்கள் host-ல் உள்ள நெரிசலையும், நீங்கள் வாங்கிய CPU ஒதுக்கீட்டை provider அமல்படுத்துவதையும் குறிக்கலாம். 5%-க்கு மேல் உள்ள மதிப்பு எதனால் ஏற்படுகிறது என்பதை மட்டும் உறுதிப்படுத்தாது. இதற்குத் தீர்வு, tuning செய்வதை விட முறையான அணுகுமுறையே. ஒவ்வொரு சோதனையையும் வெவ்வேறு நேரங்களில் ஐந்து அல்லது அதற்கு மேற்பட்ட முறை இயக்கி, அதன் median மதிப்பையும் பரவலையும் (spread) அறிக்கையாகத் தரவும்.

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

பெரும்பாலும் --direct=1 விடுபட்டிருப்பதே இதற்குக் காரணம். அது இல்லாமல், fio kernel page cache வழியாக வாசிக்கும். எனவே, முதல் முறைக்கு பிறகு 2G test file RAM-லிருந்து வழங்கப்படும்; நீங்கள் அளவிடுவது memory bandwidth-ஐ மட்டுமே. --direct=1-ஐச் சேர்த்து, test file-ஐ எந்தவொரு cache-ஐ விடவும் பெரியதாக வைத்திருக்கவும். ஒருவேளை --direct=1 தோல்வியடைந்தால், df -hT .-ஐ இயக்கி, test file எங்கே அமைந்துள்ளது என்று பார்க்கவும். ஒரு overlay வகை மட்டும் சிக்கலாகாது, ஏனெனில் overlayfs O_DIRECT-ஐ அடிப்படையிலுள்ள storage-க்கு அப்படியே கடத்தும். அடிப்படையிலுள்ள filesystem direct IO-வை மறுத்தால் மட்டுமே, test file-ஐ உண்மையான local storage-க்கு மாற்றவும்.

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

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

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

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

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

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

இந்தக் கட்டுரை பயனுள்ளதாக இருந்ததா?

#benchmarks#fio#sysbench#yabs#iperf3#vps-performance