כמה אתרים אפשר לארח על VPS אחד? החישוב האמיתי

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

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

נקודות מפתח

• הקיבולת נגזרת מבו-זמניות ומאחוז הפגיעה במטמון, לא ממספר האתרים. עשרה אתרי תדמית עם מטמון יכולים להיות קלים יותר מחנות WooCommerce אחת.
• הנוסחה היחידה שחשובה: בו-זמניות שווה קצב בקשות כפול משך בקשה. כל השאר זו הנהלת חשבונות.
• רוב האתרים הקטנים צריכים שבריר של תהליך PHP אחד בשיא. אתר עם 120,000 צפיות בחודש מייצר בממוצע כ-0.05 בקשות בשנייה.
• זיכרון הוא המספר שספקים מפרסמים, אבל ביצועי ליבה בודדת והשהיית דיסק נגמרים ראשונים. עוד זיכרון לעולם לא מזרז בקשה בודדת.
• הכשלים מגיעים בסדר צפוי: מיצוי תהליכי PHP-FPM, מגבלת חיבורים למסד הנתונים, דפדוף לדיסק, ולבסוף ה-OOM killer של הקרנל.
• אירוח כמה אתרים על שרת אחד מחייב משתמש מערכת נפרד ו-pool נפרד לכל אתר, אחרת תוסף פרוץ אחד חושף את סיסמאות מסד הנתונים של כל השאר.

למה "כמה אתרים" זו יחידת המידה הלא נכונה

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

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

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

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

תכנון קיבולת VPS: החישוב שבאמת עובד

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

שלב 1: מדדו כמה זיכרון תופס תהליך PHP אחד

אל תשתמשו במספר ממאמר. מדדו את שלכם, כי הוא תלוי לגמרי במערך התוספים שלכם.

ps --no-headers -o rss -C php-fpm8.3 | awk '{ s += $1; n++ } END { print s/n/1024, "MB average RSS" }'

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

awk '/^Pss/ { s += $2 } END { print s/1024, "MB PSS" }' /proc/PID/smaps_rollup

הריצו את זה על כמה תהליכים עמוסים וקחו ממוצע. ה-PSS הוא העלות השולית האמיתית של הוספת תהליך נוסף. לשם השוואה על התקרה ולא על הטיפוסי: ברירת המחדל של memory_limit ב-PHP היא 128M, ווורדפרס מגדירה WP_MEMORY_LIMIT ל-40MB באתר בודד ו-64MB ברשת אתרים. אלו תקרות לבקשה, לא הקצאות בפועל.

שלב 2: מדדו כמה זמן לוקחת בקשה בלי מטמון

הוסיפו לפורמט הלוג של nginx את rt=$request_time urt=$upstream_response_time, טענו מחדש, ותנו לזה לרוץ יום.

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

הפעילו גם את ה-slowlog של PHP-FPM עם request_slowlog_timeout = 5s. כל מה שמופיע שם גוזל תהליך למשך חמש שניות, ובמכונה קטנה זה שקול להוצאת חלק מהקיבולת משירות.

שלב 3: תרגמו תנועה לבו-זמניות בשיא

בחודש יש 2,592,000 שניות (30 ימים כפול 86,400). לכן:

• בקשות ממוצעות בשנייה שוות צפיות חודשיות חלקי 2,592,000.
• בקשות בשיא שוות לממוצע כפול מקדם השיא שלכם.

אל תנחשו את מקדם השיא אם אפשר להימנע. שלפו את השעה העמוסה ביותר מ-30 הימים האחרונים בלוג וחלקו ב-3,600:

awk '{ print $4 }' /var/log/nginx/access.log | cut -d: -f1-2 | sort | uniq -c | sort -rn | head -5

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

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

שלב 4: החילו את אחוז הפגיעה במטמון

