איך לבצע Benchmark לשרת VPS בצורה מקצועית

מה המשמעות של ביצוע Benchmark לשרת VPS

ביצוע Benchmark לשרת VPS מודד ארבעה פרמטרים: מהירות הליבה הבודדת של ה-CPU, רוחב הפס של הזיכרון, כמות פעולות הדיסק האקראיות הקטנות שהאחסון מסוגל לבצע בשנייה, וקצב העברת הנתונים של חיבור הרשת. הרצה אחת של yabs.sh תספק לכם תוצאות עבור ה-CPU, הדיסק והרשת בתוך כעשר דקות; השתמשו בבדיקת הזיכרון הנפרדת המופיעה בהמשך עבור רוחב פס של הזיכרון. החלק המורכב יותר הוא ניתוח התוצאות, כיוון ששרת VPS (שרת וירטואלי פרטי) חולק חומרה פיזית עם דיירים אחרים, ולכן אותו שרת יכול להציג נתון אחד בשעה 03:00 ונתון שונה מאוד בשעה 20:00.

התוכנית כאן היא להריץ את yabs.sh לקבלת תמונה מהירה, ולאחר מכן להריץ את הכלים שמתחתיו באופן ידני. הרצה עצמית של הכלים מאפשרת לכם לשנות flag מסוים, לצפות בשינוי בתוצאה, ולהבין מה הנתון הזה באמת מדד. בצעו זאת לאחר שהשרת הוגדר, ולא לפני כן. הצעדים ב-עשר הדקות הראשונות בשרת VPS חדש קודמים לכל, כיוון ששרת שעדיין מבצע את סבב העדכונים הראשון שלו יציג תוצאות Benchmark גרועות מסיבות שאינן קשורות לחומרה.

בחן את המכונה לפני שתמדוד אותה

מחצית מכל מדד ביצועים שגוי נובעת ממכונה שהכותב לא הבין.

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 משמעותה וירטואליזציה מבוססת מכולות: אתה חולק את הקרנל של המארח, ומגבלות ה-CPU והזיכרון שלך הן הגדרות cgroup (קבוצת בקרה) ולא חומרה וירטואלית. במערכת cgroup v2 ניתן לקרוא את מגבלת ה-CPU מתוך ה-cgroup של המכולה; הנתיב הבא תקף כאשר ה-cgroup מעוגן ב-/sys/fs/cgroup.

cat /sys/fs/cgroup/cpu.max

max 100000 משמעותו של-cgroup זה אין מכסה משלו; cgroups אבות עדיין יכולים להטיל אחת כזו. 200000 100000 משמעותו שניתן להשתמש ב-200000 מיקרו-שניות של CPU בכל תקופה של 100000 מיקרו-שניות, שהן מכסה השווה לשתי ליבות. תוכנית המשווקת כ-4 vCPU עם מכסה של שתי ליבות לעולם לא תשיג תוצאות של ארבע ליבות. כלי מדידת ביצועים יכולים לזהות את ההגבלה הזו: VoxelBench מדווח על מכסות CPU ומסמן CPU משותף או מוגבל כאשר המארח חושף הרבה יותר מעבדים ממה שהשרת רשאי לנצל.

df -hT / חשוב מסיבה אחרת: עמודת Type. אם מופיע בה overlay, אתה נמצא בתוך מכולה, ותוצאות הדיסק שלך יתארו את האחסון שנמצא מתחת ל-overlay הזה. רשום זאת כעת.

ניטור רציף של steal time

הערך steal time מייצג את משך הזמן שבו ה-vCPU שלכם המתין שלא מרצונו, בזמן שה-hypervisor לא הקצה לו משאבי עיבוד. זהו מדד שימושי לזיהוי חוסר בזמינות של זמן מעבד, אך הוא אינו מבחין בין עומס אצל שכנים בשרת לבין אכיפת מכסות מעבד על ידי ספק הענן.

vmstat 1 10

