תצורת PHP-FPM לעומס גבוה עבור 1C-Bitrix

שרת עם 8 GB RAM ומעבד בעל 4 ליבות תחת 50 משתמשים בו-זמניים מאט לזמני תגובה של 5 שניות. top מראה 95% CPU על php-fpm, ו-swap מלא. תצורת PHP-FPM ברירת המחדל עובדת עבור אתרים פשוטים, אך לא עבור Bitrix עם ה-ORM הכבד ומטמוני האובייקטים שלו. תחת עומס כזה, זמן יצירת הדף יכול לעלות על 10 שניות, מה שמשפיע באופן קטסטרופלי על חוויית המשתמש.

אנו מגדירים PHP-FPM עבור Bitrix כבר שנים רבות — מעל 50 פרויקטים. במהלך תקופה זו, פיתחנו תצורות שמתמודדות עם 200+ משתמשים בו-זמניים על שרת יחיד. מאמר זה מספק פרמטרים ספציפיים וחישובים עבור פרויקט טיפוסי. החיסכון הטיפוסי בעלויות מאופטימיזציה זו נע בין 30-50% במשאבי השרת.

מדוע PHP-FPM ברירת המחדל לא מתאים ל-Bitrix

ברירת המחדל של ה-pool משתמשת בדרך כלל ב-pm = dynamic עם pm.max_children = 5. עבור חנות Bitrix עם 50 משתמשים, זה לא מספיק — 5 עובדים נחסמים על ידי בקשות איטיות, ואחרים ממתינים בתור. התוצאה: Timeout 504. תצורה אופטימלית מספקת עליית מהירות של פי 2-3 בהשוואה לתצורה הסטנדרטית. עם JIT, ביצוע PHP מהיר ב-10-30% בהשוואה ללא JIT.

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

נוסחה: max_children = (Доступная RAM для PHP) / (Средний размер процесса). עם 8 GB RAM, 2 GB עבור מערכת ההפעלה, 1 GB עבור MySQL: 5 GB / 120 MB ≈ 41. קחו מרווח ביטחון: 30-35.

אבחון המצב הנוכחי

לפני הכוונון, קחו תמונת מצב של התמונה בפועל:

# Количество php-fpm процессов и их статус
ps aux | grep php-fm | grep -v grep | wc -l
# Потребление памяти на один процесс
ps aux --sort=-%mem | grep php-fpm | head -5 | awk '{print $6/1024 " MB"}'
# Статус пула через status-страницу
curl -s http://127.0.0.1/php-fpm-status?full

תמונה טיפוסית: 20-30 עובדי PHP-FPM שצורכים 80-150 MB כל אחד. 30 * 120 MB = 3.6 GB רק עבור PHP על שרת עם 8 GB.

תצורת ה-Pool

קובץ תצורת ה-pool # Количество php-fpm процессов и их статус ps aux | grep php-fpm | grep -v grep | wc -l # Потребление памяти на один процесс ps aux --sort=-%mem | grep php-fpm | head -5 | awk '{print $6/1024 " MB"}' # Статус пула через status-страницу curl -s http://127.0.0.1/php-fpm-status?full :

[bitrix]
user = bitrix
group = bitrix
listen = /run/php/php8.1-fpm-bitrix.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
; Управление процессами
pm = dynamic
pm.max_children = 30
pm.start_servers = 8
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 1000
; Таймауты
request_terminate_timeout = 120s
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/slow.log
; Статус
pm.status_path = /php-fpm-status

מצבי ניהול תהליכים: /etc/php/8.1/fpm/pool.d/bitrix.conf עובד עבור עומס משתנה — חוסך זיכרון בזמן סרק אך מבזבז משאבים על fork. [bitrix] user = bitrix group = bitrix listen = /run/php/php8.1-fpm-bitrix.sock listen.owner = www-data listen.group = www-data listen.mode = 0660 ; Управление процессами pm = dynamic pm.max_children = 30 pm.start_servers = 8 pm.min_spare_servers = 5 pm.max_spare_servers = 15 pm.max_requests = 1000 ; Таймауты request_terminate_timeout = 120s request_slowlog_timeout = 5s slowlog = /var/log/php-fpm/slow.log ; Статус pm.status_path = /php-fpm-status ממזער עיכובי בקשות תחת עומס יציב אך אינו מסתגל לירידות. dynamic חוסך מקסימום בזמן עליות נדירות אך גורם לעיכובים בהפעלה. עבור רוב פרויקטי Bitrix, אנו בוחרים ב-static. שימוש ב-static מפחית את זמן האחזור של בקשות בעד 20% בהשוואה ל-dynamic תחת עומס עקבי.

ondemand — הפעלה מחדש של עובד לאחר 1000 בקשות מונעת דליפות זיכרון. טיפוסי עבור פרויקטים עם מודולי PHP צד-שלישי רבים.

כיצד אנו מגדירים PHP-FPM שלב אחר שלב

