چطور یک VPS را درست benchmark کنیم؟

مفهوم اجرای benchmark روی VPS

برای benchmark کردن یک VPS، 4 مورد را اندازه‌گیری می‌کنید: سرعت اجرای یک هسته CPU، پهنای‌باند حافظه دستگاه، تعداد عملیات کوچک و تصادفی دیسک که فضای ذخیره‌سازی در هر ثانیه ارائه می‌دهد، و throughput لینک شبکه. اجرای yabs.sh هر 4 مورد را در حدود 10 دقیقه در اختیار شما می‌گذارد. تفسیر نتیجه بخش دشوارتر است، زیرا یک VPS (سرور خصوصی مجازی) منابع سخت‌افزاری فیزیکی را با tenantهای دیگر به اشتراک می‌گذارد. بنابراین، همان دستگاه ممکن است در ساعت 03:00 یک مقدار و در ساعت 20:00 مقدار بسیار متفاوتی گزارش کند.

در اینجا ابتدا yabs.sh را برای به‌دست‌آوردن یک تصویر سریع اجرا می‌کنیم و سپس ابزارهای زیربنایی آن را به‌صورت دستی اجرا می‌کنیم. اجرای دستی ابزارها به شما امکان می‌دهد یک flag را تغییر دهید، تغییر مقدار را monitor کنید و متوجه شوید آن مقدار واقعاً چه چیزی را اندازه‌گیری می‌کرده است. این کار را پس از راه‌اندازی دستگاه انجام دهید، نه پیش از آن. مراحل 10 دقیقه اول روی یک VPS جدید باید ابتدا انجام شوند، زیرا سیستمی که هنوز نخستین دور updateهای خود را اعمال می‌کند، به دلایلی نامرتبط با سخت‌افزار، benchmark ضعیفی ارائه می‌دهد.

پیش از اندازه‌گیری، ماشین را بررسی کنید

نیمی از هر محک نامعتبر، حاصل ماشینی است که نویسنده آن را به‌درستی نمی‌شناخته است.

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

Hypervisor vendor: KVM به معنای مجازی‌سازی کامل است؛ بنابراین kernel خودتان را اجرا می‌کنید. چاپ lxc یا openvz در systemd-detect-virt، به‌جای آن، به معنای مجازی‌سازی کانتینری است: kernel میزبان را به‌صورت مشترک استفاده می‌کنید و محدودیت‌های CPU و حافظه شما تنظیمات cgroup (control group) هستند، نه سخت‌افزار مجازی. در سیستمی با cgroup v2 می‌توانید محدودیت CPU را مستقیماً بخوانید.

cat /sys/fs/cgroup/cpu.max

max 100000 یعنی هیچ سهمیه‌ای وجود ندارد. 200000 100000 یعنی می‌توانید در هر دوره 100000 میکروثانیه‌ای، از 200000 میکروثانیه CPU استفاده کنید؛ یعنی سهمیه‌ای معادل 2 هسته. طرحی که با 4 vCPU تبلیغ می‌شود اما سهمیه آن معادل 2 هسته است، هرگز مانند 4 هسته امتیاز نمی‌گیرد و هیچ ابزار محک خطی چاپ نمی‌کند که دلیل آن را توضیح دهد.

df -hT / به دلیل دیگری اهمیت دارد: ستون Type. اگر مقدار آن overlay باشد، داخل یک کانتینر هستید و آزمایش دیسک در ادامه به تغییر نیاز دارد. اکنون این مورد را یادداشت کنید.

پایش مداوم زمان سرقت

زمان سرقت سهم زمانی است که CPU مجازی شما آماده اجرای کار بوده، اما hypervisor هسته فیزیکی را به پردازش دیگری اختصاص داده است. این شاخص به‌تنهایی بهترین معیار برای تشخیص این است که نتیجه به همسایه‌های شما مربوط است، نه به سخت‌افزار.

vmstat 1 10