עקבו אחר העמודה st בצד ימין. ערך steal time מתמשך מעיד על כך שזמן מעבד לא היה זמין למערכת האורחת, אך ערך הגבוה מ-5% אינו מוכיח בהכרח שהשרת המארח סובל מ-oversubscription. ספקי ענן עשויים להציג אכיפת מכסות מעבד כ-steal time באופן מכוון. העמודה top מציגה את אותו נתון המופיע ב-%st בשורת ה-CPU. הריצו את vmstat 1 בחלון SSH נפרד בזמן ביצוע ה-benchmark, ותעדו את ערך ה-steal לצד כל תוצאה.

התחלה עם yabs.sh

yabs.sh (Yet Another Bench Script) הוא סקריפט shell המריץ את fio, iperf3 ו-Geekbench ומפיק סיכום אחד. הוא משתמש ב-fio וב-iperf3 אם הם כבר מותקנים, ומוריד קבצים בינאריים סטטיים אם אינם קיימים. זהו הסטנדרט המקובל לדיוני ביצועי 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

דגלים (flags) מתווספים אחרי -s -- בעת שימוש ב-pipe, או ישירות אחרי שם הקובץ בעת הרצה של עותק מקומי. הדגלים השימושיים הם: -f מדלג על בדיקת הדיסק, -i מדלג על בדיקת הרשת, -g מדלג על Geekbench, -r מצמצם את מיקומי ה-iperf3 לשלושה בלבד, -j מדפיס את התוצאות בפורמט JSON, ו--w results.json כותב את ה-JSON לקובץ.

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

שני דברים שכדאי לדעת לפני ההרצה הראשונה. Geekbench מעלה את התוצאה שלכם ומפיקה URL ציבורי ב-browser.geekbench.com, כך שכל מי שמחזיק בקישור יכול לראות את דגם המעבד והניקוד שלכם. -g מדלג על בדיקה זו לחלוטין. שנית, שלב ה-iperf3 מעביר תעבורה ממשית לשרתים באזורים שונים, וזה נספר כחלק ממכסת רוחב הפס החודשית שלכם. בחיבור של 1 Gbit/s, שלב רשת מלא יכול להעביר עשרות גיגה-בייטים, לכן השתמשו ב--r אם המכסה שלכם קטנה, וב--i אם החיבור שלכם מוגבל בנפח.

משמעות החלקים השונים בפלט של yabs

מקטע הדיסק מריץ את fio עם תמהיל קריאה וכתיבה של 50/50 בארבעה גדלי בלוקים: 4k, 64k, 512k ו-1m. הוא מדווח על IOPS (פעולות קלט/פלט לשנייה) ועל רוחב פס עבור כל אחד מהם. השורה של 4k היא השורה שחשוב להתמקד בה עבור מסד נתונים, שרת דואר, או כל יישום שמבצע כתיבות קטנות רבות, כיוון שרוב ה-IO בשרת הוא קטן ומבוזר. השורה של 1m מיועדת לגיבויים ולווידאו, שם מתבצעת העברה של רצפי בתים ארוכים.

מקטע הרשת מריץ iperf3 מול שרתים ציבוריים בכמה אזורים, בשני הכיוונים, תוך שימוש בזרמים מקבילים. התייחסו למספר נמוך כאן כאל סימן לשאלה ולא כתשובה סופית, כיוון ששרתי iperf3 ציבוריים הם משותפים ולעיתים קרובות עמוסים, כך שתוצאה גרועה עשויה לנבוע מהצד המרוחק.

מקטע ה-Geekbench מספק ציון לליבה בודדת וציון לריבוי ליבות. ציון ליבה בודדת חוזה כמה מהר תסתיים בקשה אחת, הידור (compile) אחד או שאילתה אחת. ציון ריבוי ליבות מעיד בעיקר על כמות הליבות האמיתית שעומדת לרשותכם.

דיסק: הרצת fio באופן עצמאי

fio (flexible IO tester) הוא הכלי שעומד מאחורי סעיף הדיסק ב-yabs, והפעלתו ישירות היא השלב שבו לדגלים (flags) מתחילה להיות משמעות.

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