רק ההחמצות עולות לכם. בקשות שמגיעות ל-PHP שוות לבקשות בשיא כפול (1 פחות אחוז הפגיעה). מדדו במקום להניח: הוסיפו את $upstream_cache_status ללוג וספרו כמה HIT, MISS, BYPASS ו-EXPIRED יש. אתר תדמית או בלוג מוגדר היטב יושב בשנות התשעים. חנות WooCommerce היא חיה אחרת: עגלה, תשלום, אזור אישי וכל עמוד עם עוגיית סשן חייבים לעקוף את המטמון לגמרי.

שלב 5: קחו את הנמוכה מבין שתי התקרות

תקרת הזיכרון. זיכרון פנוי ל-PHP חלקי זיכרון לתהליך שווה למקסימום pm.max_children בסך כל ה-pools יחד.

תקרת המעבד. מספר ליבות כפול 1,000, חלקי מילישניות מעבד לבקשה, שווה למקסימום בקשות בשנייה שאפשר להחזיק. שימו לב שמדובר בזמן מעבד ולא בזמן שעון. בקשה שמחכה 300 מילישניות לשאילתה ושורפת 80 מילישניות מעבד עולה לכם 80, לא 380.

הקיבולת האמיתית היא הנמוכה מבין השתיים, וכמעט בכל VPS מתחת ל-16GB זו תקרת המעבד. זו הנקודה הכי שימושית במאמר הזה.

דוגמה מלאה על VPS של 2 ליבות ו-4GB

נחשב חבילת Starter (2 vCPU, 4GB, 75GB NVMe) עם nginx, PHP-FPM 8.3 ו-MariaDB, כשכל מספר מוצג כהנחה שאפשר להחליף.

תקציב זיכרון. מתוך 4,096MB נחסר: כ-400MB למערכת ההפעלה ולשירותים, כ-900MB ל-MariaDB עם buffer pool של 512MB, כ-50MB ל-nginx, כ-200MB ל-Redis, וכ-600MB מרווח ביטחון לגיבויים ולעדכונים. נשארים כ-1,946MB ל-PHP-FPM. אם מדדתם 55MB לתהליך, תקרת הזיכרון היא כ-35 תהליכים.

תקציב מעבד. נניח שמדדתם שרינדור עמוד וורדפרס בלי מטמון שורף כ-120 מילישניות מעבד. שתי ליבות נותנות 2,000 מילישניות מעבד בשנייה, כלומר כ-16 בקשות בשנייה בניצול מלא, ובפועל כ-11 עד 12.

השוואה. ב-12 בקשות בשנייה עם זמן רינדור של 400 מילישניות, הבו-זמניות היא כחמישה תהליכים פעילים. יש לכם מקום ל-35 ותשתמשו בחמישה. הגדרת pm.max_children ל-35 במכונה הזו לא מוסיפה קיבולת. היא נותנת למכונה רשות לקבל 35 רינדורים בו-זמנית על שתי ליבות, וכל הבקשות נעשות איטיות יחד. המהלך הנכון הוא לחסום סביב 12 עד 16, כך שהתור נוצר ב-nginx שם הוא זול, ולא בתור הריצה של הקרנל.

ועכשיו לאתרים. אתר וורדפרס עם מטמון ו-120,000 צפיות בחודש מייצר 0.046 בקשות בשנייה בממוצע. במקדם שיא של 8 זה 0.37 בשיא, ובאחוז פגיעה של 92 רק 0.03 מגיעות ל-PHP. חלוקה של 12 ב-0.03 נותנת 400 אתרים, וברור שלא תעשו את זה. הסיבות הן מקום בדיסק, מספר inodes, זיכרון MariaDB על עשרות סכמות, חלונות גיבוי חופפים, והעובדה שסופת בוטים על אתר אחד יכולה לבלוע את כל התקציב. כוונו לניצול של 25 עד 35 אחוז מהתקרה המחושבת, ותגיעו לכ-6 עד 10 אתרים בגודל הזה על החבילה הזו.

כמה אתרים אפשר לארח על VPS בכל גודל חבילה

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

