VPS పనితీరును సరిగ్గా ఎలా పరీక్షించాలి

VPS పనితీరు పరీక్ష చేయడం అంటే ఏమిటి

VPS పనితీరు పరీక్షలో నాలుగు అంశాలను కొలుస్తారు: ఒక CPU core ఎంత వేగంగా పనిచేస్తుందో, యంత్రానికి ఎంత memory bandwidth ఉందో, storage ప్రతి సెకనుకు ఎన్ని చిన్న random disk operations నిర్వహించగలదో, అలాగే network link ఎంత throughput అందిస్తుందో. yabs.sh ను ఒక్కసారి అమలు చేస్తే సుమారు పది నిమిషాల్లో ఈ నాలుగు కొలతలు లభిస్తాయి. ఫలితాన్ని అర్థం చేసుకోవడం కష్టమైన భాగం. VPS (virtual private server) ఇతర 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 అంటే పూర్తి virtualisation. అందువల్ల మీరు మీ స్వంత kernelను నడుపుతారు. systemd-detect-virtలో lxc లేదా openvz ముద్రితమైతే, అది container virtualisation అని అర్థం. ఈ సందర్భంలో మీరు host kernelను పంచుకుంటారు. మీ CPU మరియు memory పరిమితులు virtual hardwareకు బదులుగా cgroup (control group) settingsగా ఉంటాయి. cgroup v2 systemలో CPU పరిమితిని నేరుగా చదవవచ్చు.

cat /sys/fs/cgroup/cpu.max

max 100000 అంటే quota లేదని అర్థం. 200000 100000 అంటే ప్రతి 200000 100000-microsecond periodలో 200000 microseconds CPUను ఉపయోగించవచ్చు. ఇది రెండు coresకు సమానమైన quota. రెండు cores quota ఉన్న planను 4 vCPUగా ప్రకటించినా, అది ఎప్పటికీ నాలుగు coresల మాదిరిగా score సాధించదు. దీనికి కారణాన్ని ఏ benchmark tool కూడా తెలియజేసే lineను ముద్రించదు.

df -hT / వేరే కారణంతో ముఖ్యమైనది: Type column. అందులో overlay కనిపిస్తే, మీరు containerలో ఉన్నారు. అప్పుడు దిగువ disk testలో మార్పు చేయాలి. దీన్ని ఇప్పుడే గుర్తుంచుకోండి.

ఎల్లప్పుడూ steal time ను పర్యవేక్షించండి

steal time అంటే మీ virtual CPU అమలు కావడానికి సిద్ధంగా ఉన్న సమయంలో, hypervisor భౌతిక core ను మరొకరికి కేటాయించిన భాగం. ఫలితం hardware వల్ల కాకుండా మీ పొరుగు virtual machineల వల్ల వచ్చిందో తెలుసుకోవడానికి ఇది అత్యంత ఉపయోగకరమైన ఒకే signal.

vmstat 1 10

కుడివైపు ఉన్న st column ను చూడండి. నిరంతరం 0 లేదా 1 ఉండటం సాధారణం. 5 కంటే ఎక్కువ విలువలు కొనసాగితే, ఆ సమయంలో host పై వనరుల కేటాయింపు అధికంగా ఉందని అర్థం. అందువల్ల ఆ సమయంలో మీరు నమోదు చేసే ప్రతి CPU సంఖ్య మీ machine లోపం లేకుండానే తక్కువగా ఉంటుంది. top, CPU line లోని %st చూపించే అదే విలువను చూపిస్తుంది. మీరు benchmark నడుపుతున్నప్పుడు, రెండవ SSH session లో vmstat 1 ను నడుస్తూనే ఉంచండి. ప్రతి ఫలితం పక్కన steal విలువను నమోదు చేయండి.

yabs.shతో ప్రారంభించండి

yabs.sh (Yet Another Bench Script) అనేది static fio, iperf3 మరియు Geekbench binariesను download చేసి, వాటిని అమలు చేసి, ఒకే summaryను ముద్రించే shell script. VPS benchmark చర్చల్లో ఇది సాధారణంగా ఉపయోగించే విధానం. అందువల్ల, yabs outputను ఉపయోగించడం ద్వారా మరొకరితో benchmark ఫలితాలను అత్యంత వేగంగా పోల్చవచ్చు.