ستون st را در سمت راست بخوانید. مقدار ثابت 0 یا 1 طبیعی است. مقادیر پایدار بالاتر از 5 نشان می‌دهند که host در آن لحظه بیش‌ازحد مورد استفاده قرار گرفته است؛ بنابراین همه اعداد CPU که در آن بازه ثبت می‌کنید، بدون ایراد از طرف ماشین شما، کمتر از مقدار واقعی هستند. top همان مقدار %st را در خط CPU نشان می‌دهد. هنگام اجرای آزمون کارایی، vmstat 1 را در یک نشست SSH دوم اجرا نگه دارید و مقدار زمان سرقت را کنار هر نتیجه یادداشت کنید.

با yabs.sh شروع کنید

yabs.sh (Yet Another Bench Script) یک اسکریپت shell است که فایل‌های باینری ایستای fio، iperf3 و Geekbench را دانلود می‌کند، آن‌ها را اجرا می‌کند و یک خلاصه نمایش می‌دهد. این ابزار زبان مشترک گفتگوهای مربوط به benchmark سرورهای VPS است؛ بنابراین خروجی 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 -- قرار می‌گیرند؛ هنگام اجرای نسخه محلی، آن‌ها را مستقیماً بعد از نام فایل بنویسید. گزینه‌های کاربردی عبارت‌اند از: -f آزمون دیسک را رد می‌کند، -i آزمون شبکه را رد می‌کند، -g آزمون Geekbench را رد می‌کند، -r تعداد محل‌های iperf3 را به 2 مورد کاهش می‌دهد، -j نتایج را به‌صورت JSON نمایش می‌دهد و -w results.json همان JSON را در یک فایل می‌نویسد.

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

پیش از نخستین اجرا، دو نکته را در نظر بگیرید. Geekbench نتیجه شما را بارگذاری می‌کند و یک URL عمومی از browser.geekbench.com نمایش می‌دهد؛ بنابراین هر کسی که آن پیوند را داشته باشد می‌تواند مدل CPU و امتیازهای شما را ببیند. -g این آزمون را به‌طور کامل رد می‌کند. دوم، مرحله iperf3 ترافیک واقعی را به سرورهایی در چند منطقه منتقل می‌کند و این ترافیک از سهمیه ماهانه پهنای‌باند شما کم می‌شود. در یک پیوند 1 Gbit/s، اجرای کامل مرحله شبکه می‌تواند ده‌ها گیگابایت داده منتقل کند؛ بنابراین در صورت داشتن سهمیه محدود از -r و در یک پیوند دارای هزینه بر اساس مصرف از -i استفاده کنید.

معنی هر بخش از خروجی yabs

بخش دیسک، fio را با ترکیب 50/50 خواندن و نوشتن، در 4 اندازه بلوک اجرا می‌کند: 4k، 64k، 512k و 1m. این بخش برای هر اندازه، مقدار IOPS (تعداد عملیات ورودی/خروجی در ثانیه) و پهنای‌باند را گزارش می‌کند. ردیف 4k برای پایگاه داده، mail server یا هر کاری که نوشتن‌های کوچک و متعدد انجام می‌دهد، اهمیت بیشتری دارد؛ زیرا بیشتر عملیات IO سرورها کوچک و پراکنده هستند. ردیف 1m برای پشتیبان‌گیری و ویدئو مناسب است؛ یعنی مواردی که در آن‌ها دنباله‌های طولانی بایت جابه‌جا می‌شوند.

بخش شبکه، iperf3 را در برابر serverهای عمومی در چند منطقه و در هر دو جهت، با استفاده از streamهای موازی اجرا می‌کند. یک عدد پایین را در این بخش باید نشانه‌ای برای بررسی بیشتر بدانید، نه یک نتیجه قطعی؛ زیرا serverهای عمومی iperf3 اشتراکی هستند و اغلب اشباع می‌شوند. بنابراین ممکن است نتیجه ضعیف مربوط به سمت مقابل باشد.

بخش Geekbench یک امتیاز برای single core و یک امتیاز برای multi core ارائه می‌دهد. امتیاز single core نشان می‌دهد یک درخواست، یک فرایند compile یا یک query با چه سرعتی کامل می‌شود. امتیاز multi core عمدتاً نشان می‌دهد واقعاً چند core در اختیار شما قرار گرفته است.

