VPS का सही benchmark कैसे लें: yabs.sh और fio

VPS को बेंचमार्क करने का अर्थ

VPS को बेंचमार्क करने के लिए आप चार चीजों को मापते हैं: एक CPU कोर कितनी तेजी से चलता है, मशीन में कितनी मेमोरी बैंडविड्थ है, स्टोरेज प्रति सेकंड कितने छोटे रैंडम डिस्क ऑपरेशन पूरे करता है, और नेटवर्क लिंक कितना थ्रूपुट प्रदान करता है। yabs.sh का एक रन आपको लगभग दस मिनट में CPU, डिस्क और नेटवर्क के परिणाम देता है; मेमोरी बैंडविड्थ के लिए नीचे दिए गए अलग मेमोरी टेस्ट का उपयोग करें। परिणामों को समझना अधिक कठिन है, क्योंकि एक VPS (virtual private server) भौतिक हार्डवेयर को अन्य किरायेदारों के साथ साझा करता है, इसलिए वही मशीन 03:00 बजे एक संख्या और 20:00 बजे बिल्कुल अलग संख्या दिखा सकती है।

यहाँ योजना यह है कि एक त्वरित तस्वीर के लिए yabs.sh चलाएं, और फिर नीचे दिए गए टूल्स को मैन्युअल रूप से चलाएं। स्वयं टूल्स चलाने से आप एक फ्लैग बदल सकते हैं, संख्या में बदलाव देख सकते हैं, और यह सीख सकते हैं कि वह संख्या वास्तव में क्या माप रही थी। यह काम मशीन सेटअप होने के बाद करें, पहले नहीं। नए VPS पर पहले दस मिनट में दिए गए चरण पहले पूरे करें, क्योंकि जो मशीन अभी अपने अपडेट का पहला दौर लागू कर रही है, उसका बेंचमार्क खराब आता है, जिसका हार्डवेयर से कोई लेना-देना नहीं होता।

मापने से पहले मशीन की जांच करें

किसी भी खराब बेंचमार्क का आधा कारण वह मशीन होती है जिसे लेखक ने समझा नहीं होता।

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 प्रिंट होने का अर्थ है कंटेनर वर्चुअलाइजेशन: आप host kernel साझा करते हैं, और आपकी CPU और memory सीमाएं virtual hardware के बजाय cgroup (control group) सेटिंग्स होती हैं। cgroup v2 सिस्टम पर आप अपने कंटेनर के cgroup से CPU सीमा पढ़ सकते हैं; जब वह cgroup /sys/fs/cgroup पर माउंट होता है, तो निम्नलिखित path लागू होता है।

cat /sys/fs/cgroup/cpu.max

max 100000 का अर्थ है कि इस cgroup का अपना कोई कोटा नहीं है; पूर्वज (ancestor) cgroups अभी भी एक कोटा लागू कर सकते हैं। 200000 100000 का अर्थ है कि आप प्रत्येक 100000 माइक्रोसेकंड की अवधि में 200000 माइक्रोसेकंड CPU का उपयोग कर सकते हैं, जो दो कोर के कोटे के बराबर है। 4 vCPU के रूप में विज्ञापित प्लान, जिसमें दो कोर का कोटा हो, कभी भी चार कोर जैसा प्रदर्शन नहीं करेगा। बेंचमार्क टूल्स इस प्रतिबंध की पहचान कर सकते हैं: VoxelBench CPU कोटे की रिपोर्ट करता है और साझा या थ्रॉटल किए गए CPU को फ्लैग करता है जब host उन CPU की तुलना में बहुत अधिक CPU दिखाता है जिनका सर्वर उपयोग कर सकता है।

df -hT / एक अलग कारण से महत्वपूर्ण है: Type कॉलम। यदि इसमें overlay लिखा है, तो आप एक कंटेनर के अंदर हैं, और आपके डिस्क परिणाम उस स्टोरेज का वर्णन करेंगे जो उस ओवरले के नीचे स्थित है। इसे अभी नोट कर लें।

Steal time की निरंतर निगरानी करें

