Налаштування PHP-FPM для 1С-Бітрікс
Налаштування PHP-FPM для 1С-Бітрікс
Сервер з 8 ГБ RAM і 4-ядерним CPU під навантаженням 50 одночасних користувачів починає відповідати за 3–5 секунд. top показує 95% CPU на php-fpm процесах і swap. Стандартна конфігурація PHP-FPM розрахована на мінімальне споживання пам'яті, а не на highload. Для 1С-Бітрікс — з його важкими об'єктними моделями та ORM — це неприпустимо.
Діагностика поточного стану
Перед налаштуванням — знімок реальної картини:
# Кількість 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
Типова картина: 20–30 PHP-FPM воркерів по 80–150 МБ кожен. 30 × 120 МБ = 3,6 ГБ лише на PHP при 8 ГБ RAM.
Налаштування пулу
Конфігураційний файл пулу /etc/php/8.1/fpm/pool.d/bitrix.conf:
[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
Розрахунок pm.max_children:
max_children = (Доступна RAM для PHP) / (Середній розмір процесу)
При 8 ГБ RAM, 2 ГБ під ОС, 1 ГБ під MySQL: 5 ГБ / 120 МБ = ~41. Беремо з запасом на ріст — 30–35.
pm = dynamic vs pm = static: dynamic економить пам'ять при низькому навантаженні. static кращий при стабільно високому навантаженні — немає накладних витрат на fork нових процесів.
pm.max_requests = 1000: перезапуск воркера після 1000 запитів запобігає витокам пам'яті. Характерно для проектів із великою кількістю сторонніх PHP-модулів.
Налаштування PHP для 1С-Бітрікс
/etc/php/8.1/fpm/php.ini (критичні для 1С-Бітрікс параметри):
; Пам'ять
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
session.save_handler = memcached — сесії в пам'яті замість файлової системи. Критично при кількох серверах (кластер) і прискорює доступ до сесій у 10–20 разів.
opcache.jit = tracing — JIT-компілятор PHP 8.0+. Для 1С-Бітрікс з його процедурним кодом дає 10–30% приріст CPU.
Окремі пули для різних завдань
Рекомендується розділяти пули:
bitrix.conf — основний сайт, 30 воркерів, 256M memory
agents.conf — агенти Бітрікс, 3–5 воркерів, 512M memory, довший timeout
import.conf — імпорт 1С, 1–2 воркери, 1G memory, 300s timeout
Агенти та імпорт 1С не повинні конкурувати з користувацькими запитами за воркери. Без розділення пул для імпорту може зайняти всі 30 слотів під час обробки прайсу.
Моніторинг
# Стежимо за статусом у реальному часі
watch -n1 'curl -s http://127.0.0.1/php-fpm-status | grep -E "active|idle|total"'
Якщо active processes стабільно дорівнює max_children — пул переповнено, запити ставляться в чергу. Потрібно або збільшити max_children, або оптимізувати код.