חבילה	מפרט	אתרי תדמית	אתרי וורדפרס עם מטמון	חנויות WooCommerce	מה נגמר ראשון
Nano	1 vCPU / 1GB / 25GB	3 - 5	1	לא מומלץ	זיכרון. MariaDB ו-PHP על 1GB דורשים swap וכיוונון זהיר.
Micro	1 vCPU / 2GB / 50GB	8 - 12	2 - 4	1 קטנה מאוד	הליבה הבודדת. רינדור איטי אחד חוסם את הבא אחריו.
Starter	2 vCPU / 4GB / 75GB	15 - 25	6 - 10	1 - 2	מעבד בעומס ללא מטמון, או זיכרון אם ה-pools נשארו בברירת מחדל.
Basic	3 vCPU / 6GB / 100GB	25 - 35	10 - 15	2 - 3	מעבד, ואחריו השהיית דיסק בזמן גיבויים חופפים.
Advanced	4 vCPU / 8GB / 125GB	35 - 50	15 - 20	3 - 4	IOPS של הדיסק וחלון הגיבוי הלילי.
Pro	6 vCPU / 12GB / 150GB	50 - 75	20 - 30	5 - 6	מקום בדיסק ו-inodes כשלאתרים יש ספריות מדיה אמיתיות.
Elite	8 vCPU / 16GB / 175GB	75 - 100	30 - 40	6 - 8	מקום בדיסק, ועומס התחזוקה של כל כך הרבה התקנות.
Mega	10 vCPU / 24GB / 200GB	100 - 150	40 - 60	8 - 12	מקום בדיסק כמעט תמיד. 200GB על 60 אתרים זה 3.3GB לאתר.

ההנחות מאחורי כל מספר בטבלה:

• אתר תדמית הוא HTML סטטי או וורדפרס עם מטמון עמוד מלא, פחות מכ-5,000 צפיות בחודש, בלי משתמשים מחוברים ובלי חיפוש פנימי.
• אתר וורדפרס עם מטמון הוא אתר עם אחוז פגיעה בשנות התשעים הנמוכות, עד כ-25,000 צפיות בחודש, מספר תוספים סביר ו-PHP 8.3 עם OPcache פעיל.
• חנות WooCommerce היא קטלוג של עד כ-1,000 מוצרים בהיקף הזמנות צנוע, שבו עגלה, תשלום ואזור אישי עוקפים מטמון לגמרי. אלו הדיירים היקרים.
• כל המספרים מניחים nginx, PHP-FPM ו-MariaDB על אותה מכונה, pool נפרד לכל אתר עם pm = ondemand לאתרים השקטים, ואפס עומסים אחרים על השרת.
• הם מניחים שהגדרתם מגבלות לכל pool. הגדרות ברירת מחדל על עשרה אתרים ייתנו תוצאה גרועה משמעותית.
• אתר בודד שגדל מעל האחרים מבטל את כל השורה. הקיבולת נקבעת לפי הדייר הרועש, לא לפי הממוצע.

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

למה זיכרון הוא בדרך כלל הדבר הלא נכון לשפר

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

האמת הלא נוחה: הוספת זיכרון לעולם לא מזרזת בקשה בודדת. אם עמוד הבית שלכם לוקח 800 מילישניות לרינדור, הוא ייקח 800 מילישניות גם על 1GB וגם על 64GB. זיכרון רק מאפשר ליותר בקשות לרוץ במקביל.

ביצועי ליבה בודדת

בקשת PHP רצה על thread אחד מתחילתה ועד סופה. אין מקביליות בתוך רינדור של עמוד. לכן זמן התגובה הראשון שלכם נקבע לפי כמה מהירה ליבה אחת, ולא לפי כמה ליבות יש. שמונה ליבות איטיות יפסידו בהשוואת TTFB לשתי ליבות מהירות בכל פעם. שרתי ה-VPS של דבוסטר רצים על Intel Xeon Gold 6138, שאינטל מפרטת כ-20 ליבות ו-40 threads בתדר בסיס 2.00 GHz ותדר טורבו מרבי של 3.70 GHz. המספר הרלוונטי ל-TTFB שלכם הוא תדר הטורבו, לא ה-20.