دیسک: اجرای مستقیم fio

fio (آزمون‌گر ورودی/خروجی انعطاف‌پذیر) ابزاری است که در بخش دیسک yabs استفاده می‌شود. اجرای مستقیم آن باعث می‌شود نقش گزینه‌ها روشن شود.

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

آزمون خواندن تصادفی 4k با عمق صف 32، روی همان فایل‌سیستمی که واقعاً برایتان مهم است:

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

خط خلاصه‌ای که باید از خروجی بخوانید، به این شکل است.

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

در زیر آن، fio یک بلوک clat percentiles چاپ می‌کند. صدک 99.00 رقمی است که ارزش گزارش‌کردن دارد، چون نشان می‌دهد کندترین درخواست از هر 100 درخواست چه مدت منتظر مانده است. میانگین تأخیر دقیقاً توقف‌هایی را پنهان می‌کند که کاربر متوجه آن‌ها می‌شود.

• --direct=1 فایل را با O_DIRECT باز می‌کند؛ بنابراین خواندن‌ها از page cache هسته عبور می‌کنند. بدون آن، اجرای دوم روی یک فایل 2G در ماشینی با 8G RAM از حافظه پاسخ داده می‌شود و fio مقدار IOPS را در حد میلیون‌ها گزارش می‌کند. این عدد واقعی است، اما مربوط به حافظه است.
• --ioengine=libaio درخواست‌های ناهمگام را ارسال می‌کند. به همین دلیل --iodepth=32 می‌تواند 32 درخواست را هم‌زمان در حال اجرا نگه دارد. با یک engine همگام مانند psync، مقدار iodepth بیشتر از 1 هیچ اثری ندارد و در نتیجه هر بار فقط یک درخواست را اندازه‌گیری می‌کنید.
• --time_based --runtime=60 آزمون را به مدت ثابت 60 ثانیه اجرا می‌کند، نه برای مقدار ثابتی از کار. بنابراین دیسک سریع و دیسک کند زمان یکسانی را در ساعت واقعی صرف می‌کنند و مقایسه منصفانه باقی می‌ماند.
• --size=2G اندازه فایل آزمون را تعیین می‌کند. آن را بزرگ‌تر از هر cache موجود در مسیر نگه دارید و ابتدا بررسی کنید که فضای آزاد کافی دارید.

نوشتن تصادفی همان دستور است، با --rw=randwrite. آن را جداگانه اجرا کنید و سپس فایل را حذف کنید.

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

برای ترکیبی نزدیک‌تر به ترافیک واقعی، از --rw=randrw --rwmixread=70 استفاده کنید. نوع فضای ذخیره‌سازی که روی آن قرار دارید، بیش از هر گزینه‌ای این نتایج را تغییر می‌دهد. این تفاوت در تفاوت فضای ذخیره‌سازی NVMe و SATA SSD در VPS بررسی شده است.

وقتی fio با خطای Unknown error -1 متوقف می‌شود

overlay، یعنی سیستم فایلی که Docker به‌صورت پیش‌فرض در اختیار کانتینر قرار می‌دهد، و چندین سیستم فایل شبکه‌ای از 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 را به مسیری روی فضای ذخیره‌سازی واقعی، مانند یک volume متصل‌شده با bind mount، هدایت کنید یا fio را به‌جای کانتینر روی میزبان اجرا کنید. اگر دسترسی به فضای ذخیره‌سازی واقعی ممکن نیست، اجرای بافرشده و همگام حداقل درست‌بودن خود فرمان را تأیید می‌کند.

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 و پردازش صحیح flagها استفاده کنید. هرگز آن را به‌عنوان نتیجه دیسک گزارش نکنید.

چرا dd معیار سنجش دیسک نیست

dd در بسیاری از بحث‌های مربوط به VPS دیده می‌شود و فقط به یک پرسش محدود پاسخ می‌دهد.

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

