كيفية اختبار أداء VPS بدقة باستخدام yabs.sh

ما المقصود بإجراء اختبار معياري لـVPS

لإجراء اختبار معياري لـVPS، قِس أربعة أمور: سرعة نواة CPU واحدة، وعرض نطاق الذاكرة المتاح على الجهاز، وعدد عمليات القرص العشوائية الصغيرة التي تنفذها وحدة التخزين كل ثانية، ومعدل النقل الذي يوفّره رابط الشبكة. تمنحك عملية تشغيل واحدة لـ yabs.sh نتائج CPU والقرص والشبكة خلال نحو عشر دقائق؛ استخدم اختبار الذاكرة المنفصل أدناه لقياس عرض نطاق الذاكرة. تكمن الصعوبة الأكبر في قراءة النتيجة، لأن VPS يشارك العتاد الفعلي مع مستأجرين آخرين، ولذلك قد يعرض الجهاز نفسه رقماً في الساعة 03:00 ورقماً مختلفاً جداً في الساعة 20:00.

تتمثل الخطة هنا في تشغيل yabs.sh للحصول على صورة سريعة، ثم تشغيل الأدوات التي يستخدمها يدوياً. يتيح لك تشغيلها بنفسك تغيير flag واحد، ومراقبة تغيّر الرقم، وفهم ما كان الرقم يقيسه فعلياً. نفّذ ذلك بعد إعداد الجهاز، وليس قبله. تأتي الخطوات الواردة في الدقائق العشر الأولى على VPS جديد أولاً، لأن الجهاز الذي لا يزال يطبّق أول مجموعة من التحديثات يعطي نتائج اختبار معيارية سيئة لأسباب لا علاقة لها بالعتاد.

افحص الجهاز قبل أن تقيس أداءه

يرجع نصف نتائج الاختبارات المعيارية السيئة إلى جهاز لم يفهمه من أجرى الاختبار.

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

تعني Hypervisor vendor: KVM المحاكاة الافتراضية الكاملة، ولذلك تشغّل نواتك الخاصة. أما ظهور lxc أو openvz في ناتج systemd-detect-virt فيعني استخدام المحاكاة الافتراضية للحاويات بدلاً من ذلك: فأنت تشارك نواة المضيف، وتكون حدود المعالج والذاكرة إعدادات cgroup (مجموعة التحكم)، لا عتاداً افتراضياً. في نظام يستخدم cgroup v2، يمكنك قراءة حد المعالج من cgroup الخاصة بحاويتك؛ وينطبق المسار التالي عندما تكون هذه cgroup موصّلة عند /sys/fs/cgroup.

cat /sys/fs/cgroup/cpu.max

تعني max 100000 أن هذه cgroup لا تملك حصة خاصة بها؛ لكن يمكن لـcgroups الأعلى منها فرض حصة. وتعني 200000 100000 أنه يمكنك استخدام 200000 ميكروثانية من وقت المعالج في كل فترة مدتها 100000 ميكروثانية، أي حصة تعادل نواتين. ولن يحقق عرض يُعلن عن 4 vCPU مع حصة تعادل نواتين نتيجة مماثلة لأربع نوى. يمكن لأدوات الاختبار المعياري تحديد هذا القيد: يعرض VoxelBench حصص المعالج، ويشير إلى أن المعالج مشترك أو مقيّد عندما يكشف المضيف عن عدد من المعالجات يفوق كثيراً العدد الذي يمكن للخادم استخدامه.

وتهم df -hT / لسبب مختلف: عمود Type. إذا كانت قيمته overlay، فأنت داخل حاوية، وستصف نتائج القرص مساحة التخزين الموجودة أسفل طبقة overlay، أياً كانت. سجّل هذه المعلومة الآن.

راقب وقت الانتزاع طوال الوقت

وقت الانتزاع هو نسبة الوقت الذي أمضته وحدة المعالجة المركزية الافتراضية في الانتظار قسراً بينما لم يقم الـhypervisor بجدولتها. وهو مؤشر مفيد إلى عدم توفر وقت المعالجة، لكنه لا يميّز بين الجيران الذين يستهلكون المعالجة بكثافة وبين فرض المزوّد لحصة المعالجة الخاصة بك.

vmstat 1 10

