CPU Steal Time ב‑VPS: איך למדוד מכירת יתר של שרתים

Steal time הוא אחוז הזמן שבו המכונה הווירטואלית שלכם הייתה מוכנה לרוץ ולא קיבלה מעבד פיזי, כי השרת שמתחתיה היה עסוק בהרצת משהו אחר. קוראים אותו בעמודת st של top, vmstat או mpstat. פחות מאחוז אחד באופן עקבי זה בריא. בין אחוז לחמישה אחוזים זה שגרתי בשרת עם vCPU משותף. מעל עשרה אחוזים לאורך שעות פירושו שהמכונה הפיזית נמכרה יתר על המידה, ואתם משלמים על מעבד שאתם לא מקבלים.

זו התשובה הקצרה. הנה הארוכה, מחברה שמוכרת VPS ולכן יש לה אינטרס ברור לא לכתוב אותה: כל ספק שמוכר vCPU משותף עושה מכירת יתר במידה כלשהי. זה מה שמאפשר לשרת ב‑3.49 דולר להתקיים בכלל. השאלה מעולם לא הייתה אם הספק שלכם מוכר ביתר. השאלה היא בכמה, והאם אפשר למדוד את זה. steal time הוא המדידה, והוא עובד על המכונות שלנו בדיוק כמו על של כל אחד אחר.

נקודות מפתח

• steal time סופר רק המתנה כפויה. זמן סרק לא נספר, ולכן כל ערך מעל אפס אומר שבאמת רצית מעבד ונאלצת לחכות בתור.
• ארבע דרכים לקרוא אותו: השדה st ב‑top, העמודה st ב‑vmstat 1 30, %steal ב‑mpstat -P ALL, והמונה השמיני בשורת cpu של /proc/stat אם רוצים לכתוב סקריפט.
• טווחי האחוזים שכולם מצטטים הם כלל אצבע, לא תקן. אין מסמך ליבה, RFC או SLA שמגדיר steal time "תקין".
• דגימה של שלושים שניות לא מוכיחה כלום. מכירת היתר מורגשת הכי חזק בשעות השיא, אז תעדו 24 שעות ותסתכלו על ההתפלגות, לא על הממוצע.
• steal קרוב לאפס לא אומר שה‑VPS מהיר. השהיית דיסק, מהירות ליבה בודדת, זמני רשת ומחסור ב‑workers של PHP‑FPM גורמים לאיטיות ש‑steal time לא רואה.
• vCPU ייעודי שווה את התוספת לעומסי מעבד מתמשכים: ראנרים של CI, קידוד וידאו, שרתי משחקים ומסדי נתונים עמוסים. לרוב אחסון האתרים זו הוצאה מיותרת.

מה זה steal time באמת

ה‑VPS שלכם הוא לא מחשב. הוא תהליך על המחשב של מישהו אחר. כל vCPU הוא thread על השרת הפיזי, והמתזמן של המארח מחליט מתי ה‑thread הזה ירוץ, בדיוק כמו שהקרנל שלכם מחליט מתי nginx ירוץ ומתי MySQL.

כשה‑thread שלכם מוכן לרוץ והמתזמן של המארח עוד לא הושיב אותו על ליבה פיזית, ההמתנה הזו היא steal time. התיעוד הרשמי של הקרנל ל‑/proc/stat מתאר את השדה בשתי מילים: המתנה כפויה. הניסוח מדויק. המכונה שלכם לא בחרה לחכות. הייתה לה עבודה בתור והחומרה הייתה עסוקה במקום אחר.

מה ההיפרוויזור עושה בזמן שה‑steal נצבר

ב‑KVM, שעליו רץ רוב שוק ה‑VPS המודרני, זה לא ניחוש של האורח אלא מספר שההיפרוויזור מוסר. הקרנל האורח רושם מבנה זיכרון משותף מול המארח דרך MSR פאראוירטואלי, שתיעוד הקרנל מגדיר כ‑MSR_KVM_STEAL_TIME. ההגדרה שם היא "כמות הזמן שבה ה‑vCPU הזה לא רץ, בננושניות", ובהמשך מופיע התנאי הקריטי: זמן שבו ה‑vCPU במצב סרק לא ידווח כ‑steal time.

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

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

