NVMe לעומת SSD ב-VPS: האם באמת יש הבדל?

האם NVMe חשוב ב-VPS?

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

מה NVMe משנה ומה לא

NVMe ‏(non-volatile memory express) אינו סוג של זיכרון flash. זהו הפרוטוקול והחיבור המשמשים לגישה אל ה-flash. התקן NVMe מחובר לנתיבי PCIe ‏(peripheral component interconnect express) ומשתמש בפרוטוקול NVMe. כונן SSD מסוג SATA ‏(serial ATA) מחובר בקישור SATA ומשתמש ב-AHCI ‏(advanced host controller interface). שבבי הזיכרון המאחסנים את הבתים שלכם יכולים להיות זהים בשני המקרים.

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

תורים. ‏AHCI מספק לליבה תור פקודות אחד המכיל 32 פקודות. ‏NVMe מאפשר אלפי תורים, ובפועל בדרך כלל תור אחד לכל ליבת CPU, כאשר כל תור עמוק בהרבה מ-32. תהליך אחד שקורא בלוק אחד בכל פעם אינו יכול להבחין בהבדל. מסד נתונים עם 64 פעולות קריאה ממתינות יכול להבחין בו: ב-SATA הבקשה ה-33 ממתינה למשבצת בתור עוד לפני שההתקן רואה אותה, ואילו התקן NVMe מקבל את כל הבקשות ומעבד אותן במקביל.

רוחב הקישור. קישור SATA III פועל במהירות של 6 Gbit/s, שהם בערך 550 MB/s של נתונים בפועל לאחר תקורת הפרוטוקול. זוהי תקרה קבועה, בלי קשר לסוג ה-flash שמאחוריו. ארבעה נתיבי PCIe מעבירים כמה גיגה-בתים בשנייה, ולכן הקישור מפסיק להיות הגורם המגביל.

זמן האחזור הוא המקום שבו הציפיות בדרך כלל שגויות. בעומק תור 1, כלומר בקשה יחידה שנמצאת בעיבוד, כונן SSD מסוג SATA מחזיר תשובה לקריאת 4k בתוך כ-100 עד 150 מיקרו-שניות. ‏NVMe מחזיר תשובה בתוך כ-80 עד 100 מיקרו-שניות. שניהם מהירים, ושום תוכנה שתפעילו לא תבחין בהבדל בעת טיפול בבקשה אחת. הפער מתרחב תחת עומס מקבילי. עומק התור, כלומר מספר הבקשות שנמצאות בעיבוד בו-זמנית, הוא ההגדרה שקובעת אם שני אמצעי האחסון ייראו דומים או שונים מאוד.

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

נתונים אופייניים שפורסמו: NVMe, SATA SSD ואחסון רשת

[
  {
    "disk": "Local NVMe SSD",
    "iops_4k_read": "184,000",
    "p99_latency_ms": 0.4,
    "seq_read_mbps": "3,400"
  },
  {
    "disk": "Local SATA SSD",
    "iops_4k_read": "90,000",
    "p99_latency_ms": 1.2,
    "seq_read_mbps": "550"
  },
  {
    "disk": "Network block storage",
    "iops_4k_read": "12,500",
    "p99_latency_ms": 6.5,
    "seq_read_mbps": "250"
  }
]

הביצועים המדווחים להתקן NVMe מקומי הם בדרך כלל 184,000 IOPS של קריאות אקראיות בגודל 4k (פעולות קלט/פלט בשנייה), בעומק תור 32. באותה בדיקה, SATA SSD מציג בדרך כלל כ-90,000, עקב תור AHCI יחיד וקישור במהירות 6 Gbit/s. אחסון בלוקים ברשת מוגבל בדרך כלל על-ידי הספק ולא על-ידי החומרה, ו-12,500 הוא תקרה מתועדת נפוצה.

זמן האחזור מציג את אותה תמונה ביחידה שהמשתמשים מרגישים. זמן האחזור בקריאת p99, כלומר זמן האחזור של האחוז האיטי ביותר של הבקשות, הוא בערך 0.4 ms ב-NVMe מקומי ו-1.2 ms ב-SATA. כאשר הרשת נמצאת בנתיב, הערך עולה ל-6.5 ms, כלומר יותר מפי עשרה מהערך של NVMe.