اقرأ العمود st الموجود على اليمين. يعني استمرار وقت الانتزاع أن وقت المعالجة لم يكن متاحاً للضيف، لكن تجاوز القيمة 5% لا يثبت أن المضيف يعاني من فرط الاشتراك. قد يعرض المزوّدون عمداً فرض حصة المعالجة على شكل وقت انتزاع. يعرض top الرقم نفسه الذي يعرضه %st في سطر CPU. اترك vmstat 1 قيد التشغيل في جلسة SSH ثانية أثناء إجراء اختبار الأداء، وسجّل قيمة الانتزاع بجانب نتيجة كل اختبار.

ابدأ باستخدام yabs.sh

yabs.sh (Yet Another Bench Script) هو برنامج shell يشغّل fio وiperf3 وGeekbench ويطبع ملخصاً واحداً. يستخدم fio وiperf3 إذا كانا مثبتين مسبقاً، وينزّل الملفات التنفيذية الثابتة إذا لم يكونا مثبتين. ويُعد اللغة المشتركة في نقاشات قياس أداء VPS، لذلك فإن مخرجات yabs هي أسرع طريقة لمقارنة النتائج مع شخص آخر.

الصيغة ذات السطر الواحد التي يوفّرها المشروع هي التالية.

curl -sL yabs.sh | bash

يمرّر هذا الأمر كل ما يقدّمه الرابط حالياً مباشرةً إلى shell. نزّل الملف واقرأه، ثم شغّله.

curl -sLo yabs.sh https://raw.githubusercontent.com/masonr/yet-another-bench-script/master/yabs.sh
less yabs.sh
bash yabs.sh

ضع الخيارات بعد -s -- عند استخدام pipe، أو مباشرةً بعد اسم الملف عند تشغيل نسخة محلية. الخيارات المفيدة هي: -f لتجاوز اختبار القرص، و-i لتجاوز اختبار الشبكة، و-g لتجاوز Geekbench، و-r لتقليل مواقع iperf3 إلى ثلاثة، و-j لطباعة النتائج بصيغة JSON، و-w results.json لكتابة JSON في ملف.

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

هناك أمران يجب معرفتهما قبل التشغيل الأول. يرفع Geekbench نتيجتك ويطبع رابطاً عاماً إلى browser.geekbench.com، لذلك يستطيع أي شخص يملك هذا الرابط قراءة طراز CPU ونتائج الاختبار. يتجاوز -g هذا الاختبار بالكامل. ثانياً، تنقل مرحلة iperf3 حركة مرور فعلية إلى خوادم في عدة مناطق، ويُحتسب ذلك من حصة bandwidth الشهرية. على اتصال بسرعة 1 Gbit/s، قد تنقل مرحلة الشبكة الكاملة عشرات gigabytes، لذلك استخدم -r إذا كانت الحصة صغيرة، واستخدم -i على اتصال تُحاسب فيه على حجم البيانات.

ماذا يعني كل جزء من مخرجات yabs

يشغّل قسم القرص fio بمزيج قراءة وكتابة بنسبة 50/50 باستخدام أربعة أحجام للكتل: 4k و64k و512k و1m. ويعرض IOPS، أي عدد عمليات الإدخال والإخراج في الثانية، وعرض النطاق الترددي لكل حجم. صف 4k هو الأهم لقاعدة البيانات أو خادم البريد أو أي خدمة تنفّذ عمليات كتابة صغيرة كثيرة، لأن معظم عمليات الإدخال والإخراج في الخوادم صغيرة ومتفرقة. أما صف 1m فهو الأنسب للنسخ الاحتياطية والفيديو، حيث تنقل سلاسل طويلة من وحدات البايت.

يشغّل قسم الشبكة iperf3 مقابل خوادم عامة في عدة مناطق، وفي الاتجاهين، باستخدام تدفقات متوازية. اعتبر الرقم المنخفض هنا سبباً لطرح سؤال، لا إجابة نهائية، لأن خوادم iperf3 العامة مشتركة وغالباً ما تكون مشبعة. لذلك قد يكون سبب النتيجة الضعيفة في الطرف البعيد.

يعرض قسم Geekbench نتيجة لنواة واحدة ونتيجة لعدة أنوية. وتوضح نتيجة النواة الواحدة مدى سرعة إكمال طلب واحد أو عملية ترجمة واحدة أو استعلام واحد. أما نتيجة عدة أنوية فتوضح غالباً عدد الأنوية التي حصلت عليها فعلياً.