שנית, החישוב תלוי בכך שההיפרוויזור חושף אותו. זו תכונה פאראוירטואלית שמסוכמת דרך ביט ב‑CPUID. אם הפלטפורמה שמתחתיכם לא חושפת steal time, האורח ידווח אפס לנצח גם תחת עומס כבד. הריצו systemd-detect-virt כדי לראות על מה אתם באמת יושבים. אם הפלט הוא kvm או xen, המדד רלוונטי. אם הפלט הוא lxc או סוג קונטיינר אחר, אתם בכלל לא על היפרוויזור ו‑steal time הוא הכלי הלא נכון.

מה זה vCPU משותף בפועל

שרת פיזי יכול לשאת, למשל, שני מעבדי Intel Xeon Gold 6138. המפרט הרשמי של אינטל לדגם הזה הוא 20 ליבות ו‑40 threads, בסיס 2.00 גיגה‑הרץ ו‑3.70 בטורבו. מכונה דו‑שקעית מציגה אם כך 80 threads. אם כל vCPU שנמכר היה מוצמד אחד לאחד ל‑thread פיזי, אפשר היה לארח בדיוק 80 מכונות של ליבה אחת, והמחיר היה נראה אחרת לגמרי.

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

הבעיה נוצרת במצב אחד בדיוק: כשמספיק דיירים רוצים מעבד בו זמנית והתור מתארך. אז ה‑steal מופיע אצלכם, ורינדור עמוד שלוקח בדרך כלל 180 מילישניות לוקח 400.

איך בודקים steal time ב‑VPS

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

1. top, למבט של חמש שניות

הריצו top וקראו את השורה שמתחילה ב‑%Cpu(s):. השדות מופיעים בסדר קבוע: us, sy, ni, id, wa, hi, si ולבסוף st, שדף ההסבר מגדיר כזמן שנגנב מהמכונה הווירטואלית על ידי ההיפרוויזור.

לחצו 1 כדי לפצל את הסיכום לשורה לכל vCPU. זה חשוב יותר ממה שנשמע. ה‑steal המצרפי ממוצע על כל הליבות, ולכן בחבילה של 4 vCPU ליבה אחת שמורעבת לגמרי מוצגת כ‑25 אחוז מצרפיים. התצוגה לפי ליבה מגלה אם הכאב מפוזר או מרוכז.

2. vmstat, לסדרת זמן קצרה

הריצו vmstat 1 30 ותקבלו שלושים דגימות במרווח שנייה. קבוצת המעבד בצד ימין של הפלט היא us sy id wa st, ובגרסאות חדשות של procps-ng מתווספת גם עמודת gu.

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

3. mpstat, לפירוט לפי ליבה

mpstat מגיע מחבילת sysstat, אז התקינו קודם עם apt install sysstat או dnf install sysstat. אחר כך הריצו mpstat -P ALL 1 5. התיעוד מגדיר את %steal כאחוז הזמן בהמתנה כפויה של המעבד הווירטואלי בזמן שההיפרוויזור שירת מעבד וירטואלי אחר. סדר העמודות יציב: CPU, %usr, %nice, %sys, %iowait, %irq, %soft, %steal, %guest, %gnice, %idle. השורה הראשונה בכל בלוק היא הממוצע על כל המעבדים, ואחריה שורה לכל ליבה.

4. proc/stat, לסקריפטים

כל הכלים למעלה קוראים את /proc/stat. אם אתם בונים ניטור משלכם, קראו ישירות משם, כי סדר השדות מוגדר בקרנל ולא זז בין גרסאות כלים כמו שמיקומי עמודות ב‑vmstat יכולים לזוז.