ప్రాజెక్ట్ అందించే ఒక-లైన్ రూపం ఇది.

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 చేస్తున్నప్పుడు flagsను -s -- తర్వాత ఉంచండి. Local copyను అమలు చేస్తున్నప్పుడు వాటిని filename తర్వాత నేరుగా ఉంచండి. ఉపయోగకరమైన flags ఇవి: -f disk testను దాటవేస్తుంది, -i network testను దాటవేస్తుంది, -g Geekbenchను దాటవేస్తుంది, -r iperf3 locationsను రెండుకు పరిమితం చేస్తుంది, -j resultsను JSONగా ముద్రిస్తుంది, మరియు -w results.json ఆ JSONను ఒక fileలో రాస్తుంది.

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

మొదటి runకు ముందు రెండు విషయాలు తెలుసుకోండి. 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లో tens of gigabytes వరకు traffic వెళ్లవచ్చు. కాబట్టి allowance తక్కువగా ఉంటే -rను, metered linkపై ఉంటే -iను ఉపయోగించండి.

yabs అవుట్‌పుట్‌లోని ప్రతి భాగం అర్థం

డిస్క్ విభాగం నాలుగు block sizeలలో 50/50 read మరియు write మిశ్రమంతో fioను అమలు చేస్తుంది: 4k, 64k, 512k మరియు 1m. ప్రతి block sizeకు IOPS (input/output operations per second) మరియు bandwidthను ఇది నివేదిస్తుంది. database, mail server లేదా అనేక చిన్న writes చేసే ఏదైనా వ్యవస్థకు 4k వరుస ముఖ్యమైనది. కారణం, చాలా server IO చిన్నదిగా మరియు చెల్లాచెదురుగా ఉంటుంది. backups మరియు video కోసం 1m వరుస ఉపయోగకరంగా ఉంటుంది. ఈ సందర్భాల్లో వరుసగా ఉన్న పెద్ద byte సమూహాలను తరలిస్తారు.

నెట్‌వర్క్ విభాగం పలు ప్రాంతాల్లోని public serversకు iperf3ను అమలు చేస్తుంది. ఇది రెండు దిశల్లో parallel streamsను ఉపయోగిస్తుంది. ఇక్కడ తక్కువ సంఖ్యను తుది సమాధానంగా కాకుండా పరిశీలించాల్సిన సూచనగా చూడండి. public iperf3 servers భాగస్వామ్యంగా ఉపయోగించబడతాయి మరియు తరచుగా saturationకు చేరుకుంటాయి. అందువల్ల తక్కువ ఫలితానికి కారణం దూర ప్రాంతంలోని server కావచ్చు.

Geekbench విభాగం single core score మరియు multi core scoreను ఇస్తుంది. ఒక request, ఒక compile లేదా ఒక query ఎంత వేగంగా పూర్తవుతుందో single core score సూచిస్తుంది. మీకు వాస్తవంగా ఎన్ని cores లభించాయో multi core score ప్రధానంగా తెలియజేస్తుంది.

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 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

అవుట్‌పుట్‌లో చదవాల్సిన summary line ఇలా ఉంటుంది.

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

దాని కింద fio ఒక clat percentiles blockను ముద్రిస్తుంది. 99.00th percentile విలువను ప్రస్తావించాలి. ఎందుకంటే 100 requestsలో నెమ్మదిగా పూర్తైన ఒక request ఎంతసేపు వేచి ఉందో అది చూపిస్తుంది. Average latency వల్ల వినియోగదారు గమనించే stalls స్పష్టంగా కనిపించవు.