القرص: شغّل 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، لذلك تتجاوز القراءات ذاكرة التخزين المؤقت للصفحات في النواة. من دونه، تُخدَّم الجولة الثانية على ملف بحجم 2G من الذاكرة على جهاز يملك 8G من RAM، ويبلغ fio عن IOPS بالملايين. هذا الرقم حقيقي، لكنه يقيس الذاكرة.
• --ioengine=libaio يرسل الطلبات غير المتزامنة، وهذا ما يتيح لـ --iodepth=32 إبقاء 32 طلباً قيد التنفيذ. عند استخدام محرك متزامن مثل psync، لا يفعل iodepth الأكبر من 1 أي شيء، لذلك تقيس طلباً واحداً في كل مرة.
• --time_based --runtime=60 يشغّل الاختبار لمدة ثابتة قدرها 60 ثانية بدلاً من كمية عمل ثابتة، لذلك يحصل القرص السريع والقرص البطيء على نفس زمن الساعة، وتبقى المقارنة عادلة.
• --size=2G يحدد حجم ملف الاختبار. أبقه أكبر من أي ذاكرة تخزين مؤقت في المسار، وتحقق أولاً من توفر المساحة الحرة.

الكتابة العشوائية تستخدم الأمر نفسه مع --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

لا تتوفر ميزة Direct IO على كل نظام ملفات. لذلك، عندما يفشل fio في أول طلب له مع ضبط --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 . أولاً. إنّ Type من overlay، وهو نظام الملفات الذي يمنحه Docker للحاوية افتراضياً، ليس سبب المشكلة بحد ذاته. يمرّر overlayfs قيمة O_DIRECT إلى نظام الملفات الأساسي، ويرفضها فقط عندما يتعذر على ذلك النظام تنفيذ Direct IO. لذلك يعمل --direct=1 --ioengine=libaio على overlay مبني فوق ext4 أو xfs. عندما يتعذر على نظام الملفات الأساسي للملف المختبَر تنفيذ Direct IO فعلاً، يعرض fio ذلك عادةً عند فتح الملف: fio: looks like your file system does not support direct=1/buffered=0. في هذه الحالة، وجّه --filename إلى مسار على وحدة تخزين محلية فعلية، مثل volume مربوط عبر bind mount، أو شغّل fio على المضيف بدلاً من تشغيله داخل الحاوية. وإذا تعذر الوصول إلى وحدة تخزين فعلية، فإن تشغيل buffered متزامن يثبت على الأقل أن الأمر نفسه صحيح.

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 بشكل صحيح. لا تعرضه أبداً على أنه نتيجة للقرص.

لماذا لا يُعدّ dd اختباراً لأداء القرص

يظهر dd في كثير من مواضيع VPS، وهو يجيب عن سؤال محدد واحد.

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

يقيس ذلك معدل نقل الكتابة التسلسلية باستخدام خيط واحد وطلب واحد قيد التنفيذ. وهو فحص معقول للتأكد من سلامة الأداء الأساسي. لكنه لا يخبرك بشيء عن عمليات الإدخال والإخراج العشوائية، ولا عن سلوك النظام عند وصول 32 طلباً في الوقت نفسه. عند حذف oflag=direct، تمر عمليات الكتابة عبر ذاكرة الصفحات المؤقتة، لكن conv=fdatasync يظل يفرض كتابة البيانات الناتجة إلى وحدة التخزين قبل انتهاء الأمر. وإذا حذفت ذلك أيضاً، فقد تقيس النتيجة في الغالب مدى سرعة قبول النواة لعمليات الكتابة في الذاكرة، ولذلك تكون قيم 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. شغّل الاختبار بخيط واحد أولاً. هذا هو الرقم الذي يحدد مدى سرعة اكتمال طلب PHP واحد أو مهمة compile واحدة، وهو الرقم الذي يختلف أكثر بين الخوادم ذات السعر نفسه. ثم شغّله باستخدام جميع الخيوط، لمعرفة كيفية توسّع معدل المعالجة عبر vCPUs المخصّصة لك.

يجب أن تكون واضحاً بشأن ما يقيسه هذا الاختبار: يبحث sysbench cpu بشكل متكرر عن الأعداد الأولية باستخدام القسمة التجريبية. ولكل عدد مرشح، يحسب الجذر التربيعي بدقة مزدوجة، ثم يختبر القواسم باستخدام عملية modulo على أعداد صحيحة بعرض 64 بت، ويقارن كل قاسم بالحد العائم. لذلك فهو يخلط بين عمليات على الأعداد الصحيحة وعمليات بالفاصلة العائمة. ولا يضغط على عرض نطاق الذاكرة أو وحدات المتجهات أو ذاكرة التخزين المؤقت بطريقة تشبه حمل عمل حقيقياً، لذلك فهو مناسب لترتيب خادمين، لكنه غير مناسب للتنبؤ بكيفية تشغيل تطبيقك.