השהיית דיסק ו-IOPS

NVMe מהיר, אבל על מארח וירטואלי אתם חולקים התקן. המדד שחשוב הוא לא תפוקה במגה-בייט לשנייה אלא השהיה תחת בו-זמניות, והכלי הוא iostat -xz 1. עקבו אחרי %util ו-await. על NVMe זמני שירות אמורים להיות הרבה מתחת למילישנייה. אם await יושב באופן עקבי בעשרות מילישניות, משהו עומד בתור ושום כמות זיכרון לא תעזור.

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

איפה זיכרון כן קריטי

לזכות הזיכרון: הוא חשוב מאוד ל-InnoDB buffer pool. אם קבוצת העבודה של מסד הנתונים נכנסת ל-buffer pool, הקריאות מגיעות מהזיכרון. אם לא, הן מגיעות מהדיסק, והפכתם בעיית זיכרון לבעיית IOPS. הוא חשוב גם ל-OPcache, ל-Redis, ולעצם העובדה שדפדוף לדיסק הוא אסון. פשוט תגזרו את הגודל מהחישוב, לא מהחרדה.

מה באמת נשבר ראשון כשמעמיסים על VPS

עומס יתר לא מגיע כאירוע אחד. הוא מגיע כרצף, ולכל שלב יש חתימה מזהה.

1. מיצוי תהליכי PHP-FPM

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

החתימה ברורה בלוג. תראו server reached pm.max_children setting (N), consider raising it או listening queue is not empty, #N requests are waiting to be served. שתי ההודעות מגיעות ישירות ממנהל התהליכים של PHP-FPM.

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

2. מגבלת חיבורים למסד הנתונים

הבא בתור. כל תהליך PHP פעיל מחזיק בדרך כלל חיבור אחד למסד הנתונים, ולכן סכום pm.max_children על כל ה-pools קובע את הביקוש בשיא. MySQL 8.0 מגיע עם max_connections של 151 ומחזיר שגיאה 1040, "Too many connections", כשחורגים. MySQL שומר חיבור נוסף אחד מעל המגבלה למשתמשים עם ההרשאה CONNECTION_ADMIN, וכך אפשר בכל זאת להיכנס ולהריץ SHOW PROCESSLIST באמצע התקלה.

בדקו את שיא השימוש במקום לחכות לשגיאה: SHOW GLOBAL STATUS LIKE 'Max_used_connections';

שתי מלכודות. ראשית, אם סכום ה-pools עולה על max_connections, זינוק תנועה באתר אחד ינעל את כל השאר מחוץ למסד הנתונים. שנית, אל תתקנו את זה בהעלאה ל-1000. כל חיבור מקצה buffers משלו לפי הצורך, ומגבלה גבוהה על מכונה קטנה היא דרך ישירה ל-OOM killer.

3. דפדוף לדיסק

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

בקרנלים מודרניים יש אות טוב יותר. קראו את /proc/pressure/memory והסתכלו על הערך some avg10: הוא אומר באיזה אחוז מעשר השניות האחרונות לפחות משימה אחת נעצרה בהמתנה לזיכרון. אפס זה בריא. ספרות כפולות באופן מתמשך אומרות שאתם כבר בצרות.

4. ה-OOM killer

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

לכן הסימפטום הגלוי של עומס זיכרון הוא כמעט אף פעם לא "אין זיכרון". הוא כל האתרים על השרת שמציגים בו-זמנית "Error establishing a database connection", וזה שולח אנשים לחפש בעיית מסד נתונים שלא קיימת.

אשרו בפקודה אחת: dmesg -T | grep -iE "killed process|out of memory". וודאו גם ש-MariaDB חוזרת לפעול. הוסיפו הגדרת systemd עם Restart=on-failure, אחרת תקלה של חמש דקות הופכת ללילה שלם.

5. מקום בדיסק ו-inodes