קריאות רציפות מציגות את הפער הגדול ביותר, אך הן המדד הכי פחות שימושי: 3,400 MB/s לעומת 550 MB/s. כמעט שום תהליך בשרת אינו קורא קובץ גדול יחיד מתחילתו ועד סופו במהירות מלאה. עמודת הגישה האקראית ועמודת זמן האחזור מתארות טוב יותר את הפעולות שמבצעים בפועל מסד נתונים, תור דואר או מנהל חבילות.

אילו עומסי עבודה מושפעים מהדיסק

כלל אחד מסביר את כולם: עומס עבודה מושפע מהדיסק רק כאשר הוא ממתין לדיסק. Linux שומר נתוני קבצים שנעשה בהם שימוש לאחרונה ב-RAM, במטמון הדפים, ולכן קריאה שנייה של קובץ אינה מגיעה כלל לאחסון. אם קבוצת העבודה, כלומר הנתונים שנמצאים בשימוש בפועל, מתאימה לנפח ה-RAM, הקריאות הופכות לקריאות זיכרון לאחר המעבר הראשון. כתיבות פועלות אחרת. כל כתיבה שהיישום מרוקן באמצעות fsync() חייבת להישמר באחסון יציב לפני שהיישום רשאי להמשיך.

עבודה שמבצעת commit. PostgreSQL, ‏MySQL ו-SQLite קוראים ל-fsync() או ל-fdatasync() בעת ביצוע commit, וכל commit ממתין לתגובת ההתקן. לכן קצב ה-commit של חיבור יחיד נקבע לפי זמן האחזור של הכתיבה, ולא לפי רוחב הפס. התקן שמרוקן את המטמון בתוך 0.2 ms מאפשר לבצע הרבה יותר commits בשנייה מהתקן שנדרש לו 5 ms, ושום כמות של תפוקה אינה משנה זאת. MySQL מציין זאת ביומן השגיאות כאשר פעולת הריקון אינה עומדת בקצב:

[Note] InnoDB: page_cleaner: 1000ms intended loop took 4589ms. The settings might not be optimal.

PostgreSQL מדווח על כך בשורות ה-checkpoint שלו, שבהן ערך sync= גדול מצביע על כך שהריקון עצמו היה איטי:

LOG:  checkpoint complete: wrote 8192 buffers (25.0%); write=27.694 s, sync=11.207 s, total=39.001 s

עבודה שניגשת לקבצים קטנים רבים. כל קובץ כולל פעולות מטא-נתונים, שאינן נדרשות בקריאה סדרתית אחת גדולה. npm install, ‏git clone של מאגר גדול, פריסת תמונות קונטיינר, מאגר דואר מסוג Maildir וגיבוי שסורק עץ גדול משקיעים את זמנם בגישה אקראית קטנה. משימת גיבוי restic ב-VPS קוראת ומחשבת גיבוב לכל קובץ שטרם נצפה, ולכן זמן השעון של גיבוי הכולל מיליון קבצים עוקב מקרוב אחר זמן האחזור של קריאות אקראיות. הדבר נכון גם לגבי du -sh, שקורא מטא-נתונים בלבד.

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

אילו עומסי עבודה אינם מושפעים מהדיסק

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

הזרמת מדיה. זרם 4K אחד בקצב של 40 Mbit/s קורא נתונים בקצב של 5 MB/s. עשרה זרמים קוראים נתונים בקצב של 50 MB/s, שגם אחסון בלוקים ברשת מספק ללא קושי. שרת מדיה Jellyfin על VPS מוגבל על ידי מכסת תעבורת היציאה מהרשת, ועל ידי המעבד בזמן המרת קידוד, ולא על ידי אמצעי האחסון.

הסקת מודלים מקומית. הפעלת Ollama על VPS לאירוח עצמי של LLM קוראת את קובץ המודל פעם אחת, ולאחר מכן פועלת בזיכרון RAM. NVMe מקצר את זמן הטעינה של מודל בנפח 20 GB מדקות לשניות. הוא אינו משנה את מספר האסימונים לשנייה, המוגבל על ידי רוחב הפס של הזיכרון ועל ידי המעבד.

כל פעולה שממתינה לשירות חיצוני. עובד שמקדיש 800 ms לכל משימה לבקשת HTTP לא יעבוד מהר יותר בדיסק טוב יותר.