تأتي 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"
  }
]

عادةً ما يحقق قرص NVMe محلي في النتائج المنشورة نحو 180,000 من IOPS للقراءة العشوائية بحجم 4k. أما SSD محلي من نوع SATA فيحقق نحو 90,000. ويحقق التخزين الكتلي المتصل بالشبكة، حيث يعبر كل طلب الشبكة قبل وصوله إلى القرص، نحو 12,000، بينما يحقق القرص الميكانيكي نحو 180، لأنه يحرك رأساً فعلياً لكل طلب عشوائي.

هذه أرقام منشورة نموذجية لكل فئة من فئات التخزين، وليست قياسات مأخوذة من خادم واحد. استخدمها لغرض واحد: التحقق من أن نتيجتك تقع ضمن نفس الرتبة التقريبية. إذا كان العرض المباع على أنه NVMe يحقق في الاختبار بضعة آلاف فقط من IOPS للقراءة بحجم 4k، فتحقق أولاً من أن --direct=1 كان مفعّلاً. إذا كان مفعّلاً، فتحقق من حدود IOPS للعرض ومن أرصدة الاندفاع، إضافةً إلى تنافس التخزين ومواصفات العتاد المعلنة.

لماذا لا يُعد تشغيل واحد معياراً للأداء

النتيجة الواحدة لقطة لمدة دقيقة واحدة على جهاز مشترك. تعامل معها على أنها عينة واحدة.

• شغّل كل اختبار خمس مرات على الأقل، ووزّع عمليات التشغيل على ساعات مختلفة وعلى يومين مختلفين على الأقل. احتفظ بالوسيط وبنطاق التباين. النتيجة المنشورة من دون نطاق تباين هي رقم تسويقي.
• سجّل زمن steal بجانب كل عملية تشغيل. احتفظ بعمليات التشغيل التي كانت فيها st مرتفعة، وتحقّق مما إذا كانت تعكس تنافساً على الموارد أو حصة CPU المخصصة للخطة؛ فقد يؤدي استبعادها إلى إخفاء الأداء الذي تحصل عليه فعلياً.
• شغّل اختبار القرص بمدتين مختلفتين. تمنح خطط كثيرة حصة burst من IOPS تُستعاد بمرور الوقت، لكن لا يضمن تشغيل fio لمدة 60 ثانية ولا --runtime=600 أنك قست الحد الأدنى للأداء. يمكن لأرصدة AWS gp2 أن تحافظ على 3,000 IOPS لمدة 30 دقيقة على الأقل عند اكتمال الرصيد، لذلك قد يقيس كلا التشغيلين أداء burst. تحقّق من نموذج الأرصدة لدى المزوّد، وراقب رصيد الاعتمادات قبل اعتبار النتيجة أداءً مستداماً.
• تحقّق من عدم تشغيل أي شيء آخر. إن بدء unattended-upgrades لمعاملة apt في منتصف اختبار CPU يخصم نقاطاً فعلية من نتيجتك، كما أن تنفيذ ps -e -o comm= | grep -E 'apt|dpkg' قبل كل عملية تشغيل يستغرق ثانية واحدة.
• غيّر متغيراً واحداً في كل مرة. تؤدي إصدارات الأدوات المختلفة أو أحجام الكتل أو أعداد مؤشرات الترابط إلى أرقام لا يمكن مقارنتها، مهما بدت متشابهة.

عندما تقارن بين مزودين، شغّل الاختبارات في الساعة نفسها من اليوم نفسه. وإلا فأنت تقيس وقت اليوم.

قِس أداء حملك الفعلي أخيراً

تُرتّب الأدوات الاصطناعية الأجهزة. لكن حملك الفعلي وحده يوضح ما إذا كان الجهاز كافياً. قِس زمن العملية التي تنفذها فعلياً.

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