בדיקת קריאה אקראית של 4k בעומק תור (queue depth) של 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 הוא הנתון שכדאי לצטט, כיוון שהוא מייצג את זמן ההמתנה של הבקשה האיטית ביותר מתוך מאה. השהיה ממוצעת (average latency) מסתירה בדיוק את העיכובים שהמשתמש מרגיש.

• --direct=1 פותח את הקובץ עם O_DIRECT, כך שהקריאות עוקפות את ה-page cache של ה-kernel. בלעדיו, מעבר שני על קובץ בגודל 2G במכונה עם 8G של RAM יוגש מהזיכרון, ו-fio ידווח על מיליוני IOPS. המספר הזה אמיתי, אך הוא מייצג ביצועי זיכרון.
• --ioengine=libaio מגיש בקשות אסינכרוניות, מה שמאפשר ל---iodepth=32 להחזיק 32 מהן בתהליך (in flight). עם מנוע סינכרוני כמו 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

אפשרות ה-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 על ה-host במקום בתוך המכולה. אם אין גישה לאחסון אמיתי, הרצה מסונכרנת עם buffer לפחות תוכיח שהפקודה עצמה תקינה.

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 מותקן ושהדגלים מפורשים כראוי. לעולם אל תציגו זאת כתוצאת ביצועי דיסק.

מדוע dd אינו כלי למדידת ביצועי דיסק

dd מופיע בשרשורים רבים בנושא VPS, והוא עונה על שאלה צרה אחת בלבד.

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

פקודה זו מודדת קצב כתיבה סדרתי (sequential write) עם thread אחד ובקשה אחת בתהליך. מדובר בבדיקת תקינות בסיסית סבירה. היא אינה אומרת דבר על 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 אחת או עבודת הידור (compile) אחת, והוא משתנה במידה הרבה ביותר בין מארחים באותו מחיר. לאחר מכן, הריצו עם כל השרשורים, מה שמראה כיצד התפוקה (throughput) משתנה בהתאם ל־vCPUs שהוקצו לכם.

היו ברורים לגבי מה שזה מודד: sysbench cpu מוצא מספרים ראשוניים שוב ושוב באמצעות חילוק ניסיוני. עבור כל מועמד, הוא מחשב שורש ריבועי בדיוק כפול (double precision), ולאחר מכן בודק מחלקים עם modulo של מספרים שלמים ב־64 ביט, תוך השוואת כל מחלק מול גבול הנקודה הצפה הזה. לכן, הבדיקה משלבת עבודה של מספרים שלמים ומספרים בנקודה צפה. היא אינה מאמצת את רוחב הפס של הזיכרון, את יחידות הווקטור או את ה־cache בשום צורה הדומה לעומס עבודה אמיתי, ולכן היא טובה לדירוג שני מארחים אך גרועה לניבוי אופן הפעולה של היישום שלכם.

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 המספר קורס, כיוון שאתם משלמים את ה-overhead של כל פעולה פי 1000 יותר, כך שבסופו של דבר אתם מודדים את עלות הלולאה ולא את רוחב הפס של הזיכרון. זהו ה-flag שבו טועים הכי הרבה בהשוואות ביצועי זיכרון מפורסמות.

רשת: iperf3

הדרך האמינה לבדיקת תפוקה (throughput) היא מול מכונה שנייה שבשליטתכם, שכן כך תדעו מה קורה בשני הקצוות.

בצד המרוחק:

iperf3 -s

פקודה זו מאזינה בפורט TCP 5201. פתחו את הפורט רק עבור הכתובת ממנה אתם מבצעים את הבדיקה, וסגרו אותו בסיום. המדריך כללי firewall בסיסיים ב-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

הפקודה הראשונה מודדת העלאה (upload) מהמכונה הנבדקת. הדגל -R הופך את כיוון הבדיקה, ובכך מודד הורדה (download). הדגל -P 8 פותח שמונה זרמים (streams) במקביל.