این دستور توان عملیاتی نوشتن ترتیبی را با یک thread و یک درخواست در حال اجرا اندازه‌گیری می‌کند. این یک بررسی اولیه مناسب است. درباره IO تصادفی چیزی نمی‌گوید و مشخص نمی‌کند وقتی 32 درخواست هم‌زمان برسند چه اتفاقی رخ می‌دهد. اگر oflag=direct را حذف کنید، این دستور عمدتاً سرعت پذیرش عملیات نوشتن در حافظه توسط 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 است. ابتدا آزمون را با یک thread اجرا کنید. این مقدار مشخص می‌کند یک درخواست PHP با چه سرعتی تکمیل می‌شود یا یک کار compile چه مدت طول می‌کشد، و بین میزبان‌هایی با قیمت یکسان بیشترین تفاوت را دارد. سپس آزمون را با همه threadها اجرا کنید. این کار نشان می‌دهد vCPUهای شما هسته‌های مستقل هستند یا بخش‌هایی از یک هسته.

دقیقاً مشخص کنید این آزمون چه چیزی را اندازه‌گیری می‌کند: sysbench cpu به‌طور مکرر اعداد اول را با استفاده از محاسبات صحیح 64 بیتی پیدا می‌کند. این آزمون پهنای‌باند حافظه، واحدهای برداری یا cache را به شکلی مشابه workload واقعی تحت فشار قرار نمی‌دهد. بنابراین برای رتبه‌بندی دو میزبان مناسب است، اما برای پیش‌بینی نحوه اجرای برنامه شما مناسب نیست.

Ubuntu 24.04، sysbench 1.0.20 را ارائه می‌کند که در آن نام آزمون ابتدا می‌آید. اگر فرمانی را با --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 است و در همه سیستم‌ها، سرعت خواندن از نوشتن بیشتر است. مقدار --memory-block-size را روی 1M نگه دارید و این مقدار را در همه میزبان‌هایی که مقایسه می‌کنید یکسان تنظیم کنید. در 1K عدد به‌شدت کاهش می‌یابد، زیرا سربار هر عملیات را هزار برابر بیشتر متحمل می‌شوید و در نهایت، به‌جای پهنای‌باند حافظه، هزینه حلقه را اندازه‌گیری می‌کنید. این پرکاربردترین گزینه‌ای است که در امتیازهای منتشرشده حافظه به‌صورت ناهماهنگ تنظیم می‌شود.

شبکه: iperf3

روش درست برای آزمون توان عملیاتی، انجام آزمون در برابر ماشین دومی است که آن را کنترل می‌کنید؛ زیرا در این حالت می‌دانید هر دو سمت چه کاری انجام می‌دهند.

در سمت دیگر:

iperf3 -s

این دستور روی TCP 5201 به درخواست‌ها گوش می‌دهد. این پورت را فقط برای نشانی‌ای که آزمون را از آن اجرا می‌کنید باز کنید و پس از پایان کار ببندید. قواعد پایه فایروال ufw در VPS نحو این کار را توضیح می‌دهد.

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

دستور اول سرعت آپلود را از ماشین مورد آزمون اندازه‌گیری می‌کند. -R جهت را معکوس می‌کند و سرعت دانلود را اندازه می‌گیرد. -P 8 هشت جریان موازی باز می‌کند.

هم اجرای تک‌جریانی و هم نسخه موازی را انجام دهید؛ زیرا این دو به پرسش‌های متفاوتی پاسخ می‌دهند. یک اتصال TCP فقط می‌تواند به اندازه داده‌های تأییدنشده‌ای را نگه دارد که پنجره آن اجازه می‌دهد. بنابراین سقف سرعت آن تقریباً برابر است با اندازه پنجره تقسیم بر زمان رفت‌وبرگشت. با تأخیر 80 ms و پنجره 4 MB، این سقف حدود 400 Mbit/s است؛ حتی اگر لینک زیربنایی سرعت بیشتری داشته باشد. مقدار تک‌جریانی نشان می‌دهد یک دانلود چه سرعتی دریافت می‌کند. مقدار موازی ظرفیت لینک را نشان می‌دهد.

هنگام انجام این آزمون، سهمیه پهنای‌باند خود را زیر نظر داشته باشید. 30 ثانیه در سرعت 1 Gbit/s حدود 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"
  }
]