• --direct=1 ఫైల్‌ను O_DIRECTతో తెరుస్తుంది. అందువల్ల reads, kernel page cacheను దాటిపోతాయి. ఇది లేకపోతే, 8G RAM ఉన్న machineలో 2G ఫైల్‌పై రెండో pass memory నుంచే అందించబడుతుంది. అప్పుడు fio IOPSను millionsలో report చేస్తుంది. ఆ సంఖ్య నిజమే, కానీ అది memory సంఖ్య.
• --ioengine=libaio asynchronous requestsను submit చేస్తుంది. అందువల్ల --iodepth=32 requestsలో 32ను in flightగా ఉంచగలదు. psync వంటి synchronous engineతో iodepth 1 కంటే ఎక్కువగా ఉన్నా ఎలాంటి ప్రభావం ఉండదు. కాబట్టి మీరు ఒకేసారి ఒక requestను మాత్రమే కొలుస్తారు.
• --time_based --runtime=60 స్థిరమైన work amountకు బదులుగా 60 seconds పాటు run అవుతుంది. అందువల్ల fast disk మరియు slow diskకు ఒకే wall clock సమయం ఉంటుంది, comparison నిష్పక్షపాతంగా ఉంటుంది.
• --size=2G test file sizeను నిర్దేశిస్తుంది. Pathలోని ఏ cache కంటే ఇది పెద్దదిగా ఉండాలి. ముందుగా free space ఉందో తనిఖీ చేయండి.

Random write కోసం అదే commandను --rw=randwriteతో ఉపయోగించండి. దీన్ని విడిగా run చేసి, ఆపై 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

నిజమైన trafficకు మరింత దగ్గరైన mix కోసం --rw=randrw --rwmixread=70ను ఉపయోగించండి. మీరు ఉపయోగిస్తున్న storage class ఈ ఫలితాలను ఏ flagకన్నా ఎక్కువగా మార్చుతుంది. ఆ తేడా VPSలో NVMe మరియు SATA SSD storage మధ్య తేడాలో వివరించబడింది.

fio Unknown error -1తో ఆగినప్పుడు

ప్రతి filesystemలో Direct IO అందుబాటులో ఉండదు. overlay, Docker డిఫాల్ట్‌గా containerకు ఇచ్చే filesystem, అలాగే అనేక network filesystems O_DIRECTకు మద్దతు ఇవ్వవు. అందువల్ల libaio kernel పూర్తి చేయలేని requestను submit చేస్తుంది, మరియు 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 డిస్క్ బెంచ్‌మార్క్ ఎందుకు కాదు

dd అనేక VPS చర్చల్లో కనిపిస్తుంది. ఇది ఒక పరిమిత ప్రశ్నకు మాత్రమే సమాధానం ఇస్తుంది.

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 writes‌ను memoryలోకి ఎంత వేగంగా స్వీకరిస్తుందో ప్రధానంగా కొలుస్తుంది. అందుకే 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 అభ్యర్థన పూర్తవడానికి లేదా ఒక compile పని పూర్తవడానికి పట్టే వేగాన్ని నిర్ణయించే సంఖ్య ఇదే. ఒకే ధరలోని hosts మధ్య ఇది ఎక్కువగా మారుతుంది. తర్వాత అన్ని threadsతో అమలు చేయండి. దీని ద్వారా మీ vCPUs వేర్వేరు coresనా, లేక ఒక coreను పంచుకునే slicesనా అనేది తెలుస్తుంది.

ఈ పరీక్ష ఏమి కొలుస్తుందో స్పష్టంగా తెలుసుకోండి: sysbench cpu, 64 bit integer arithmetic ఉపయోగించి prime numbersను పదేపదే కనుగొంటుంది. ఇది memory bandwidth, vector units లేదా cacheను వాస్తవ workloadను పోలిన విధంగా stress చేయదు. అందువల్ల రెండు hostsను ర్యాంక్ చేయడానికి ఇది ఉపయోగకరం. కానీ మీ application ఎలా నడుస్తుందో అంచనా వేయడానికి ఇది సరైనది కాదు.

Ubuntu 24.04, test name మొదట వచ్చే sysbench 1.0.20ను అందిస్తుంది. పాత postలోని --test=cpuతో commandను copy చేస్తే WARNING: the --test option is deprecated వస్తుంది. sysbench 0.4 మరియు sysbench 1.0 స్కోర్లు ఏమాత్రం పోల్చదగినవి కావు. అందువల్ల 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 వద్ద సంఖ్య తీవ్రంగా పడిపోతుంది. ప్రతి ఆపరేషన్‌కు అయ్యే overheadను వెయ్యి రెట్లు ఎక్కువసార్లు చెల్లించాల్సి వస్తుంది. అందువల్ల మెమరీ bandwidthకు బదులుగా loop ఖర్చును కొలుస్తారు. ప్రచురించిన memory స్కోర్‌లలో ఎక్కువగా సరిపోలని flag ఇదే.