1. ביקורת על מצב השרת הנוכחי באמצעות dynamic, pm.max_requests = 1000 סטטוס ה-pool.
2. חישוב ps בהתבסס על זיכרון פנוי.
3. יצירת pools נפרדים עבור האתר, הסוכנים וייבוא 1C.
4. כוונון curl עם JIT, Memcached עבור סשנים, OPcache.
5. הגדרת slowlog וניטור.
6. בדיקה תחת עומס.

תצורת PHP עבור Bitrix

pm.max_children (פרמטרים קריטיים עבור Bitrix):

; Память
memory_limit = 256M
; Время выполнения
max_execution_time = 90
max_input_time = 60
; Загрузка файлов (для загрузки изображений и прайсов)
upload_max_filesize = 256M
post_max_size = 256M
max_file_uploads = 50
; Сессии
session.gc_maxlifetime = 3600
session.save_handler = memcached
session.save_path = "127.0.0.1:11211"
; OPcache
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 60
opcache.jit = tracing
opcache.jit_buffer_size = 64M
; Отключаем опасные функции
disable_functions = exec,passthru,shell_exec,system,proc_open,popen

php.ini — סשנים בזיכרון במקום במערכת הקבצים. קריטי עבור אשכולות מרובי שרתים ומאיץ את גישת הסשנים פי 50 בהשוואה לקבצים.

/etc/php/8.1/fpm/php.ini — מהדר JIT עבור PHP 8.0+. עבור הקוד הפרוצדורלי של Bitrix, נותן שיפור CPU של 10-30%. OPcache מאחסן סקריפטים מהודרים בזיכרון משותף, ומפחית פעולות קלט/פלט של קבצים.

השוואה בין פרמטרי PHP ברירת מחדל ואופטימליים:

מדוע pools נפרדים עבור סוכנים וייבוא 1C?

מומלץ להפריד pools:

• upload_max_filesize — האתר הראשי, 30 עובדים, זיכרון 256M
• session.save_handler — סוכני Bitrix, 3-5 עובדים, זיכרון 512M, timeout ארוך יותר
• opcache.memory_consumption — ייבוא 1C, 1-2 עובדים, זיכרון 1G, timeout של 300 שניות

סוכנים וייבוא 1C לא צריכים להתחרות עם בקשות משתמשים על עובדים. ללא הפרדה, pool הייבוא יכול לתפוס את כל 30 המקומות במהלך עיבוד מחירונים.

ניטור

# Смотрим статус в реальном времени
watch -n1 'curl -s http://127.0.0.1/php-fpm-status | grep -E "active|idle|total"'

אם bitrix.conf שווה בעקביות ל-agents.conf — ה-pool עמוס יתר על המידה, ובקשות ממתינות בתור. יש צורך להגדיל את import.conf או לבצע אופטימיזציה של הקוד.

טעויות טיפוסיות בתצורת PHP-FPM

• pm.max_children קטן מדי. אם max_children קטן ממספר הבקשות בו-זמניות, הבקשות ממתינות בתור. פתרון — חישוב באמצעות הנוסחה שלמעלה.
• חוסר ב-slowlog. ללא slowlog, לא תדעו אילו בקשות איטיות. הפעילו request_slowlog_timeout = 5s.
• pool יחיד עבור כל המשימות. ייבוא 1C וסוכנים צריכים pools נפרדים, אחרת בקשות משתמשים נחסמות.

מה כלול בתצורת מפתח ביד

אנו מציעים שירות אופטימיזציה מקיף של PHP-FPM עבור 1C-Bitrix:

• ביקורת על תצורת השרת וה-PHP הנוכחית
• חישוב מספר העובדים האופטימלי וגדלי pools
• הגדרת pools נפרדים עבור סוכנים וייבוא
• אופטימיזציה של OPcache ו-JIT
• העברת סשנים ל-Memcached או Redis
• הגדרת slowlog וניטור
• תיעוד תצורה
• אחריות לפעולה יציבה תחת עומס

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

ציר זמן ותהליך

ציר זמן טיפוסי: 2–5 ימי עסקים בהתאם למורכבות השרת.

• יום 1: איסוף נתונים וביקורת (מפרטי שרת, תצורות נוכחיות, דפוס עומס).
• יום 2: ניתוח ועיצוב (חישוב עובדים, תכנון הפרדת pools, בחירת מטמון).
• יום 3–4: יישום (הגדרת pools, php.ini, סשנים, slowlog, ניטור).
• יום 5: בדיקת עומס, כוונון סופי ותיעוד.

רשימת בדיקה לבדיקה עצמית (אופציונלי)

• חישוב # Смотрим статус в реальном времени watch -n1 'curl -s http://127.0.0.1/php-fpm-status | grep -E "active|idle|total"' בהתבסס על RAM פנוי.
• הגדרת active processes ל-1000 למניעת דליפות זיכרון.
• הפעלת max_children ובדיקת slowlog יומית.
• שימוש ב-pools נפרדים עבור סוכנים וייבוא 1C.
• אחסון סשנים ב-Memcached או Redis.
• הפעלת OPcache עם JIT (PHP 8.0+).
• ניטור max_children כדי למנוע הצטברות תורים.

קראו גם מידע נוסף בוויקיפדיה ותיעוד רשמי ללימוד מעמיק.