یک volume محلی NVMe در نتایج منتشرشده معمولاً حدود 180,000 IOPS برای خواندن تصادفی 4k ثبت می‌کند. یک SSD محلی SATA معمولاً حدود 90,000 به دست می‌آورد. فضای ذخیره‌سازی block متصل به شبکه، که در آن هر درخواست پیش از رسیدن به disk از شبکه عبور می‌کند، معمولاً به 12,000 نزدیک‌تر است. یک disk چرخان نیز تقریباً 180 را مدیریت می‌کند، زیرا برای هر درخواست تصادفی، هد فیزیکی را جابه‌جا می‌کند.

این ارقام، مقادیر معمول منتشرشده برای هر رده از فضای ذخیره‌سازی هستند و اندازه‌گیری‌های انجام‌شده روی یک host واحد نیستند. از آن‌ها فقط برای یک هدف استفاده کنید: بررسی اینکه نتیجه خودتان در همان مرتبه بزرگی قرار دارد. اگر یک plan که با عنوان NVMe فروخته می‌شود، در benchmark به چند هزار IOPS برای 4k می‌رسد، ابتدا تأیید کنید که --direct=1 فعال بوده است. اگر فعال بوده، یا فضای ذخیره‌سازی با توضیح صفحه محصول مطابقت ندارد، یا آن را با همسایه‌ای بسیار پرمصرف به اشتراک گذاشته‌اید.

چرا یک اجرا معیار سنجش نیست

یک نتیجه، فقط تصویری از یک دقیقه در یک ماشین اشتراکی است. آن را یک نمونه در نظر بگیرید.

• هر آزمون را دست‌کم 5 بار و در ساعت‌های مختلف و حداقل در 2 روز متفاوت اجرا کنید. میانه و دامنه تغییرات را نگه دارید. نتیجه‌ای که بدون دامنه تغییرات منتشر شود، یک عدد تبلیغاتی است.
• زمان steal را در کنار هر اجرا ثبت کنید. اجراهایی را که st در آن‌ها زیاد بوده حذف کنید، یا دست‌کم این موضوع را یادداشت کنید.
• آزمون دیسک را با 2 مدت‌زمان اجرا کنید. بسیاری از طرح‌ها سهمیه burst برای IOPS دارند که به‌مرور زمان دوباره پر می‌شود؛ بنابراین اجرای 60 ثانیه‌ای fio، burst را اندازه‌گیری می‌کند، در حالی که --runtime=600 کف عملکرد را اندازه‌گیری می‌کند. کف عملکرد همان چیزی است که در یک روز نامناسب دریافت می‌کنید.
• مطمئن شوید هیچ فرایند دیگری در حال اجرا نیست. unattended-upgrades که در میانه آزمون CPU یک تراکنش apt را آغاز شود، امتیاز واقعی شما را کاهش می‌دهد و اجرای ps -e -o comm= | grep -E 'apt|dpkg' پیش از هر آزمون فقط 1 ثانیه زمان می‌برد.
• هر بار فقط 1 متغیر را تغییر دهید. نسخه‌های متفاوت ابزار، اندازه‌های بلوک یا تعداد thread، اعدادی تولید می‌کنند که قابل مقایسه نیستند؛ حتی اگر بسیار مشابه به نظر برسند.

هنگام مقایسه 2 ارائه‌دهنده، آزمون را در یک ساعت یکسان از یک روز یکسان اجرا کنید. در غیر این صورت، زمان روز را اندازه‌گیری کرده‌اید.

در نهایت، بارکاری خودتان را محک بزنید

ابزارهای مصنوعی ماشین‌ها را رتبه‌بندی می‌کنند. فقط بارکاری خودتان نشان می‌دهد که آیا یک ماشین کافی است یا نه. زمان انجام کاری را اندازه‌گیری کنید که واقعاً انجام می‌دهید.

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