מדוע ה-hypervisor חשוב לא פחות מהמדיה

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

אינכם יכולים לראות את המדיה מתוך ה-guest. lsblk -d -o NAME,ROTA,SIZE,MODEL מציג את vda עם דגם ריק, משום ש-virtio אינו מעביר את זהות הכונן. cat /sys/block/vda/queue/rotational מדווח על מה שה-hypervisor מפרסם, ולכן ערך 0 שם אינו הוכחה לשימוש ב-flash. nvme list, מהחבילה nvme-cli, אינו מציג דבר ברוב מופעי ה-VPS, גם כאשר השרת המארח מלא בכונני NVMe, משום שהדיסק שלכם הוא התקן virtio ולא התקן NVMe. תוכנית שמציינת NVMe מתארת בדרך כלל את רכיבי השרת המארח. ייתכן שה-volume שלכם עדיין מחובר דרך הרשת.

מצב המטמון בשרת המארח משפיע על התוצאות יותר מהמדיה. כאשר מופעל writeback caching בשרת המארח, פעולת fsync() של ה-guest יכולה להסתיים מיד לאחר שהשרת המארח שמר את הנתונים ב-RAM שלו. כך מתקבלת תוצאת benchmark שאף התקן פיזי אינו יכול לספק. המשמעות היא גם שקריסה של השרת המארח עלולה לגרום לאובדן כתיבות שבסיס הנתונים שלכם סבור שהן בטוחות. במצב מטמון none, התוצאות נמוכות יותר ומשקפות את הביצועים בפועל.

מגבלות וקרדיטי burst. ספקים רבים מגבילים את מספר ה-IOPS לכל volume או לכל תוכנית, ונפחי אחסון רבים ברשת משתמשים בהקצאת burst. הקצאת burst היא מאגר קרדיטים: ה-volume פועל במהירות כל עוד הקרדיטים זמינים, ולאחר מכן יורד למהירות בסיסית נמוכה בהרבה. קל לזהות את התסמין. פעולת import או restore פועלת במהירות במשך כמה דקות, ואז מואטת בחדות ונשארת איטית, בלי ששיניתם דבר בתצורה. ניצלתם את הקרדיטים.

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

כיצד למדוד את הדיסק שבפועל זמין ל-VPS שלך

התקן את fio, כלי הבנצ'מרק הסטנדרטי ל-IO, ובצע מדידה. תחילה, שלוש אזהרות. הבדיקה יוצרת קובץ, ולכן היא משתמשת בשטח דיסק ונכללת בכל מכסת IOPS שעליה מחייבים אותך. שמור על זמני ריצה קצרים. אל תפעיל אותה בעומק תור מלא מול אמצעי אחסון שמשרת תעבורת רשת פעילה, משום שתתחרה ביישום שלך על משאבי האחסון.

sudo apt update && sudo apt install -y fio ioping sysstat
cd /var/tmp

קריאה אקראית בעומק תור 32, שהוא העומק שספקים מציינים:

fio --name=randread --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 \
  --runtime=30 --time_based --group_reporting

השורה החשובה מתחילה ב-read:

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

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

עומק תור 1 מציג את זמן האחזור הגולמי, שהוא הזמן שתהליך בעל פתיל יחיד חווה:

fio --name=lat --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based

בדיקת ה-commit מנבאת את התנהגות מסד הנתונים. היא כותבת 4k וקוראת ל-fdatasync() לאחר כל כתיבה, ולכן הקצב המדווח כולל את פעולת ה-flush:

fio --name=commit --filename=fio.test --size=1G --bs=4k --rw=randwrite \
  --ioengine=psync --fdatasync=1 --runtime=30 --time_based
rm -f fio.test

נתון ה-IOPS מהרצה זו קרוב למספר המרבי של עסקאות קטנות לשנייה שחיבור אחד למסד הנתונים יכול לבצע להן commit, משום שפעולת commit ממתינה לאותו flush.

לדגימה מהירה ללא fio:

ioping -c 20 .

--- . (ext4 /dev/vda1) ioping statistics ---
19 requests completed in 4.13 ms, 76 KiB read, 4.60 k iops, 17.9 MiB/s
min/avg/max/mdev = 174.2 us / 217.6 us / 386.1 us / 51.3 us

