האם כדאי לבחור אחסון NVMe עבור שרת VPS?

האם ל-NVMe יש חשיבות ב-VPS?

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

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

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

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

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

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

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

אחסון בלוקים מבוסס רשת הוא מחלקה שלישית עם פיזיקה שונה. פעולת כתיבה עוברת ברשת אל אשכול אחסון ומקבלת אישור רק לאחר שהאשכול שמר אותה, לכן ההשהיה נמדדת במילי-שניות במקום במיקרו-שניות. מה שאתם מקבלים בתמורה להשהיה הזו הוא עמידות: הנפח (volume) שורד גם אם המארח שאליו הוא מחובר קורס, וניתן לבצע לו 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 פעולות קריאה אקראיות של 4k בשנייה (IOPS) בעומק תור של 32. אותה בדיקה על כונן SATA SSD מציגה נתון קרוב ל-90,000, המוגבל על ידי תור AHCI יחיד ורוחב פס של 6 Gbit/s. אחסון בלוקים ברשת מוגבל בדרך כלל על ידי ספק השירות ולא על ידי החומרה, ו-12,500 הוא תקרה מתועדת נפוצה.

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

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

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

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

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

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

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

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

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

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

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

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

הזרמת מדיה. זרם 4K אחד ב-40 Mbit/s קורא 5 MB/s. עשרה זרמים כאלה קוראים 50 MB/s, מה שגם אחסון בלוקים ברשת משרת ללא מאמץ. שרת מדיה Jellyfin על גבי VPS מוגבל על ידי מכסת התעבורה היוצאת מהרשת שלך, ועל ידי ה-CPU בעת קידוד מחדש (transcoding), ולא על ידי אמצעי האחסון.

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

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

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

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

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

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

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

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 עוקף את ה-page cache של מערכת ההפעלה האורחת, כך שהתוצאה משקפת את ההתקן עצמו ולא את ה-RAM שלכם. אם תשמיטו אותו, תמדדו את הזיכרון, מה שיניב מספר שאף דיסק לא יכול להגיע אליו. השתמשו ב---size=4G או בערך גדול יותר אם יש לכם מספיק מקום, שכן קובץ בגודל 1G עלול להיטען במלואו לתוך ה-cache של המארח ולהציג תוצאה מטעה לטובה.

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

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 ממתינה לאותו ה-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 בעומק תור (queue depth) של 32, עם שיהוי (latency) של פחות מ-0.3 ms בעומק תור 1, תואמים לביצועי זיכרון פלאש מקומי. שיהוי של מספר מילי-שניות בעומק תור 1 מעיד על נתיב רשת, ללא קשר לשם התוכנית. קריאות סדרתיות שנעצרות סביב 550 MB/s הן סימן היכר של חיבור SATA. מספר גבוה בהרבה ממה שכל התקן בודד יכול לספק מעיד על כך שקיים caching בנתיב, כמעט תמיד ברמת המארח (host).

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

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 שסובל מצוואר בקבוק בדיסק

עומס גבוה (load average) במערכת עם מעבד פנוי וערך wa גבוה ב-vmstat מעידים על תהליכים שממתינים בתור לדיסק. הסימן הברור ביותר מה-kernel הוא ההודעה הבאה ב-dmesg -T:

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

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

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

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

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

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

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

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

systemctl status fstrim.timer
sudo fstrim -av

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

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

בחירת תוכנית

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

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

FAQ

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

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

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

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

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

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

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

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

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

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