תיעוד הקרנל למערכת proc קובע את סדר המונים בשורת cpu: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice. כלומר steal הוא המספר השמיני, ושדה מספר 9 אם סופרים גם את התווית cpu. הערכים מצטברים מאז האתחול ונמדדים ב‑USER_HZ, בדרך כלל מאיות שנייה.

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

S1=$(awk '/^cpu / { print $9 }' /proc/stat); T1=$(awk '/^cpu / { t=0; for (i=2; i<=9; i++) t+=$i; print t }' /proc/stat); sleep 10; S2=$(awk '/^cpu / { print $9 }' /proc/stat); T2=$(awk '/^cpu / { t=0; for (i=2; i<=9; i++) t+=$i; print t }' /proc/stat); echo "scale=3; 100*($S2-$S1)/($T2-$T1)" | bc

שימו לב שהלולאה עוצרת בשדה 9 ולא סוכמת את כל השורה. המונים guest ו‑guest_nice נצברים גם בתוך user ו‑nice, ולכן סכימה של כל השדות סופרת אותם פעמיים. ב‑VPS רגיל שניהם אפס וזה לא משנה, אבל בווירטואליזציה מקוננת זה יעוות את התוצאה.

איך לפרש את המספר: טבלת טווחים

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

steal מתמשך	מה קורה	מה לעשות
מתחת ל‑1%	למעשה אין תחרות. ה‑vCPU מקבל ליבה כמעט בכל פעם שהוא מבקש.	כלום. אם השרת מרגיש איטי, הסיבה נמצאת במקום אחר.
1-5%	שגרה בשרת עם vCPU משותף. המתנה קצרה ברגעי עומס, שקופה לרוב היישומים.	תעדו כדי שיהיה קו בסיס, ואז התעלמו. זה מה שקניתם.
5-10%	השרת עמוס מספיק כדי לעלות לכם בהשהיה מדידה. בערך בקשה אחת מכל חמש עשרה מחכה.	התחילו תיעוד של 24 שעות. הצליבו את השיאים מול התנועה שלכם. אם הם לא חופפים, זה שכן ולא אתם.
10-25%	אתם לא מקבלים חלק משמעותי מהמעבד שאתם משלמים עליו. זמני התגובה יהיו לא עקביים בצורה גלויה.	פתחו קריאה עם הלוגים מצורפים ובקשו מעבר לשרת פיזי פחות עמוס.
מעל 25%	השרת הפיזי בצרות. רבע ומעלה מבקשות המעבד שלכם ממתינות מאחורי דיירים אחרים.	הסלימו מיד. אם הספק לא מעביר אתכם תוך יום או יומיים, התחילו לתכנן יציאה.

הסתייגות אחת על כל האמור: קפיצות אינן עומס מתמשך. קריאה של 40 אחוז לשלוש שניות בזמן גיבוי של שכן היא רעש. חמישה אחוזים בכל יום חול בין 14:00 ל‑18:00 היא תבנית, והתבנית היא מה שחשוב.

מדדו 24 שעות, לא 30 שניות

מכירת יתר היא תופעה של שעות שיא. אם אתם מתחברים ב‑03:00, מריצים vmstat 1 10, רואים 0.2 אחוז ומסיקים שהשרת בריא, מדדתם בדיוק את השעה שבה אף אחד לא משתמש בו. זו הטעות הנפוצה ביותר בבדיקת ספק.

אפשרות א: cron עם vmstat

הוסיפו שורת cron ל‑root שדוגמת פעם בדקה ומוסיפה ללוג:

* * * * * /usr/bin/vmstat 1 2 | /usr/bin/tail -1 | /usr/bin/awk -v ts="$(/bin/date -Is)" '{ print ts, $13, $14, $15, $16, $17 }' >> /var/log/steal.log