הערך mdev, הסטייה הממוצעת, חשוב לא פחות מהממוצע. סטייה גדולה בשרת לא פעיל מצביעה על כך שמערכת האחסון משותפת ועמוסה.

כיצד לקרוא את התוצאה

נכון ליולי 2026, אלה ערכים סבירים עבור VPS קטן. עשרות אלפי IOPS של קריאה אקראית בגודל 4k ובעומק תור של 32, עם השהיה בעומק תור 1 הנמוכה מכ-0.3 ms, תואמים לאחסון Flash מקומי. השהיה של כמה מילישניות בעומק תור 1 מצביעה על נתיב רשת, בלי קשר לשם החבילה. קריאות סדרתיות שנעצרות בקרבת 550 MB/s הן סימן לקישור SATA. ערך גבוה בהרבה מהיכולת של התקן יחיד כלשהו מצביע על כך שמנגנון מטמון נמצא בנתיב, כמעט תמיד אצל המארח.

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

iostat -x 1 3
vmstat 1 5
cat /proc/pressure/io

בפלט של iostat -x, קראו את r_await ואת w_await, שהם מספר המילישניות הממוצע שבהן בקשה המתינה, ואת aqu-sz, שהוא אורך התור הממוצע. התעלמו מ-%util בדיסק וירטואלי. ערך זה מציג את שיעור הזמן שבו לפחות בקשה אחת הייתה בטיפול, אך אינו אומר דבר על רוויה בהתקן שמטפל בבקשות רבות בו-זמנית. לכן ערך %util של 100 לצד ערך r_await של 0.2 ms מצביע על דיסק עסוק אך תקין. ב-vmstat, העמודה wa מציגה את אחוז זמן ה-CPU שהוקדש להמתנה ל-IO. אם /proc/pressure/io קיים ב-kernel שלכם, הערך some avg10= שלו מציג את שיעור 10 השניות האחרונות שבהן לפחות משימה אחת הייתה תקועה בהמתנה ל-IO. זהו המדד הישיר ביותר לשאלה אם האחסון הוא צוואר הבקבוק שלכם.

כיצד נראה VPS המוגבל על ידי הדיסק

ממוצע עומס גבוה, כאשר המעבד במצב סרק, וערך wa גדול ב-vmstat, מצביעים על כך שתהליכים ממתינים מאחורי הדיסק. האות הברור ביותר מהליבה הוא ההודעה הזו ב-dmesg -T:

INFO: task jbd2/vda1-8:194 blocked for more than 120 seconds.

השורה הזו מופיעה מכיוון שפתיל ליבה המתין יותר משתי דקות לתשובת מערכת האחסון, ולכן מנגנון הניטור של משימות תקועות בליבה תיעד אותה. jbd2 הוא פתיל היומן של ext4, ולכן המשמעות היא שמערכת הקבצים כולה המתינה, ולא תוכנית אחת שהתנהגה באופן חריג. ב-VPS הדבר מצביע בדרך כלל על תשתית האחסון או על מכסת IOPS שמוצתה.

התסמינים ברמת היישום תואמים לאותו דפוס. זמן התגובה החציוני נשאר סביר, בעוד שהבקשות האיטיות ביותר יוצרות זנב ארוך, מכיוון שרק הבקשות שניגשות לדיסק מושפעות מהעיכוב. apt upgrade נשאר ב- Unpacking במשך דקות, מכיוון ש-dpkg מבצע flush במהלך הכתיבה. git status במאגר גדול נמשך שניות. אלה עלויות של מטא-נתונים ושל flush, ולכן רוחב פס גדול יותר לא יעזור.

מה לעשות כאשר הדיסק הוא צוואר הבקבוק

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

צמצמו את מספר פעולות ה-flush, כאשר הנתונים מאפשרים זאת. ב-PostgreSQL, synchronous_commit = off מאפשר לפעולת commit להסתיים לפני שהכתיבה נמצאת בדיסק. אם השרת קורס, אתם עלולים לאבד את השבריר האחרון של השנייה בעסקאות. מסד הנתונים אינו נפגם, מכיוון שה-write-ahead log עדיין נכתב לפי הסדר. הפשרה הזו מתאימה לעותק לצורכי ניתוח, אך אינה מתאימה לתשלומים. innodb_flush_log_at_trx_commit = 2 ב-MySQL מספק את אותה פשרה.

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

