איך לבדוק ביצועי VPS בצורה נכונה עם yabs.sh

מה פירוש ביצוע מבחן ביצועים ל-VPS

כדי לבצע מבחן ביצועים ל-VPS, מודדים ארבעה דברים: את מהירות הפעולה של ליבת CPU יחידה, את רוחב הפס של הזיכרון במכונה, את מספר פעולות הדיסק האקראיות הקטנות שהאחסון משרת בכל שנייה, ואת קצב העברת הנתונים שמספק קישור הרשת. הרצה אחת של yabs.sh מספקת את כל ארבעת המדדים בתוך כעשר דקות. החלק הקשה יותר הוא פירוש התוצאה, משום ש-VPS (שרת פרטי וירטואלי) חולק חומרה פיזית עם לקוחות אחרים. לכן אותה מכונה עשויה לדווח על ערך מסוים בשעה 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 פירושו וירטואליזציה מלאה, ולכן אתם מפעילים ליבה משלכם. הדפסת lxc או openvz של systemd-detect-virt פירושה וירטואליזציה באמצעות מכולות: אתם משתפים את ליבת המארח, ומגבלות המעבד והזיכרון שלכם מוגדרות באמצעות cgroup (קבוצת בקרה), ולא באמצעות חומרה וירטואלית. במערכת עם cgroup v2 אפשר לקרוא ישירות את מגבלת המעבד.

cat /sys/fs/cgroup/cpu.max

max 100000 פירושו שאין מכסה. 200000 100000 פירושו שמותר לכם להשתמש ב-200000 מיקרו-שניות של מעבד בכל פרק זמן של 100000 מיקרו-שניות, כלומר מכסה השקולה ל-2 ליבות. תוכנית המשווקת כ-4 vCPU עם מכסה של 2 ליבות לעולם לא תקבל תוצאה השקולה ל-4 ליבות, ואף כלי לבדיקת ביצועים לא ידפיס שורה שמסבירה מדוע.

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

ניטור זמן steal לאורך כל הבדיקה

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

vmstat 1 10

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

מתחילים עם yabs.sh

yabs.sh (Yet Another Bench Script) הוא סקריפט מעטפת שמוריד קבצים בינאריים סטטיים של fio, ‏iperf3 ו-Ge​​ekbench, מריץ אותם ומציג סיכום אחד. זהו אמצעי התקשורת המקובל בדיונים על ביצועי VPS, ולכן פלט של yabs הוא הדרך המהירה ביותר להשוות תוצאות עם משתמש אחר.

הפקודה החד-שורתית הרשמית של הפרויקט היא:

curl -sL yabs.sh | bash

פקודה זו מעבירה ישירות למעטפת את התוכן שה-URL מחזיר באותו רגע. הורידו את הקובץ, קראו אותו ורק לאחר מכן הריצו אותו.

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

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

דיסק: הפעילו את fio בעצמכם

fio (‏flexible IO tester‏) הוא הכלי שמופעל מאחורי מקטע הדיסק של 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, עומק תור גדול מ-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 לבין אחסון SSD מסוג SATA ב-VPS.

כאשר fio נעצר עם Unknown error -1

קלט/פלט ישיר אינו זמין בכל מערכת קבצים. overlay, מערכת הקבצים ש-Docker מקצה למכולה כברירת מחדל, וכמה מערכות קבצים ברשת אינן תומכות ב-O_DIRECT. לכן libaio שולח בקשה שהליבה אינה יכולה להשלים, ו-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 לנתיב באחסון אמיתי, כגון אמצעי אחסון שמחובר באמצעות 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 נמצא במטמון הדפים, ולכן נתון ה-IOPS מתאר את זיכרון ה-RAM שלכם. השתמשו בהרצה זו כדי לוודא ש-fio מותקן ושהדגלים מפוענחים כראוי. לעולם אל תציגו אותה כתוצאה של ביצועי דיסק.

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

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

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

הפקודה מודדת קצב כתיבה רציפה באמצעות thread אחד ובקשה אחת פעילה בכל רגע. זו בדיקת תקינות סבירה. היא אינה אומרת דבר על קלט/פלט אקראי, ואינה מראה מה קורה כאשר 32 בקשות מגיעות בו-זמנית. הסרת oflag=direct גורמת לכך שהמדידה בודקת בעיקר באיזו מהירות הליבה מקבלת כתיבות לזיכרון, ולכן הערכים של 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 אחת או עבודת קומפילציה אחת, והוא משתנה במידה הרבה ביותר בין שרתים באותו מחיר. לאחר מכן הפעילו את הבדיקה עם כל התהליכונים. כך ניתן לראות אם ה־vCPU שלכם הם ליבות נפרדות או פרוסות של ליבה אחת.

חשוב להבהיר מה הבדיקה מודדת: sysbench cpu מאתר שוב ושוב מספרים ראשוניים באמצעות חשבון שלם ברוחב 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 המספר צונח, משום שתקורת הפעולה משולמת פי 1,000 בתדירות גבוהה יותר. לכן אתם מודדים את עלות הלולאה במקום את רוחב הפס של הזיכרון. זהו הדגל שאינו תואם לרוב בפרסומי תוצאות בדיקות הזיכרון.

רשת: 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, בלי קשר למהירות הקישור בפועל. התוצאה של הזרם הבודד מראה מה תקבל הורדה אחת. התוצאה המקבילית מראה את קיבולת הקישור.

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

מדוע הרצה אחת אינה מדד ביצועים

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

• הריצו כל בדיקה לפחות חמש פעמים, בפריסה על פני שעות שונות ולפחות יומיים שונים. שמרו את החציון ואת הפיזור. תוצאה שמפורסמת ללא פיזור היא נתון שיווקי.
• תעדו את זמן ה-steal לצד כל הרצה. השליכו הרצות שבהן st היה גבוה, או ציינו זאת לכל הפחות.
• הריצו את בדיקת הדיסק בשני משכי זמן. תוכניות רבות מקצות מכסת IOPS מתפרצת שמתמלאת מחדש עם הזמן, לכן הרצת fio שאורכה 60 שניות מודדת את ההתפרצות, ואילו --runtime=600 מודד את הרצפה. הרצפה היא הביצועים שתקבלו ביום גרוע.
• ודאו ששום דבר אחר אינו פועל. unattended-upgrades שמתחיל עסקת apt באמצע בדיקת CPU עולה לכם בנקודות ביצועים אמיתיות, ו-ps -e -o comm= | grep -E 'apt|dpkg' לפני כל הרצה נמשך שנייה.
• שנו משתנה אחד בכל פעם. גרסאות שונות של כלים, גדלי בלוקים או מספרי thread-ים מפיקות מספרים שאי-אפשר להשוות, גם אם הם נראים דומים מאוד.

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

בצעו את הבנצ'מרק לעומס העבודה שלכם רק בסוף

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

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 נכשל לאחר מכן עם err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1, הריצו את df -hT .: Type של overlay אינו תומך ב־O_DIRECT, ולכן יש להפנות את הבדיקה לאחסון אמיתי.

האם yabs.sh מספיק בפני עצמו?

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

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

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

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

fio, sysbench ו־iperf3 זמינים כולם במאגרים של Ubuntu ושל Debian: sudo apt install -y fio sysbench iperf3. yabs.sh דורש רק את curl, משום שהוא מוריד קבצים בינאריים סטטיים עבור כל רכיב חסר. מחקו כל קובץ בדיקה לאחר שתסיימו, מכיוון שקובץ fio בגודל 2G שנשאר בדיסק בנפח 20G יהפוך כעבור כמה שבועות להתראת "הדיסק מלא" של מישהו.