פחות דרמטי, נפוץ יותר ממה שחושבים. בדקו גם df -h וגם df -i. השני הוא המלכודת: התקנת וורדפרס עם תוספים היא עשרות אלפי קבצים קטנים, ובמערכת קבצים ext4 מספר ה-inodes נקבע ביצירה. אפשר בהחלט למצות inodes כשעדיין יש 40 אחוז דיסק פנוי, ואז הכל נכשל עם "No space left on device" בזמן ש-df -h מתעקש שהכל בסדר.

איך לארח כמה אתרים על VPS אחד כמו שצריך

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

משתמש מערכת נפרד לכל אתר

זו ההחלטה הכי חשובה, וזו שרוב המדריכים מדלגים עליה. אם כל האתרים רצים כ-www-data, אז תוסף פגיע אחד בכל אתר נותן לתוקף גישת קריאה ל-wp-config.php של כל שאר האתרים, כלומר לסיסמאות מסד הנתונים של כולם.

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

Pool נפרד של PHP-FPM לכל אתר

תנו לכל אתר קובץ pool משלו, socket משלו ומשתמש משלו:

• user ו-group מוגדרים למשתמש המערכת של אותו אתר
• listen מצביע ל-socket ייעודי, עם listen.owner של משתמש nginx
• php_admin_value[open_basedir] שמגביל את ה-pool לתיקייה שלו בלבד
• php_admin_value[memory_limit] פר אתר, כדי שייבוא שהשתולל לא ייקח את כל השרת
• php_admin_value[disable_functions] שחוסם exec, shell_exec, system ו-proc_open אלא אם באמת צריך אותם

בחרו את מנהל התהליכים לכל אתר בנפרד. המדריך הרשמי של PHP-FPM מגדיר שלושה מצבים: static מחזיק מספר קבוע, dynamic מתאים את עצמו בין ספי תהליכים פנויים, ו-ondemand יוצר תהליך רק כשמגיעה בקשה והורג אותו אחרי pm.process_idle_timeout, שברירת המחדל שלו היא 10 שניות.

בשרת רב-אתרים זו כל המשחק. השתמשו ב-ondemand לאתרים השקטים והם יעלו לכם אפס זיכרון כשאין מבקרים. השתמשו ב-dynamic לאתר או שניים העמוסים. הכשל הנפוץ הוא להגדיר כל pool כ-dynamic עם pm.max_children = 20: עשרה אתרים כאלה הם 200 תהליכים תיאורטיים, שב-55MB לתהליך זה ביקוש של 11GB על מכונה של 4GB.

הכלל שכדאי לרשום על פתק: סכום pm.max_children של כל ה-pools, כפול הזיכרון שמדדתם לתהליך, חייב להיכנס לתקציב הזיכרון שהקצתם ל-PHP. לא כל pool בנפרד. הסכום.

מגבלות משאבים לכל אתר

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

אם אתם צריכים מגבלות קשיחות, התשובה הכנה היא ש-pools של PHP-FPM לא נותנים אותן, כי מגבלות cgroup חלות על השירות כולו. לאכיפה אמיתית מריצים יחידת systemd נפרדת של PHP-FPM לכל אתר ומחילים MemoryMax, CPUQuota ו-IOWeight על כל יחידה, או עוברים לקונטיינרים. לאוסף אתרים אישי זו הנדסת יתר. ללקוחות משלמים על אותו שרת, זה לא.

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

הגבלת קצב היא ניהול קיבולת

חלק מפתיע מהתקלות של "ה-VPS שלי עמוס" הן זחלן אחד שמתנהג רע או ניסיונות פריצה ל-wp-login.php. שניהם מגיעים ל-PHP, שניהם עוקפים את מטמון העמודים, ושניהם יכולים לבלוע את כל תקציב התהליכים בלי מבקר אנושי אחד. אזור limit_req ב-nginx על עמודי התחברות ו-XML-RPC, יחד עם fail2ban, זול יותר מהחבילה הבאה ופותר את הבעיה האמיתית.

גיבויים, רדיוס נזק ובעיית הסוכנות

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

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

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