הריצו גם את הבדיקה בזרם בודד וגם את הגרסה המקבילית, שכן הן עונות על שאלות שונות. חיבור TCP בודד יכול להחזיק כמות נתונים לא מאושרים (unacknowledged data) בהתאם לגודל ה-window שלו, לכן התקרה שלו היא בערך גודל ה-window חלקי זמן הלוך-חזור (RTT). בשיהוי של 80 ms עם window של 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. כונן SATA SSD מקומי מגיע לסביבות ה-90,000. אחסון בלוקים מרושת (Network attached block storage), שבו כל בקשה חוצה רשת לפני שהיא מגיעה לדיסק, נמצא קרוב יותר ל-12,000, ודיסק מגנטי מסתובב מנהל בערך 180, כיוון שהוא מזיז ראש פיזי עבור כל בקשה אקראית.

אלו הם נתונים טיפוסיים שפורסמו עבור כל סוג אחסון, ולא מדידות ממארח יחיד. השתמשו בהם למטרה אחת בלבד: לוודא שהתוצאה שלכם נמצאת בסדר הגודל הנכון. אם תוכנית שנמכרת כ-NVMe מציגה בבדיקות ביצועים אלפים בודדים של 4k IOPS, ראשית ודאו ש---direct=1 היה פעיל. אם הוא היה פעיל, בדקו את מגבלות ה-IOPS ונקודות ה-burst של התוכנית, וכן את רמת העומס על האחסון ואת החומרה המוצהרת.

מדוע הרצה בודדת אינה נחשבת ל-benchmark

תוצאה בודדת היא תמונת מצב של דקה אחת על מכונה משותפת. התייחסו אליה כאל דגימה אחת בלבד.

• בצעו כל בדיקה לפחות חמש פעמים, בפריסה על פני שעות שונות ולפחות יומיים שונים. שמרו את החציון ואת טווח התוצאות. תוצאה שמפורסמת ללא טווח היא נתון שיווקי.
• תעדו את ה-steal time לצד כל הרצה. שמרו הרצות שבהן ה-st היה גבוה ובדקו האם הן משקפות עומס (contention) או את מכסת ה-CPU של התוכנית; פסילת הרצות אלו עלולה להסתיר את הביצועים שאתם מקבלים בפועל.
• בצעו את בדיקת הדיסק בשני משכי זמן. תוכניות רבות מעניקות מכסת IOPS לפרצי פעילות (burst) שמתמלאת עם הזמן, אך הרצת fio של 60 שניות או --runtime=600 אינן מבטיחות שמדדתם את רצפת הביצועים. ה-credits של AWS gp2 יכולים לתמוך ב-3,000 IOPS למשך 30 דקות לפחות מיתרה מלאה, כך ששתי ההרצות עלולות למדוד ביצועי burst בלבד. בדקו את מודל ה-credits של הספק ונטרו את יתרת ה-credits לפני שאתם מגדירים תוצאה כביצועים מתמשכים (sustained performance).
• ודאו ששום דבר אחר אינו רץ. unattended-upgrades שמתחיל טרנזקציית apt באמצע בדיקת CPU עולה לכם בנקודות ממשיות, ו-ps -e -o comm= | grep -E 'apt|dpkg' לפני כל הרצה גוזל זמן.
• שנו משתנה אחד בכל פעם. גרסאות שונות של כלים, גדלי בלוקים או מספר threads מפיקים מספרים שלא ניתן להשוות ביניהם, ללא קשר למידת הדמיון ביניהם.

כאשר אתם משווים בין שני ספקים, בצעו את הבדיקות באותה שעה ובאותו יום. אחרת, מדדתם את השפעת השעה ביום ולא את ביצועי השרת.

בצעו Benchmark לעומס העבודה שלכם בסוף

כלים סינתטיים מדרגים מכונות. רק עומס העבודה האישי שלכם יקבע אם מכונה מסוימת מספיקה לצרכיכם. מדדו את הפעולה שאתם מבצעים בפועל.

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