Steal time वह समय है जो आपका virtual CPU अनैच्छिक रूप से प्रतीक्षा में बिताता है, क्योंकि hypervisor ने उसे schedule नहीं किया होता। यह उपलब्ध CPU समय की कमी का एक उपयोगी संकेत है, लेकिन यह व्यस्त पड़ोसियों (noisy neighbours) और provider द्वारा लागू की गई CPU quota सीमा के बीच अंतर नहीं करता है।

vmstat 1 10

दाईं ओर स्थित st column को देखें। निरंतर steal time का अर्थ है कि guest के लिए CPU समय उपलब्ध नहीं था, लेकिन 5% से अधिक मान यह साबित नहीं करता कि host oversubscribed है। प्रदाता जानबूझकर CPU quota enforcement को steal time के रूप में दिखा सकते हैं। top वही आंकड़ा दिखाता है जो CPU line पर %st में होता है। बेंचमार्क करते समय दूसरे SSH session में vmstat 1 को चालू रखें और प्रत्येक परिणाम के साथ steal figure को नोट करें।

yabs.sh के साथ शुरुआत करें

yabs.sh (Yet Another Bench Script) एक shell script है जो fio, iperf3 और Geekbench को चलाती है और एक summary print करती है। यदि ये पहले से installed हैं तो यह fio और iperf3 का उपयोग करती है, अन्यथा यह static binaries download कर लेती है। यह VPS benchmark चर्चाओं की सामान्य भाषा है, इसलिए yabs का output किसी अन्य व्यक्ति के साथ तुलना करने का सबसे तेज़ तरीका है।

प्रोजेक्ट का अपना one-line format यह है।

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 परिणामों को JSON के रूप में print करता है, और -w results.json उस JSON को एक file में लिखता है।

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

पहली बार चलाने से पहले दो बातें जान लें। Geekbench आपके परिणाम को upload करता है और एक public browser.geekbench.com URL print करता है, इसलिए उस link को रखने वाला कोई भी व्यक्ति आपके CPU model और scores को पढ़ सकता है। -g उस test को पूरी तरह से छोड़ देता है। दूसरी बात, iperf3 चरण कई क्षेत्रों के servers पर वास्तविक traffic भेजता है, और यह आपकी मासिक bandwidth allowance में गिना जाता है। 1 Gbit/s link पर एक पूर्ण network चरण दसियों gigabytes का डेटा भेज सकता है, इसलिए कम allowance होने पर -r का उपयोग करें और metered link पर -i का उपयोग करें।

yabs आउटपुट के प्रत्येक भाग का अर्थ

डिस्क अनुभाग 4k, 64k, 512k और 1m के चार block sizes पर 50/50 read और write मिश्रण के साथ fio चलाता है। यह प्रत्येक block size के लिए IOPS (input/output operations per second) और bandwidth रिपोर्ट करता है। Database, mail server या बहुत-सी छोटी writes करने वाले किसी भी workload के लिए 4k वाली row महत्वपूर्ण है, क्योंकि अधिकांश server IO छोटा और बिखरा हुआ होता है। 1m वाली row backups और video के लिए महत्वपूर्ण है, जहाँ bytes की लंबी श्रृंखलाएँ स्थानांतरित की जाती हैं।

Network अनुभाग कई regions में public servers के विरुद्ध, दोनों दिशाओं में, parallel streams का उपयोग करके iperf3 चलाता है। यहाँ कम संख्या को अंतिम निष्कर्ष के बजाय जाँच का संकेत मानें, क्योंकि public iperf3 servers साझा होते हैं और अक्सर saturated रहते हैं। इसलिए खराब परिणाम दूर वाले endpoint के कारण भी हो सकता है।

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 section के पीछे उपयोग होने वाला 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 print करता है। 99.00th percentile वह आंकड़ा है जिसे उद्धृत करना उचित है, क्योंकि यह बताता है कि 100 में से सबसे धीमे 1 request को कितनी देर प्रतीक्षा करनी पड़ी। औसत latency उन stalls को छिपा देती है जिन्हें user महसूस करता है।