השאירו את מנגנון ה-discard פעיל באמצעי אחסון דקים. באחסון בהקצאה דקה, מערכת האחסון העורפית אינה יודעת שבלוק פנוי עד שמערכת הקבצים מודיעה לה על כך. אמצעי אחסון שאינו מבצע trim מאבד בהדרגה את ביצועי הכתיבה. Ubuntu מספקת עבור זאת טיימר שבועי:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av מדפיס את מספר הבתים שנמחקו בכל נקודת עגינה. הודעה שלפיה פעולת ה-discard אינה נתמכת פירושה שהדיסק הווירטואלי אינו מעביר את פעולת ה-discard למארח, ולכן אין דבר שעליכם לתקן.

דלגו על כוונון מתזמן ה-IO. בדיסק virtio, cat /sys/block/vda/queue/scheduler מציג בדרך כלל שכבר מוגדר none, והתזמון בפועל מתבצע במארח, שאליו אין לכם גישה. דלגו גם על noatime: Ubuntu מבצעת עגינה עם relatime כברירת מחדל, וכך נמנעות כמעט כל כתיבות ה-atime.

בחירת תוכנית

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

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

FAQ

האם NVMe תמיד מהיר יותר מ-SSD מסוג SATA ב-VPS?

לא. בעומק תור 1 הביצועים דומים, בערך 80 עד 150 מיקרו-שניות לקריאת 4k, ותוכנית בעלת פתיל ביצוע יחיד אינה יכולה להבחין ביניהם. NVMe מוביל כאשר בקשות רבות נמצאות בטיפול במקביל, משום ש-AHCI מספק תור אחד בעומק של 32 פקודות, ואילו NVMe מספק אלפי תורים עמוקים יותר. במארח משותף, העומס של אורחים אחרים עשוי לשנות את זמן ההשהיה שלך יותר מסוג אמצעי האחסון, לכן מדוד את אמצעי האחסון שלך באמצעות fio במקום להסתמך על שם החבילה.

כיצד ניתן לבדוק אם ה-VPS שלי אכן משתמש ב-NVMe?

אי-אפשר לבדוק זאת ישירות, משום ש-virtio מסתיר את ההתקן הפיזי. lsblk מציג את vda ללא מחרוזת דגם, nvme list אינו מחזיר דבר, ו-/sys/block/vda/queue/rotational מדווח רק על מה שה-hypervisor מפרסם. במקום זאת, מדוד את ההתנהגות. קריאת 4k אקראית בעומק תור 1, עם זמן השהיה הנמוך מ-0.3 ms, מעידה על אחסון Flash מקומי. זמן של כמה מילי-שניות מעיד על כך שקפיצת רשת נמצאת בנתיב. קריאות סדרתיות שנעצרות בקרבת 550 MB/s מעידות על קישור SATA.

האם NVMe גורם לאתר שלי להיטען מהר יותר?

בדרך כלל לא. לאחר הבקשה הראשונה, Linux מגיש את הקבצים מ-page cache שב-RAM, ולכן הדיסק מפסיק לפעול. מהירות הדף ב-VPS קטן מוגבלת בדרך כלל על ידי זמן המעבד של היישום ועל ידי רוחב הפס. הדיסק חוזר לנתיב הקריטי אם האתר כותב בכל בקשה, למשל עגלת קניות המבוססת על מסד נתונים שמבצעת commit לעיתים קרובות, משום שכל commit ממתין להשלמת flush.

מהי תוצאת fio טובה עבור VPS?

נכון ליולי 2026, VPS קטן על גבי Flash מקומי מחזיר בדרך כלל עשרות אלפי IOPS של קריאות 4k אקראיות בעומק תור 32, עם זמן השהיה בעומק תור 1 הנמוך מ-0.3 ms. אחסון בלוקים ברשת מחזיר בדרך כלל כמה אלפי IOPS, עם זמן השהיה של כמה מילי-שניות. הרץ את הבדיקה 3 פעמים בשעות שונות. פער גדול בין ההרצות מלמד יותר מהממוצע, משום שהוא מראה באיזו מידה האורחים האחרים במארח משפיעים עליך.

האם כדאי למקם את מסד הנתונים שלי באחסון בלוקים ברשת?

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