פעולה זו דוחסת כמה מאות מגה-בייטים, ולכן היא מפעילה את ה-CPU ואת הדיסק בו-זמנית ומשתנה כאשר אחד מהם משתנה. האזהרה Removing leading / from member names היא תקינה. עדיף מכך, מדדו את ה-build שלכם, את השאילתה האיטית ביותר שלכם, או את רינדור הדף שלכם. build שלוקח 4 דקות על שרת אחד ו-7 דקות על אחר מכריע את הסוגיה, ללא קשר למה ש-Geekbench הציג. זוהי גם המדידה שתבהיר לכם מתי תוספת כוח מחשוב מפסיקה להיות משתלמת, דבר שכדאי לדעת לפני שבודקים כמה VPS באמת עולה בחודש או מעבירים את עומס העבודה ל-שרת ייעודי.

FAQ

מדוע אני מקבל תוצאות benchmark שונות בכל הרצה?

שרת VPS חולק משאבי CPU, אחסון ורשת פיזיים עם דיירים אחרים, לכן התוצאה תלויה בפעילות שלהם באותו רגע. הריצו את vmstat 1 במהלך הבדיקה ועקבו אחר העמודה st: הערך steal time מתעד זמן CPU שלא היה זמין עבורכם, אך הוא עשוי לשקף גם אכיפה של הקצאת ה-CPU שרכשתם וגם עומס על השרת המארח. ערך הגבוה מ-5% אינו מעיד בהכרח על הגורם לבעיה. הפתרון הוא מתודולוגי ולא כוונון. בצעו כל בדיקה חמש פעמים או יותר בשעות שונות, ודווחו על החציון יחד עם טווח התוצאות.

מדוע fio מדווח על מיליוני IOPS?

כמעט תמיד בגלל שחסר --direct=1. בלעדיו, fio קורא דרך ה-page cache של ה-kernel, כך שאחרי המעבר הראשון, קובץ בדיקה בגודל 2G מוגש מה-RAM ומדדתם למעשה את רוחב הפס של הזיכרון. הוסיפו את --direct=1 ושמרו על קובץ הבדיקה גדול מכל cache בנתיב. אם --direct=1 נכשל לאחר מכן, הריצו את df -hT . ובדקו היכן קובץ הבדיקה מאוחסן. סוג overlay אינו הבעיה כשלעצמו, כיוון ש-overlayfs מעביר את O_DIRECT לאחסון שמתחתיו. העבירו את קובץ הבדיקה לאחסון מקומי אמיתי רק אם מערכת הקבצים שמתחת מסרבת לבצע direct IO.

האם yabs.sh מספיק כשלעצמו?

למבט ראשוני, כן. הוא מריץ fio בארבעה גדולי בלוקים, iperf3 בשני הכיוונים ו-Geekbench, ומפיק סיכום אחד שאחרים יכולים לקרוא. הוא מפסיק להספיק כאשר רוצים להבין מדוע מספר מסוים הוא כפי שהוא, כיוון שלא ניתן לשנות את ה-flags שלו עבור כל בדיקה בנפרד. ברגע שתוצאת yabs נראית שגויה, שחזרו אותה ישירות עם fio או sysbench ושנו flag אחד בכל פעם.

איזה מספר בודד מנבא כיצד היישום שלי ירגיש?

מהירות ליבה בודדת של ה-CPU וזמן השהיה (latency) של קריאה אקראית ב-4k, לפי סדר זה, עבור רוב עומסי העבודה של אתרי אינטרנט ומסדי נתונים. נתוני תפוקה (throughput) נראים מרשימים אך לעיתים רחוקות קובעים משהו, כיוון שבקשה טיפוסית היא קטנה. ציינו את האחוזון ה-99 מתוך בלוק ה-clat percentiles של fio במקום את הממוצע, שכן הבקשה האיטית האחת מתוך מאה היא זו שהמשתמש מרגיש.

האם עלי להתקין משהו לפני ביצוע ה-benchmark?

הכלים 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 הופך להתראת "דיסק מלא" עבור מישהו אחר בעוד מספר שבועות.