Network: iperf3

Throughputను పరీక్షించడానికి సరైన విధానం, మీరు నియంత్రించే రెండవ యంత్రంతో పరీక్షించడం. అప్పుడు రెండు చివరల్లో ఏమి జరుగుతుందో మీకు తెలుస్తుంది.

అవతలి చివరలో:

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

మొదటి command పరీక్షిస్తున్న యంత్రం నుంచి uploadను కొలుస్తుంది. -R దిశను తిప్పుతుంది. దీంతో download కొలుస్తారు. -P 8 ఎనిమిది parallel streamsను ప్రారంభిస్తుంది.

Single stream మరియు parallel version రెండింటినీ అమలు చేయండి. అవి వేర్వేరు ప్రశ్నలకు సమాధానం ఇస్తాయి. ఒక TCP connection, దాని window అనుమతించేంత unacknowledged dataను మాత్రమే కలిగి ఉంటుంది. అందువల్ల దాని గరిష్ఠ వేగం సుమారుగా window sizeను round trip timeతో భాగించిన విలువగా ఉంటుంది. Latency 80 msగా, window 4 MBగా ఉంటే, అంతర్గత link ఎంత వేగంగా ఉన్నా, ఆ గరిష్ఠ వేగం సుమారు 400 Mbit/s మాత్రమే. Single stream ఫలితం ఒక downloadకు లభించే వేగాన్ని తెలియజేస్తుంది. Parallel ఫలితం link సామర్థ్యాన్ని తెలియజేస్తుంది.

ఈ పరీక్షలు నిర్వహిస్తున్నప్పుడు మీ 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లో చేసిన measurements కావు. వీటిని ఒకే ఉద్దేశంతో ఉపయోగించండి: మీ స్వంత ఫలితం సరైన order of magnitudeలో ఉందో తనిఖీ చేయడానికి. NVMeగా విక్రయించిన planలో 4k IOPS తక్కువ వేలల్లో వస్తే, ముందుగా --direct=1 ఆన్‌లో ఉందో నిర్ధారించండి. అది ఆన్‌లో ఉంటే, storage product pageలో వివరించినదిగా లేదేమో, లేదా మీరు చాలా బిజీగా ఉన్న neighbourతో దాన్ని share చేస్తున్నారేమో.

ఒక్కసారి నిర్వహించిన పరీక్ష benchmark కాదు

ఒక్క ఫలితం shared machineపై ఒక నిమిషానికి సంబంధించిన snapshot మాత్రమే. దాన్ని ఒక sampleగా పరిగణించండి.

• ప్రతి పరీక్షను కనీసం ఐదుసార్లు నిర్వహించండి. వాటిని వేర్వేరు గంటల్లో, కనీసం రెండు వేర్వేరు రోజుల్లో విభజించండి. median మరియు spreadను ఉంచండి. spread లేకుండా ప్రచురించిన ఫలితం marketing figure మాత్రమే.
• ప్రతి run పక్కన steal timeను నమోదు చేయండి. st ఎక్కువగా ఉన్న runలను తొలగించండి. కనీసం అది ఎక్కువగా ఉందని నమోదు చేయండి.
• disk పరీక్షను రెండు durationsలో నిర్వహించండి. చాలా plansలో burst IOPS allowance కొంతకాలానికి మళ్లీ నిండుతుంది. అందువల్ల 60 second fio run burstను కొలుస్తుంది, అయితే --runtime=600 కనీస స్థాయిని కొలుస్తుంది. చెడు రోజున మీకు లభించేది ఆ కనీస స్థాయే.
• మరే ఇతర ప్రక్రియ నడవడం లేదని నిర్ధారించండి. CPU పరీక్ష మధ్యలో unattended-upgrades apt transaction ప్రారంభిస్తే మీకు నిజమైన points కోల్పోతారు. ప్రతి runకు ముందు ps -e -o comm= | grep -E 'apt|dpkg' నిర్వహించడానికి ఒక సెకను పడుతుంది.
• ఒకేసారి ఒక variableను మాత్రమే మార్చండి. వేర్వేరు tool versions, block sizes లేదా thread countsతో లభించే numbersను పోల్చలేరు. అవి చూడటానికి ఎంత సమానంగా ఉన్నా ఈ పరిమితి వర్తిస్తుంది.