این دستور چند صد مگابایت را فشرده می‌کند؛ بنابراین CPU و دیسک را هم‌زمان درگیر می‌کند و با تغییر هرکدام از آن‌ها، نتیجه نیز تغییر می‌کند. هشدار Removing leading / from member names عادی است. بهتر از آن، زمان ساخت پروژه خودتان، کندترین query خودتان یا render شدن صفحه خودتان را اندازه‌گیری کنید. اگر ساخت پروژه در یک میزبان 4 دقیقه و در میزبان دیگر 7 دقیقه طول بکشد، پاسخ روشن است؛ صرف‌نظر از اینکه Geekbench چه نظری داشته باشد. این همان اندازه‌گیری‌ای است که مشخص می‌کند از چه زمانی پرداخت هزینه برای ماشین قدرتمندتر دیگر ارزش ندارد؛ دانستن این موضوع پیش از مطالعه درباره هزینه واقعی ماهانه یک VPS یا انتقال بارکاری به یک سرور اختصاصی مفید است.

FAQ

چرا هر بار که آزمون را اجرا می‌کنم، نتیجه متفاوتی می‌گیرم؟

یک VPS، CPU فیزیکی، فضای ذخیره‌سازی و شبکه را با tenantهای دیگر به‌اشتراک می‌گذارد؛ بنابراین نتیجه شما به کاری بستگی دارد که آن‌ها در همان لحظه انجام می‌دهند. هنگام آزمون، vmstat 1 را اجرا کنید و ستون st را بخوانید: اگر steal time پایدار بیشتر از 5 باشد، host مشغول بوده است و CPU score شما به دلایلی خارج از ماشینتان پایین است. راه‌حل، تغییر روش آزمون است، نه tuning. هر آزمون را پنج بار یا بیشتر و در ساعت‌های مختلف اجرا کنید، سپس median را همراه با spread گزارش دهید.

چرا fio میلیون‌ها IOPS گزارش می‌کند؟

تقریباً همیشه به این دلیل است که --direct=1 وجود ندارد. بدون آن، fio از page cache مربوط به kernel می‌خواند؛ بنابراین پس از نخستین pass، فایل آزمون 2G از RAM ارائه می‌شود و در واقع memory bandwidth را اندازه‌گیری کرده‌اید. --direct=1 را اضافه کنید و فایل آزمون را بزرگ‌تر از هر 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 به‌تنهایی کافی است؟

برای بررسی اولیه، بله. این ابزار fio را با چهار block size، ابزار iperf3 را در هر دو جهت و Geekbench را اجرا می‌کند و یک summary قابل‌خواندن برای دیگران چاپ می‌کند. زمانی که بخواهید بدانید یک عدد چرا چنین مقداری دارد، دیگر کافی نیست؛ زیرا نمی‌توانید flagهای آن را برای هر آزمون جداگانه تغییر دهید. هرگاه نتیجه yabs نادرست به نظر رسید، آن را مستقیماً با fio یا sysbench بازتولید کنید و هر بار فقط یک flag را تغییر دهید.

کدام عدد منفرد پیش‌بینی می‌کند که برنامه من چه احساسی ایجاد خواهد کرد؟

برای بیشتر workloadهای وب و database، به‌ترتیب سرعت single core CPU و latency مربوط به random read در اندازه 4k مهم‌تر هستند. اعداد throughput چشمگیر به نظر می‌رسند، اما به‌ندرت تعیین‌کننده‌اند؛ زیرا یک request معمولی کوچک است. به‌جای average، صدک 99 را از block مربوط به fio clat percentiles گزارش کنید، چون همان یک request کند از هر صد request چیزی است که کاربر متوجه آن می‌شود.

آیا پیش از benchmark باید چیزی نصب کنم؟

fio، sysbench و iperf3 همگی در archiveهای Ubuntu و Debian موجود هستند: sudo apt install -y fio sysbench iperf3. yabs.sh فقط به curl نیاز دارد، زیرا برای مواردی که وجود ندارند، binaryهای static را download می‌کند. پس از پایان کار، همه فایل‌های آزمون را حذف کنید؛ زیرا باقی گذاشتن یک فایل fio با اندازه 2G روی دیسک 20G می‌تواند چند هفته بعد باعث ایجاد هشدار disk full برای فرد دیگری شود.