מדריך מאמרים
מספר המשתמשים בו-זמנית ששרת יכול להתמודד איתם תלוי לא במספר הליבות שיש לו, אלא בכמות הזיכרון שכל תהליך צורך.
אמירה זו אולי נשמעת כפרובוקציה, אך זוהי החוויה האמיתית והכואבת ביותר בתעשיית התפעול והתחזוקה.
למה זיכרון הוא צוואר הבקבוק המרכזי?
אנשים רבים רואים VPS עם מעבד בעל 8 ליבות ו-24 ג'יגה-בייט של זיכרון וחושבים באופן תת-מודע שהם יכולים בקלות להריץ מאות תהליכי PHP-FPM.
עם זאת, במציאות, צריכת הזיכרון של RSS של תהליך PHP יחיד היא לעתים קרובות גבוהה עד 200MB.
זוהי התוצאה שהתקבלה באמצעות בדיקה בפועל דרך שורת הפקודה:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
בסביבת ה-framework המורכבת וסביבת התוספים מרובת התוספים של HestiaCP , במיוחד ללא אופטימיזציה של OPcache, 200MB הם הנורמה.
משמעות הדבר היא שהזיכרון, ולא המעבד, הוא המגבלה הקשיחה שקובעת את המקבילות המקסימלית.
קובץ תצורה מומלץ (php-fpm.conf)
pm = dynamic
pm.max_children = 80
pm.start_servers = 16
pm.min_spare_servers = 8
pm.max_spare_servers = 24
pm.max_requests = 500
pm.process_idle_timeout = 10s
request_terminate_timeout = 60s
לוגיקת חישוב פרמטרים ובסיס הגדרה
| פרמטרי תצורה | הגדרת ערך | חישוב הליבה ובסיס ההתקנה |
|---|---|---|
| pm | dynamic | מצב דינמי מאפשר הוספה או מחיקה אלסטית של תהליכים בהתבסס על דרישות בו-זמניות, איזון בין מהירות תגובה לניצול זיכרון. |
| pm.max_children | 80 | 24 ג'יגה-בייט זיכרון כולל פחות ליבת המערכת ו MySQL/Redisלאחר Nginx, נותרו כ-16 ג'יגה-בייט עבור PHP.16,384 MB / 200 MB ≈ 81.9הגדרה של 80 יכולה לבטל לחלוטין OOM (Out of Memory) במהלך מקביליות גבוהה. |
| pm.start_servers | 16 | חימום מוקדם בעת ההפעלה מוגדר למספר כפול של ליבות המעבד (8 ליבות × 2 = 16) כדי להבטיח שהשירות יוכל לטפל באופן מיידי במקביליות בסיסית לאחר ההפעלה מחדש. |
| pm.min_spare_servers | 8 | הגדר את ספירת ליבות המעבד ל-8 ליבות כדי להבטיח שניתן יהיה להגיב לבקשות חדשות בכל עת בתקופות עם תעבורה נמוכה. |
| pm.max_spare_servers | 24 | הגדר אותו לפי 3 ממספר ליבות המעבד (8 ליבות × 3 = 24) כדי לשמור על מספר מתון של תהליכים לאחר שהתעבורה תרד, על מנת להתמודד עם תנודות עדינות. |
| pm.max_requests | 500 | אם תהליך בודד מגיע לבסיס גדול של 200MB, צמצום מספר הבקשות ל-500 לפני השמדה ובנייה מחדש יכול לנקות דליפות זיכרון מרומזות מהר יותר. |
| pm.process_idle_timeout | 10s | עולה על min_spare_servers תהליכים שאינם פעילים משוחררים אוטומטית ומוחזרים לזיכרון המערכת לאחר 10 שניות ללא בקשות. |
הגדרות תמיכה חיוניות והצעות אופטימיזציה
1. מנגנון פסק זמן נגד הנגאובר
request_terminate_timeout = 60s זה המפתח.
זה יכול לסיים בכוח תהליכים שנתקעו עקב קיפאון במסד הנתונים או חסימת API של צד שלישי.
בינתיים, של Nginx fastcgi_read_timeout יש לשמור אותו לפחות 60 שניות, אחרת הלקוח יקבל אותו בטרם עת. 504 Gateway Timeout.
2. אסטרטגיות להתגברות על צווארי בקבוק בזיכרון
מקסימום של 80 תהליכים בו זמנית פירושו שבתנאי בו-זמניות קיצוניים, המערכת יכולה לטפל במקסימום של 80 בקשות HTTP דינמיות בו זמנית.
אם ברצונך לשפר עוד יותר את הקיבולת, המוקד צריך להיות על הפחתת השימוש בזיכרון לכל תהליך.
- אפשר OPcacheYouריה
php.iniתצורת בינוניתopcache.enable=1及opcache.memory_consumption=256אחסון במטמון של קוד בייט יכול להפחית את ניצול הזיכרון של תהליך בודד מ-200MB ל-60~100MB. - שליטה סבירה על memory_limit:רָצוֹן
php.iniאֶמצַעmemory_limitמוגבל ל128Mאו256Mכדי למנוע סקריפטים חריגים בודדיםללא הגבלהזה צורך הרבה זיכרון.
ברגע ששימוש הזיכרון של תהליך בודד יורד ל-100MB...pm.max_children ניתן לשדרג אותו בבטחה ל 150 בנוסף, יכולת המקביליות כמעט הוכפלה.
נקודות מבט סמכותיות שהובאו
לפי ההמלצות בתיעוד הרשמי של Nginx :
"יש תמיד לנטר יישומי FastCGI באמצעות הנחיות פסק זמן כדי למנוע תשישות משאבים."
(מקור: מסמכי Nginx)
המדריך הרשמי של PHP קובע בבירור:
"pm.max_children מגדיר את המספר המרבי של תהליכי צאצאים שייווצרו. זוהי ההנחיה החשובה ביותר."
(מקור: תיעוד PHP-FPM)
השקפות סמכותיות אלו תואמות באופן מושלם את השיטות שלנו, ומוכיחות שלוגיקת אופטימיזציה אינה מבוססת רק על ניסיון, אלא גם על שיטות עבודה מומלצות סטנדרטיות.
סיכום: נקודות המבט שלי וציטוטים מרכזיים
בתרחישים של בו-זמניות גבוהה, המעבד הוא המנוע, הזיכרון הוא מיכל הדלק, ו-PHP-FPM הוא מנהל הצי.
לא משנה כמה חזק המנוע, אם מיכל הדלק לא גדול מספיק, השיירה לא תגיע רחוק במיוחד.
מומחים אמיתיים לא ממקסמים את הפרמטרים באופן עיוור, אלא מחשבים במדויק את ניצול הזיכרון של כל תהליך כדי למנוע גם בזבוז וגם גלישה.
מהות האופטימיזציה היא למצוא את האיזון האופטימלי עם משאבים מוגבלים.
זו לא רק טכנולוגיה, אלא גם פילוסופיה.
לכן, תפסיקו להאמין ש"מספר הליבות קובע הכל." מה שבאמת קובע את מגבלת המקביליות הוא השליטה שלכם על הזיכרון.
נקטו פעולה וייעלו את ה-VPS שלכם עד למלוא הפוטנציאל שלו, תוך ניצול מקסימלי של כל טיפת זיכרון.
אני מקווה שהמאמר "שרת VPS עם 8 ליבות ו-24 ג'יגה-בייט שאורך מספיק זיכרון? כוונון קיצוני של מאגר תהליכי PHP-FPM תחת HestiaCP" שפורסם בבלוג של צ'ן וייליאנג ( https://www.chenweiliang.com/ ) יהיה לעזר עבורך.
אל תהססו לשתף את הקישור למאמר הזה: https://www.chenweiliang.com/cwl-34509.html