• --direct=1 file को O_DIRECT के साथ खोलता है, इसलिए reads kernel page cache को bypass करते हैं। इसके बिना, 8G RAM वाली machine पर 2G file का दूसरा pass memory से serve होता है और fio लाखों में IOPS report करता है। यह संख्या वास्तविक है, लेकिन यह memory की संख्या है।
• --ioengine=libaio asynchronous requests submit करता है। इससे --iodepth=32 32 requests को in flight रख सकता है। psync जैसे synchronous engine के साथ 1 से अधिक iodepth का कोई प्रभाव नहीं होता। इसलिए आप एक समय में केवल 1 request measure करते हैं।
• --time_based --runtime=60 fixed amount of work के बजाय fixed 60 seconds तक चलता है। इससे fast disk और slow disk को समान wall clock मिलता है और comparison निष्पक्ष रहता है।
• --size=2G test file का size set करता है। इसे path में मौजूद किसी भी cache से बड़ा रखें और पहले जाँच लें कि पर्याप्त 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

वास्तविक traffic के अधिक निकट mix के लिए --rw=randrw --rwmixread=70 का उपयोग करें। आप किस class के storage पर हैं, इससे इन results में किसी भी flag की तुलना में अधिक बदलाव आता है। इस अंतर को VPS पर NVMe और SATA SSD storage के बीच का अंतर में समझाया गया है।

जब fio Unknown error -1 के साथ रुक जाए

Direct IO हर filesystem पर उपलब्ध नहीं होता है, इसलिए जब fio अपनी पहली ही request पर --direct=1 सेट होने के कारण विफल हो जाता है, तो सबसे पहले 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 . चलाएं। overlay का Type, जो कि Docker डिफ़ॉल्ट रूप से container को देता है, अपने आप में विफलता का कारण नहीं है। overlayfs, O_DIRECT को नीचे मौजूद filesystem तक पहुँचा देता है और इसे केवल तभी अस्वीकार करता है जब वह filesystem Direct IO न कर सके, इसलिए ext4 या xfs पर स्थित overlay पर --direct=1 --ioengine=libaio काम करता है। जब test file के नीचे वाला filesystem वास्तव में Direct IO नहीं कर सकता, तो file खोलते समय fio आमतौर पर यह संदेश देता है: fio: looks like your file system does not support direct=1/buffered=0। ऐसी स्थिति में --filename को वास्तविक local storage के किसी path पर point करें, जैसे कि bind mounted volume, या 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

यह एक थ्रेड और एक इन-फ्लाइट रिक्वेस्ट के साथ sequential write throughput को मापता है। यह एक उचित sanity check है। यह random IO के बारे में कुछ नहीं बताता, और न ही यह बताता है कि जब एक साथ 32 रिक्वेस्ट आती हैं तो क्या होता है। oflag=direct को हटा दें तो राइट्स page cache के माध्यम से जाते हैं, लेकिन conv=fdatasync अभी भी कमांड समाप्त होने से पहले आउटपुट डेटा को स्टोरेज में जाने के लिए मजबूर करता है। इसे भी हटा दें तो परिणाम मुख्य रूप से यह माप सकता है कि आपका kernel कितनी जल्दी मेमोरी में राइट्स स्वीकार करता है, यही कारण है कि फोरम पोस्ट में दिए गए 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 कैसे scale करता है।

स्पष्ट रहें कि यह क्या मापता है: 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 वाला command कॉपी करते हैं, तो आपको WARNING: the --test option is deprecated प्राप्त होगा। sysbench 0.4 और sysbench 1.0 के scores की आपस में तुलना बिल्कुल नहीं की जा सकती, इसलिए कभी भी ऐसे प्रकाशित आंकड़ों से अपनी तुलना न करें जिनमें version का उल्लेख न हो।

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 पर रखें, और जिन hosts की आप तुलना कर रहे हैं उन सभी पर इसे समान रखें। 1K पर संख्या गिर जाती है, क्योंकि आप प्रति-ऑपरेशन ओवरहेड का भुगतान हजार गुना अधिक बार करते हैं, इसलिए आप मेमोरी बैंडविड्थ के बजाय लूप की लागत माप रहे होते हैं। प्रकाशित मेमोरी स्कोर्स में यह सबसे अधिक गलत तरीके से उपयोग किया जाने वाला फ्लैग है।

Network: iperf3

थ्रूपुट का परीक्षण करने का सही तरीका यह है कि इसे आपके नियंत्रण वाली दूसरी मशीन के विरुद्ध किया जाए। इससे आपको पता रहता है कि दोनों सिरों पर क्या हो रहा है।

