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

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

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

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

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

חצי מכל 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 (קבוצת בקרה) ולא חומרה וירטואלית. במערכת cgroup v2 ניתן לקרוא את מגבלת ה-CPU ישירות.

cat /sys/fs/cgroup/cpu.max

max 100000 משמעותו שאין מכסה (quota). 200000 100000 משמעותו שניתן להשתמש ב-200000 מיקרו-שניות של CPU בכל תקופה של 100000 מיקרו-שניות, שהן מכסה השווה לשתי ליבות. תוכנית המשווקת כ-4 vCPU עם מכסה של שתי ליבות לעולם לא תשיג תוצאות של ארבע ליבות, ואף כלי benchmark לא ידפיס שורה שמסבירה לכם מדוע.

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

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

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

vmstat 1 10

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

התחלה עם yabs.sh

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

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

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

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

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

היו ברורים לגבי מה שהבדיקה הזו מודדת: sysbench cpu מוצא שוב ושוב מספרים ראשוניים באמצעות חשבון מספרים שלמים של 64 bit. הבדיקה אינה מאמצת את רוחב הפס של הזיכרון, את יחידות הווקטור או את ה-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 של כל פעולה פי אלף יותר פעמים, כך שבסופו של דבר אתם מודדים את עלות הלולאה ולא את רוחב הפס של הזיכרון. זהו הדגל (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, ודיסק מסתובב (HDD) מנהל בערך 180, כיוון שהוא מזיז ראש פיזי עבור כל בקשה אקראית.

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

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

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

• בצעו כל בדיקה לפחות חמש פעמים, בפריסה על פני שעות שונות ולפחות יומיים שונים. שמרו את החציון ואת טווח התוצאות. תוצאה שמפורסמת ללא טווח היא נתון שיווקי.
• תעדו את ה-steal time לצד כל הרצה. פסלו הרצות שבהן ה-st היה גבוה, או לכל הפחות ציינו זאת.
• בצעו את בדיקת הדיסק בשני משכי זמן. תוכניות רבות מעניקות מכסת IOPS לפרצי פעילות (burst) שמתמלאת מחדש עם הזמן; לכן, הרצת fio של 60 שניות מודדת את ה-burst, בעוד ש---runtime=600 מודד את רף הביצועים המינימלי. הרף המינימלי הוא מה שתקבלו ביום עמוס.
• ודאו ששום דבר אחר אינו רץ ברקע. הפעלת טרנזקציית apt ב-unattended-upgrades באמצע בדיקת CPU תעלה לכם בנקודות ביצועים אמיתיות, וביצוע sync ב-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 עקבי מעל 5 מעיד על עומס במארח, וציון ה-CPU שלכם נמוך מסיבות שאינן תלויות במכונה שלכם. הפתרון הוא מתודולוגי ולא קשור לכוונון. בצעו כל בדיקה חמש פעמים או יותר בשעות שונות, ודווחו על החציון יחד עם טווח התוצאות.

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

כמעט תמיד בגלל שחסר --direct=1. בלעדיו, fio קורא דרך ה-page cache של ה-kernel, כך שאחרי המעבר הראשון קובץ בדיקה של 2G מוגש מה-RAM ואתם מודדים רוחב פס של זיכרון. הוסיפו --direct=1 ושמרו על קובץ הבדיקה גדול מכל cache בנתיב. אם --direct=1 נכשל עם err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1, הריצו את df -hT .: מערכת קבצים מסוג Type בגרסת overlay אינה תומכת ב-O_DIRECT, לכן כוונו את הבדיקה לאחסון פיזי אמיתי.

האם 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 דורש רק את curl, כיוון שהוא מוריד קבצים בינאריים סטטיים עבור כל מה שחסר. מחקו כל קובץ בדיקה בסיום, כיוון שקובץ fio בגודל 2G שנשאר על דיסק של 20G יהפוך להתראת "דיסק מלא" עבור מישהו אחר בעוד שבועות.