రెండు providersను పోల్చేటప్పుడు, వాటిపై ఒకే రోజు ఒకే గంటలో tests నిర్వహించండి. లేకపోతే మీరు కొలిచింది రోజు సమయాన్ని మాత్రమే.

మీ స్వంత 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, మీకు అత్యంత నెమ్మదిగా ఉండే query లేదా మీ స్వంత page render‌కు పట్టే సమయాన్ని కొలవండి. ఒక host‌లో build పూర్తయ్యేందుకు 4 minutes, మరొకదానిలో 7 minutes పడితే, Geekbench ఏమనుకున్నా ప్రశ్నకు సమాధానం దొరికినట్టే. మీరు మరింత శక్తివంతమైన machine కోసం చెల్లించడం ఎప్పుడు ప్రయోజనకరం కాదో కూడా ఈ కొలత చెబుతుంది. VPS‌కు వాస్తవంగా నెలకు ఎంత ఖర్చవుతుందో చదవడానికి లేదా workload‌ను dedicated server‌పైకి మార్చడానికి ముందు ఇది తెలుసుకోవడం ఉపయోగకరం.

FAQ

నేను పరీక్షను ప్రతిసారి అమలు చేసినప్పుడు వేరే బెంచ్‌మార్క్ ఫలితం ఎందుకు వస్తుంది?

VPS భౌతిక CPU, storage మరియు network వనరులను ఇతర tenantలతో పంచుకుంటుంది. అందువల్ల ఆ సమయంలో వారు ఏమి చేస్తున్నారనే దానిపై మీ ఫలితం ఆధారపడి ఉంటుంది. పరీక్ష సమయంలో vmstat 1 ను అమలు చేసి, st columnను చదవండి: steal time నిరంతరం 5 కంటే ఎక్కువగా ఉంటే host బిజీగా ఉందని అర్థం. మీ machine వెలుపలి కారణాల వల్ల CPU score తక్కువగా ఉంటుంది. దీనికి tuning కంటే సరైన పద్ధతి ముఖ్యం. ప్రతి పరీక్షను వేర్వేరు సమయాల్లో ఐదు లేదా అంతకంటే ఎక్కువసార్లు అమలు చేయండి. ఆ తర్వాత spreadతో పాటు medianను నివేదించండి.

fio లక్షల IOPSలను ఎందుకు నివేదిస్తుంది?

దాదాపు ఎల్లప్పుడూ --direct=1 లేకపోవడం వల్లే ఇది జరుగుతుంది. అది లేకపోతే fio kernel page cache ద్వారా చదువుతుంది. అందువల్ల మొదటి pass తర్వాత 2G test file RAM నుంచి అందించబడుతుంది. మీరు memory bandwidthను కొలిచినట్లవుతుంది. --direct=1 ను జోడించండి. Test 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ని కూడా ముద్రిస్తుంది. ఏదైనా సంఖ్య ఎందుకు అలా వచ్చిందో తెలుసుకోవాలనుకున్నప్పుడు ఇది సరిపోదు. కారణం, ప్రతి 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 నుంచి 99th percentileను పేర్కొనండి. ప్రతి 100 requestsలో ఆలస్యమయ్యే ఒక్క requestనే user గమనిస్తాడు.

బెంచ్‌మార్కింగ్‌కు ముందు ఏదైనా install చేయాలా?

Ubuntu మరియు Debian archivesలో fio, sysbench మరియు iperf3 అన్నీ ఉన్నాయి: sudo apt install -y fio sysbench iperf3. yabs.sh కు curl మాత్రమే అవసరం. ఏవి missingగా ఉన్నాయో వాటి కోసం ఇది static binariesను download చేస్తుంది. పని పూర్తయిన తర్వాత ప్రతి test fileను తొలగించండి. 20G diskపై మిగిలిపోయిన 2G fio file, కొన్ని వారాల తర్వాత ఎవరికైనా disk full alertకు కారణమవుతుంది.