כתובת IP אחת היא מוניטין משותף. כל האתרים שולחים דואר מאותה כתובת. טופס יצירת קשר פרוץ אחד שמתחיל להעביר ספאם גורם לחסימת הכתובת, ופתאום מיילי איפוס סיסמה של כל האתרים נוחתים בספאם. שלחו דואר טרנזקציוני דרך ספק ייעודי עם SPF, DKIM ו-DMARC תקינים, וזה מפסיק להיות הבעיה שלכם.

בדיקת שחזור היא לא רשות בקנה מידה הזה. בחרו אתר אחד ברבעון ושחזרו אותו באמת למקום אחר. גיבוי לא בדוק על עשרה אתרים הוא עשרה גיבויים לא בדוקים.

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

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

• אתם לא רוצים להריץ עדכוני מערכת. VPS נותן לכם מכונת לינוקס לא מנוהלת. עדכוני אבטחה, חומת אש, חידוש תעודות וסבב לוגים הם עכשיו העבודה שלכם, על כל האתרים. אם זה לא מושך, אחסון שיתופי מנוהל ישרת אתכם טוב יותר במאמץ קטן יותר, וההשוואה שלנו בין אחסון שיתופי ל-VPS מפרטת את התמורה.
• אתר אחד הוא 80 אחוז מהעומס. תנו לו מכונה משלו. התאמת שרת לדייר הכי עמוס פירושה תשלום יתר על כל השקטים.
• לקוחות עם התחייבות חוזית לזמינות. רדיוס נזק משותף הוא חשיפה שאי אפשר להנדס החוצה. מכונות נפרדות ללקוח משמעותי הן המבנה הנכון.
• תנועה תנודתית ובלתי צפויה. VPS קבוע לא סופג זינוק של פי 50. שימו CDN מלפנים או עברו לפלטפורמה שמתרחבת אופקית.
• הקהל שלכם רחוק מהשרת. שרתי דבוסטר ממוקמים בדרום ארה"ב. אם כל הגולשים שלכם בישראל, הפיזיקה מוסיפה זמן הלוך ושוב שאף כיוונון לא מבטל. CDN יטפל בקבצים סטטיים, אבל HTML שלא במטמון עדיין עושה את הדרך.

התשובה, בניסוח מחדש

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

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

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

שאלות נפוצות

כמה אתרים אפשר לארח על VPS עם 2GB?

באופן מציאותי 8 עד 12 אתרי תדמית קטנים, או 2 עד 4 אתרי וורדפרס עם מטמון, בהנחה של nginx, PHP-FPM ו-MariaDB על אותה מכונה עם pool נפרד לכל אתר במצב ondemand. במפרט של 2GB עם ליבה אחת המגבלה בפועל היא בדרך כלל המעבד ולא הזיכרון.

כמה אתרי וורדפרס VPS אחד מסוגל להחזיק?

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

כמה זיכרון צריך ל-VPS שמריץ כמה אתרים?

חשבו במקום לנחש: תקורת מערכת ההפעלה, ועוד ה-InnoDB buffer pool, ועוד nginx ומטמון אובייקטים, ועוד סכום כל ה-pools כפול הזיכרון שמדדתם לתהליך, ועוד כ-15 אחוז מרווח. ברוב המערכים הקטנים זה נוחת בין 4 ל-8 ג'יגה. זיכרון נוסף לעולם לא מזרז בקשה בודדת.

האם בטוח לארח אתרי לקוחות על אותו VPS?

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

האם צריך פאנל ניהול כדי לארח כמה אתרים?

לא. כמה אתרים זה פשוט כמה server blocks ב-nginx, כמה pools וכמה מסדי נתונים, והכל ניתן להגדרה ידנית. פאנל חוסך זמן ואוכף ברירות מחדל של בידוד, אבל צורך זיכרון ומוסיף משטח תקיפה. בחבילה של 1 או 2 ג'יגה פאנל יכול לעלות לכם רבע מהזיכרון השמיש.

מה קורה כשנגמר הזיכרון ב-VPS?

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