שני דברים לדעת. השימוש ב‑vmstat 1 2 ולקיחת השורה האחרונה מדלגת על ממוצע האתחול ונותנת דגימה אמיתית של שנייה. ושדה 17 הוא st בפריסת העמודות הקלאסית של procps-ng, כאשר 13 עד 16 הם us sy id wa. מיקומי עמודות הם בדיוק סוג הדבר שמשתנה בין גרסאות הפצה, אז הריצו vmstat 1 2 ידנית וספרו לפני שאתם סומכים על המספרים.

ועוד משהו ששווה שעה של תסכול: סימן אחוז בפקודת cron הוא תו מיוחד. דף ההסבר של crontab קובע שסימן אחוז שלא מוברח בלוכסן אחורי הופך לתו שורה חדשה, וכל מה שאחריו נשלח לפקודה כקלט תקני. אם אתם משתמשים במחרוזת פורמט של date עם אחוזים, הבריחו כל אחד מהם.

אפשרות ב: sar, הכלי שנבנה בדיוק לזה

חבילת sysstat כוללת אוסף רקע שמתעד סטטיסטיקות מעבד בלוח זמנים קבוע. ברגע שהוא מופעל, sar -u מנגן מחדש את היסטוריית המעבד של היום כולל %steal, בלי שתכתבו שורת סקריפט.

• התקינו sysstat וודאו שהאוסף רץ. חלק מההפצות שולחות אותו מושבת, אז בדקו את /etc/default/sysstat או הפעילו את שירות sysstat דרך systemd.
• חכו יום. האיסוף רץ בדרך כלל כל עשר דקות, לפי הגדרת ה‑cron או הטיימר של החבילה.
• הריצו sar -u להיום, או sar -u -f /var/log/sa/sa15 לקובץ של יום מסוים. תיקיית ברירת המחדל היא /var/log/sa, אם כי חלק מההפצות מעבירות אותה.
• צמצמו לחלון עם -s ו‑-e, למשל sar -u -s 14:00:00 -e 18:00:00. שימו לב ש‑sar מציג כברירת מחדל 08:00 עד 18:00, אז אם הבעיה ב‑22:00 צריך לבקש אותה במפורש.

על מה להסתכל כשיש נתונים

• ההתפלגות, לא הממוצע. ממוצע של 3 אחוזים שמורכב מ‑22 שעות של 0.1 ושעתיים של 30 הוא שרת שבור, והממוצע מסתיר את זה לגמרי.
• שעה ביום. מיינו לפי שעה. steal שנגרם משכנים מתקבץ סביב שעות העסקים של אזור השרת וסביב חלונות גיבוי נפוצים.
• מתאם לעומס שלכם. השוו את הלוג מול לוג הגישה של שרת האתר. אם התנועה שלכם שטוחה וה‑steal מטפס, התחרות אינה שלכם.
• יום בשבוע. יש שרתים שתקינים בימי חול ונוראיים בסוף השבוע, או להפך, תלוי במה שהדיירים האחרים מריצים.

למה ה‑VPS איטי כש‑steal קרוב לאפס

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

השהיית דיסק

הריצו iostat -x 1 וקראו את await, שהתיעוד מגדיר כזמן ממוצע במילישניות עד שבקשת קלט/פלט משורתת, כולל זמן בתור. קראו גם r_await ו‑w_await בנפרד, כי קריאה וכתיבה מתנהגות שונה. ב‑NVMe רוצים מספר חד‑ספרתי; עשרות מילישניות בעומס רגיל אומרות אחסון עמוס או יישום שעושה הרבה יותר גישות דיסק ממה שחשבתם. התעלמו מ‑%util בכוננים מודרניים; דף ההסבר עצמו מזהיר שבהתקנים שמשרתים בקשות במקביל המספר הזה לא משקף את גבול הביצועים.

מהירות ליבה בודדת