تضغط هذه العملية بضع مئات من الميغابايت، ولذلك تختبر المعالج والقرص معاً، وتتغير نتيجتها عند تغير أيٍّ منهما. تحذير Removing leading / from member names طبيعي. والأفضل من ذلك أن تقيس زمن عملية البناء الخاصة بك، أو أبطأ استعلام لديك، أو عرض صفحتك الفعلي. إذا استغرقت عملية البناء 4 دقائق على أحد المضيفين و7 دقائق على مضيف آخر، فقد حُسم الأمر، بصرف النظر عما أظهره Geekbench. وهذا هو القياس الذي يوضح أيضاً متى لا تعود زيادة موارد الجهاز تستحق التكلفة، ومن المفيد معرفة ذلك قبل أن تقرأ التكلفة الشهرية الفعلية لـVPS أو تنقل حمل العمل إلى خادم مخصص.

FAQ

لماذا أحصل على نتيجة مختلفة لاختبار الأداء في كل مرة أشغّله فيها؟

يشترك VPS في وحدة المعالجة المركزية والتخزين والشبكة الفعلية مع مستأجرين آخرين، لذلك تعتمد نتيجتك على ما يفعلونه في تلك اللحظة. شغّل vmstat 1 أثناء الاختبار واقرأ عمود st: يسجّل وقت steal المستمر وقت وحدة المعالجة المركزية غير المتاح، لكنه قد يعكس تطبيق المزوّد لحصة وحدة المعالجة المركزية التي اشتريتها، كما قد يعكس تنافس الأحمال على المضيف. لا تثبت قيمة تتجاوز 5% السبب. الحل هو اتباع منهج ثابت، وليس ضبط الإعدادات. شغّل كل اختبار خمس مرات أو أكثر خلال ساعات مختلفة، ثم أبلغ عن الوسيط مع نطاق النتائج.

لماذا يعرض fio ملايين IOPS؟

السبب غالباً هو غياب --direct=1. من دونه يقرأ fio من ذاكرة التخزين المؤقت للصفحات في النواة، لذلك بعد المرور الأول يُخدَّم ملف اختبار بحجم 2G من RAM، وتكون قد قست عرض نطاق الذاكرة. أضف --direct=1 واجعل ملف الاختبار أكبر من أي ذاكرة تخزين مؤقت في المسار. إذا فشل --direct=1 بعد ذلك، فشغّل df -hT . وتحقق من طبقة التخزين التي يوجد عليها ملف الاختبار. لا تكون طبقة من النوع overlay هي المشكلة بحد ذاتها، لأن overlayfs يمرر O_DIRECT إلى وحدة التخزين الموجودة أسفلها. انقل ملف الاختبار إلى تخزين محلي فعلي فقط إذا رفض نظام الملفات الأساسي الإدخال والإخراج المباشر.

هل يكفي yabs.sh بمفرده؟

نعم، للحصول على نظرة أولية. يشغّل fio بأربعة أحجام للكتل، ويشغّل iperf3 في الاتجاهين، ويشغّل Geekbench، ثم يطبع ملخصاً يمكن للآخرين قراءته. لكنه لا يعود كافياً عندما تريد معرفة سبب نتيجة معينة، لأنك لا تستطيع تغيير خياراته لكل اختبار. عندما تبدو نتيجة yabs غير صحيحة، أعد الاختبار باستخدام fio أو sysbench مباشرة، وغيّر خياراً واحداً في كل مرة.

ما الرقم الوحيد الذي يتنبأ بإحساس أداء تطبيقي؟

سرعة النواة الواحدة لوحدة المعالجة المركزية، ثم زمن استجابة القراءة العشوائية بحجم 4k، بهذا الترتيب، لمعظم أحمال الويب وقواعد البيانات. تبدو أرقام معدل النقل مثيرة للإعجاب، لكنها نادراً ما تحسم شيئاً، لأن الطلب المعتاد صغير. أبلغ عن النسبة المئوية 99 من كتلة clat percentiles في fio بدلاً من المتوسط، لأن الطلب البطيء من كل 100 طلب هو ما يلاحظه المستخدم.

هل أحتاج إلى تثبيت أي شيء قبل إجراء اختبار الأداء؟

توجد fio وsysbench وiperf3 جميعاً في مستودعات Ubuntu وDebian: sudo apt install -y fio sysbench iperf3. يعمل yabs.sh في Bash ويحتاج إلى curl أو wget للتنزيلات، إضافة إلى tar لاستخراج Geekbench؛ ومن دون tar، يتخطى Geekbench. يستخدم fio وiperf3 عند تثبيتهما، وينزّل ملفات تنفيذية ثابتة عند غيابهما. احذف كل ملف اختبار بعد الانتهاء، لأن ترك ملف fio بحجم 2G على قرص سعته 20G سيتحول بعد أسابيع إلى تنبيه امتلاء القرص لدى شخص ما.