दूर वाली मशीन पर:

iperf3 -s

यह TCP 5201 पर सुनता है। पोर्ट को केवल उस address के लिए खोलें जिससे आप परीक्षण कर रहे हैं। परीक्षण पूरा होने पर इसे बंद कर दें। VPS पर Basic ufw firewall rules में 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 उतना ही unacknowledged data रख सकता है जितना उसका window अनुमति देता है। इसलिए इसकी अधिकतम दर लगभग window size को round trip time से विभाजित करने के बराबर होती है। 80 ms latency और 4 MB window पर यह सीमा लगभग 400 Mbit/s होती है, चाहे underlying link कितनी भी तेज हो। Single stream का आंकड़ा बताता है कि एक download को कितनी गति मिलेगी। Parallel आंकड़ा link की capacity बताता है।

यह परीक्षण करते समय अपने bandwidth allowance पर नज़र रखें। 1 Gbit/s पर 30 seconds में लगभग 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"
  }
]

प्रकाशित परिणामों में एक 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 से लिए गए माप। इनका उपयोग केवल एक उद्देश्य के लिए करें: यह जाँचने के लिए कि आपका अपना परिणाम सही परिमाण (order of magnitude) में है या नहीं। यदि NVMe के रूप में बेचा गया कोई plan 4k IOPS के कुछ हजार के निचले स्तर पर benchmark देता है, तो पहले पुष्टि करें कि --direct=1 चालू था। यदि वह चालू था, तो plan की IOPS सीमा और burst credits के साथ-साथ storage contention और विज्ञापित hardware की भी जाँच करें।

एक रन बेंचमार्क क्यों नहीं है

एक एकल परिणाम साझा मशीन पर एक मिनट की स्थिति का स्नैपशॉट होता है। इसे केवल एक नमूना मानें।

• प्रत्येक टेस्ट को कम से कम पांच बार चलाएं, जो अलग-अलग घंटों और कम से कम दो अलग-अलग दिनों में फैला हो। माध्यिका (median) और फैलाव (spread) को सुरक्षित रखें। बिना फैलाव के प्रकाशित परिणाम केवल एक मार्केटिंग आंकड़ा है।
• प्रत्येक रन के साथ steal time को रिकॉर्ड करें। जिन रन में st अधिक था, उन्हें रखें और जांचें कि क्या वे contention को दर्शाते हैं या plan के CPU quota को; उन्हें हटाने से आप उस प्रदर्शन को छिपा सकते हैं जो आपको वास्तव में प्राप्त हो रहा है।
• डिस्क टेस्ट को दो अवधियों पर चलाएं। कई plans एक burst IOPS allowance देते हैं जो समय के साथ भरता है, लेकिन न तो 60 सेकंड का fio रन और न ही --runtime=600 यह गारंटी देता है कि आपने न्यूनतम प्रदर्शन (floor) को मापा है। AWS gp2 credits पूर्ण बैलेंस से कम से कम 30 मिनट तक 3,000 IOPS बनाए रख सकते हैं, इसलिए दोनों रन burst प्रदर्शन को माप सकते हैं। प्रदाता के credit model की जांच करें और परिणाम को sustained performance कहने से पहले credit balance की निगरानी करें।
• सुनिश्चित करें कि अन्य कुछ भी नहीं चल रहा है। CPU टेस्ट के बीच में unattended-upgrades द्वारा apt transaction शुरू करने से आपके वास्तविक अंक कम हो जाते हैं, और प्रत्येक रन से पहले ps -e -o comm= | grep -E 'apt|dpkg' एक सेकंड का समय लेता है।
• एक बार में केवल एक variable बदलें। टूल के अलग-अलग संस्करण, ब्लॉक साइज या थ्रेड काउंट ऐसे आंकड़े उत्पन्न करते हैं जिनकी तुलना नहीं की जा सकती, चाहे वे कितने भी समान क्यों न दिखें।

जब आप दो प्रदाताओं की तुलना करते हैं, तो उन्हें एक ही दिन के एक ही घंटे पर चलाएं। अन्यथा, आपने केवल दिन के समय को मापा है।

अपने कार्यभार का बेंचमार्क सबसे अंत में करें