רוב בקשות האינטרנט הן חד‑חוטיות. רינדור עמוד PHP, view של פייתון, handler של Node: ליבה אחת מתחילה ועד סוף. שמונה ליבות איטיות יפסידו לשתי ליבות מהירות בעומס כזה בכל פעם. steal אומר אם קיבלתם ליבה. הוא לא אומר כמה מהירה היא הייתה. בדקו lscpu והשוו לתדרי הבסיס והטורבו המפורסמים, וזכרו שעומס מתמשך על כל הליבות דוחף כל מעבד שרת לכיוון תדר הבסיס.

השכן הרועש שלא מופיע כ‑steal

שני מקרים אמיתיים שבהם אתם מפסידים ביצועים עם קריאה של אפס. אם ה‑vCPU שלכם מתוזמן על thread שה‑sibling שלו ב‑SMT מריץ שכן עמוס, ה‑vCPU שלכם כן רץ, ולכן שום דבר לא נספר כגנוב, אבל כל מחזור שעון מבצע פחות עבודה כי שני ה‑threads חולקים יחידות ביצוע. באופן דומה, שכן שמרווה את רוחב פס הזיכרון או דורס את מטמון ה‑L3 המשותף מאט את הפקודות שלכם בלי לגרום להן לחכות לליבה. steal time לא רואה אף אחד מהשניים.

מחסור ב‑workers של PHP‑FPM

הסימפטום הקלאסי: האתר או מיידי או לוקח שמונה שניות, בלי שום דבר באמצע, והמעבד על 20 אחוז. זה תור, לא מחסור בחישוב. כל worker תפוס בהמתנה למשהו איטי, בדרך כלל מסד הנתונים או קריאת HTTP חיצונית, ובקשות חדשות ממתינות בתור ההאזנה. בדקו את דף הסטטוס של FPM או את ה‑slow log, וקראו את המדריך שלנו על כמה אתרים אפשר לארח על VPS לגבי חישוב pm.max_children מול זיכרון אמיתי.

לחץ זיכרון ו‑swap

הריצו free -m ו‑vmstat 1 10 והסתכלו על העמודות si ו‑so. כל ערך מתמשך שאינו אפס בשרת אתרים אומר שאתם מדפדפים לדיסק, והדיסק איטי מהזיכרון בכמה סדרי גודל. זה נראה כמו בעיית מעבד בכל לוח מחוונים, ואיננו כזו.

חניקת מעבד בקונטיינר

אם systemd-detect-virt אמר לכם שאתם בקונטיינר ולא במכונה וירטואלית מלאה, תקרות מעבד נאכפות על ידי cgroups ואינן מופיעות כ‑steal. קראו את /sys/fs/cgroup/cpu.stat והסתכלו על nr_throttled ו‑throttled_usec. ערך עולה אומר שאתם נתקלים במכסה שמוגדרת ב‑cpu.max, וזו שיחה אחרת לגמרי מול הספק.

עץ החלטה מהיר

• אם steal מעל 5 אחוזים בשעת השיא שלכם, אז זה השרת הפיזי. עברו לפרק הבא.
• אם steal נמוך ו‑await גבוה, אז זה האחסון. הפחיתו קלט/פלט, הוסיפו מטמון או עברו לדיסק מהיר יותר.
• אם שניהם נמוכים אבל ליבה אחת תקועה על 100 אחוז, אז זה היישום שלכם. עשו לו פרופיילינג.
• אם הכול נמוך ובקשות עדיין מצטברות בתור, אז אלה מגבלות workers או חיבורים. בדקו PHP‑FPM, max_connections של מסד הנתונים ותור ההאזנה.
• אם השרת מהיר בשורת הפקודה ואיטי בדפדפן, אז זו רשת או TLS ולא ה‑VPS. בדקו עם curl -w ו‑mtr מהאזור של המשתמשים.

מכירת יתר, בתיאור של ספק שעושה אותה

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

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

יש גם כשל שני שאינו אשמת אף אחד: שיאים מתואמים. שרת שכל הדיירים בו הם חנויות ישראליות יהיה תקין ב‑04:00 ולחוץ ב‑20:00, גם ביחס שפוי, פשוט כי כולם רוצים מעבד באותו זמן. לכן שרת יכול להיות מוקצה היטב על הנייר ועדיין לתת steal גרוע שעתיים ביום, ולכן הפתרון הוא לרוב מעבר לשרת פיזי אחר ולא חבילה גדולה יותר.

העמדה הכנה של ספק אינה "אנחנו לא מוכרים ביתר". היא: הנה איך למדוד, על המכונות שלנו כמו על של כל אחד אחר, ואם מדדתם משהו רע אצלנו, פתחו קריאה ונבדוק את השרת. ספק שאומר לכם ש‑steal time לא רלוונטי אצלו או שמוכר ליבות ייעודיות ומתמחר בהתאם, או שלא מדבר איתכם ישר.

מה עושים בפועל עם steal גבוה

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

1. פתחו קריאה, עם ראיות

ההבדל בין קריאה שמובילה להעברה לבין קריאה שמקבלת תשובה מועתקת הוא הקובץ המצורף. שלחו את לוג 24 השעות או פלט sar -u עם חותמות זמן, ציינו במפורש את השעות שבהן חצו את הסף, צרפו ראיה שה‑steal אינו מתואם לעומס שלכם (למשל ספירת בקשות לשעה מלוג הגישה), הוסיפו פלט mpstat -P ALL 1 5 מחלון בעייתי, ונסחו בקשה ברורה. "אנא בדקו את עומס השרת הפיזי והעבירו את המכונה לשרת פחות עמוס" זו בקשה שמהנדס יכול לפעול לפיה. "השרת שלי איטי" איננה.

2. בקשו במפורש העברה לשרת פיזי אחר

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

3. שקלו אם חבילה אחרת באמת עוזרת

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

4. עזבו, ובצורה מסודרת

אם שתי קריאות לאורך שבועיים לא הביאו לשינוי מדיד, זה לא ישתפר. היגרו בשיטתיות: הקימו את השרת החדש, הורידו את ה‑TTL ב‑DNS יום מראש, סנכרנו נתונים, בדקו על ה‑IP החדש עם עקיפה בקובץ hosts, ורק אז החליפו. נצלו את ההזדמנות לעשות את היסודות נכון על המכונה החדשה עם צ'ק־ליסט הקשחת ה‑VPS שלנו. ולפני שאתם מתחייבים לספק הבא, הריצו את אותה מדידה של 24 שעות על מכונת ניסיון שלו. למדוד לפני הגירה זול בהרבה מלמדוד אחריה.

vCPU ייעודי מול vCPU משותף

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

עומס עבודה	vCPU משותף	למה
אתר תדמית, בלוג, וורדפרס קטן	מתאים	פרצים של אלפיות שנייה, רוב התוכן מוגש ממטמון. ליבות ייעודיות כאן הן בזבוז.
חנות WooCommerce	לרוב מתאים	עגלה ותשלום עוקפים מטמון, אז שווה לעקוב אחרי steal במבצעים.
שרת API עם התחייבות להשהיה	תלוי בהתחייבות	אם הבטחתם אחוזון 99 למישהו אחר, אתם לא יכולים להרשות שונות שאינה בשליטתכם.
ראנר CI/CD, שרת בנייה	לא מתאים	עומס מתמשך על כל הליבות לדקות רצופות. זה בדיוק העומס שמכירת יתר מענישה.
קידוד וידאו, עבודות ffmpeg	לא מתאים	שעות של 100 אחוז מעבד. תרגישו כל אחוז steal, וגם תעצבנו את השכנים.
שרת משחקים	לא מתאים	עומסי tick דורשים ליבה זמינה בכל טיק. steal מתורגם ישירות לקפיצות lag שהשחקנים מרגישים.
מסד נתונים ראשי עמוס	תלוי בהיקף	מסדים קטנים בסדר. כשמקביליות השאילתות עולה, עיכובי תזמון מצטברים דרך מאגרי החיבורים.
סביבת פיתוח, staging, בוטים, cron	אידיאלי	בטלים כמעט תמיד. תשלום על ליבות שמורות כאן הוא תשלום על כלום.