सिंथेटिक टूल मशीनों की रैंकिंग करते हैं। केवल आपका अपना कार्यभार बताता है कि मशीन पर्याप्त है या नहीं। उसी कार्य को समयबद्ध करें जिसे आप वास्तव में करते हैं।

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

हर बार benchmark चलाने पर मुझे अलग परिणाम क्यों मिलता है?

एक VPS अन्य tenants के साथ physical CPU, storage और network साझा करता है, इसलिए आपका परिणाम इस बात पर निर्भर करता है कि वे उस समय क्या कर रहे हैं। टेस्ट के दौरान vmstat 1 चलाएं और st कॉलम को पढ़ें: sustained steal time अनुपलब्ध CPU समय को रिकॉर्ड करता है, लेकिन यह host contention के साथ-साथ आपके द्वारा खरीदे गए CPU allocation को लागू करने वाले provider को भी दर्शा सकता है। 5% से अधिक का मान कारण स्पष्ट नहीं करता है। इसका उत्तर ट्यूनिंग के बजाय पद्धति में है। प्रत्येक टेस्ट को अलग-अलग घंटों में पांच या अधिक बार चलाएं, फिर median और spread की रिपोर्ट करें।

fio लाखों IOPS की रिपोर्ट क्यों करता है?

लगभग हमेशा इसलिए क्योंकि --direct=1 गायब है। इसके बिना fio kernel page cache के माध्यम से पढ़ता है, इसलिए पहले pass के बाद 2G की टेस्ट फाइल RAM से सर्व की जाती है और आप memory bandwidth को माप रहे होते हैं। --direct=1 जोड़ें और टेस्ट फाइल को path में मौजूद किसी भी cache से बड़ा रखें। यदि --direct=1 विफल हो जाता है, तो df -hT . चलाएं और जांचें कि टेस्ट फाइल किस पर स्थित है। एक overlay प्रकार अपने आप में समस्या नहीं है, क्योंकि overlayfs O_DIRECT को नीचे मौजूद storage तक पहुंचा देता है। टेस्ट फाइल को केवल तभी वास्तविक local storage पर ले जाएं यदि नीचे मौजूद filesystem direct IO को अस्वीकार करता है।

क्या केवल yabs.sh पर्याप्त है?

पहली बार देखने के लिए, हाँ। यह चार block sizes पर fio, दोनों दिशाओं में iperf3 और Geekbench चलाता है, और यह एक सारांश प्रिंट करता है जिसे दूसरे लोग पढ़ सकते हैं। यह तब पर्याप्त नहीं रहता जब आप यह जानना चाहते हैं कि कोई संख्या वैसी क्यों है, क्योंकि आप प्रति टेस्ट इसके flags को बदल नहीं सकते। एक बार जब yabs का परिणाम गलत लगे, तो इसे सीधे fio या sysbench के साथ पुन: उत्पन्न करें और एक बार में एक flag बदलें।

कौन सी एकल संख्या यह अनुमान लगाती है कि मेरा application कैसा महसूस करेगा?

अधिकांश web और database workloads के लिए, उस क्रम में, single core CPU speed और 4k random read latency। Throughput के आंकड़े प्रभावशाली दिखते हैं और शायद ही कभी कुछ तय करते हैं, क्योंकि एक सामान्य request छोटी होती है। औसत के बजाय fio clat percentiles ब्लॉक से 99th percentile का उल्लेख करें, क्योंकि सौ में से वह एक धीमी request ही है जिसे उपयोगकर्ता नोटिस करता है।

क्या मुझे benchmarking से पहले कुछ भी install करने की आवश्यकता है?

fio, sysbench और iperf3 सभी Ubuntu और Debian archives में हैं: sudo apt install -y fio sysbench iperf3। yabs.sh Bash में चलता है और डाउनलोड के लिए curl या wget की आवश्यकता होती है, साथ ही Geekbench को extract करने के लिए tar; tar के बिना, यह Geekbench को छोड़ देता है। यह install होने पर fio और iperf3 का उपयोग करता है और गायब होने पर static binaries डाउनलोड करता है। समाप्त होने पर प्रत्येक टेस्ट फाइल को हटा दें, क्योंकि 20G डिस्क पर छोड़ी गई 2G fio फाइल हफ्तों बाद किसी के लिए disk full का अलर्ट बन जाती है।