הכלל שמתחת לטבלה: אם גרף השימוש שלכם נראה כמו קפיצות מזדמנות, vCPU משותף הוא הבחירה הנכונה והזולה. אם הוא נראה כמו מישור, קנו ייעודי. אם אתם לא יודעים איך הוא נראה, בשביל זה יש לוג של 24 שעות.

איפה דבוסטר עומדת, בכנות

חבילות ה‑VPS שלנו הן KVM עם root מלא, על חומרת Intel Xeon Gold 6138 עם אחסון NVMe, קו 1 גיגה‑ביט ותעבורה בלתי מוגבלת, מ‑Nano ב‑3.49 דולר לחודש ועד Mega ב‑34.99. כל חבילה כוללת כתובת IPv4 ועזרה בהגירה ללא תשלום.

מה שלא נספר לכם הוא שביטלנו איכשהו את הכלכלה של וירטואליזציה משותפת. החבילות שלנו הן vCPU משותף, ומתומחרות ככאלה. מה שכן נספר לכם זה מה לעשות עם זה: למדוד. הריצו את פרוטוקול 24 השעות על ה‑VPS שלכם בדבוסטר בדיוק כמו שהייתם עושים אצל כל אחד אחר. אם מצאתם steal מתמשך שאינו מתואם לתנועה שלכם, פתחו קריאה עם הלוג ובקשו שנבדוק את השרת. זו בקשה שאפשר לפעול לפיה, ואנחנו מעדיפים לפעול לפיה מאשר לקרוא עליה בביקורת.

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

שאלות נפוצות

מה נחשב steal time תקין ב‑VPS?

מתחת לאחוז אחד באופן מתמשך זה מצוין, ובין אחוז לחמישה אחוזים זה שגרתי בכל חבילה עם vCPU משותף. בין 5 ל‑10 אתם מאבדים השהיה מדידה וכדאי לאסוף נתונים. מעל 10 אחוזים לאורך שעות, השרת נמכר יתר על המידה. אלה כללי אצבע של אנשי מקצוע ולא תקן רשמי.

איך בודקים steal time ב‑VPS?

הריצו top וקראו את הערך st בשורת סיכום המעבד, ולחצו 1 כדי לראות כל vCPU בנפרד. לסדרת זמן קצרה הריצו vmstat 1 30 וקראו את עמודת st, תוך התעלמות מהשורה הראשונה שהיא ממוצע מאז האתחול. לפירוט לפי ליבה התקינו sysstat והריצו mpstat -P ALL 1 5.

מה זה steal time בלינוקס בדיוק?

זה הזמן שבו המעבד הווירטואלי שלכם היה מוכן לרוץ וההיפרוויזור לא נתן לו ליבה פיזית. תיעוד /proc/stat קורא לזה המתנה כפויה. ב‑KVM המארח מדווח את זה לאורח דרך MSR פאראוירטואלי בננושניות, וזמן סרק מוחרג במפורש, ולכן כל ערך מעל אפס אומר שעבודה אמיתית התעכבה.

אפשר להוריד steal time מתוך ה‑VPS?

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

למה ה‑VPS איטי אם ה‑steal אפס?

כי steal מודד רק סוג כשל אחד. בדקו השהיית דיסק עם iostat -x 1 וקראו את await, בדקו swap בעמודות si ו‑so של vmstat, בדקו אם ל‑PHP‑FPM או למסד הנתונים נגמרו workers או חיבורים, ובדקו מהירות ליבה בודדת. גם תחרות על רוחב פס זיכרון מצד שכן מאטה אתכם בלי לרשום steal בכלל.

האם vCPU ייעודי שווה את התוספת?

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