Конфігурація PHP-FPM для високонавантаженого 1С-Бітрікс

Сервер із 8 ГБ RAM та 4-ядерним CPU під навантаженням 50 одночасних користувачів гальмує до 5 секунд відповіді. top — 95% CPU на php-fpm, swap забитий. Дефолтна конфігурація PHP-FPM підходить для візиток, але не для Бітрікса з його важкою ORM та об'єктними кешами. При такому навантаженні час генерації сторінки може перевищувати 10 секунд, що катастрофічно позначається на користувацькому досвіді.

Ми налаштовуємо PHP-FPM під Бітрікс уже багато років — більше 50 проєктів за плечима. За цей час виробили конфігурації, які витримують 200+ одночасних користувачів на одному сервері. У цій статті — конкретні параметри та розрахунки для типового проєкту.

Чому дефолтний PHP-FPM не підходить для Бітрікс?

Дефолтний пул зазвичай pm = dynamic з pm.max_children = 5. Для магазину на Бітрікс із 50 користувачами цього мало — 5 воркерів блокуються повільними запитами, решта чекають у черзі. Результат: Timeout 504. Оптимізована конфігурація дає приріст швидкості в 2-3 рази порівняно зі стандартною.

Як розрахувати кількість воркерів?

Формула: max_children = (Доступна RAM для PHP) / (Середній розмір процесу). При 8 ГБ RAM, 2 ГБ під OS, 1 ГБ під MySQL: 5 ГБ / 120 МБ = ~41. Беремо із запасом на зростання — 30–35.

Діагностика поточного стану

Перед налаштуванням — знімок реальної картини:

# Кількість 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

Режими управління процесами: dynamic підходить для змінного навантаження — економить пам'ять при простої, але витрачає ресурси на fork. static мінімально затримує запити при стабільному навантаженні, але не адаптується до спаду. ondemand економить максимум при рідкісних піках, але викликає затримки при старті. Для більшості Бітрікс-проєктів обираємо dynamic.

pm.max_requests = 1000 — перезапуск воркера після 1000 запитів запобігає витокам пам'яті. Характерно для проєктів з великою кількістю сторонніх PHP-модулів.

Як ми налаштовуємо PHP-FPM покроково

1. Аудит поточного стану сервера за допомогою команд ps, curl статусу пулу.
2. Розрахунок pm.max_children на основі вільної пам'яті.
3. Створення окремих пулів для сайту, агентів та імпорту 1С.
4. Налаштування php.ini з JIT, Memcached для сесій, OPcache.
5. Конфігурація slowlog та моніторингу.
6. Тестування під навантаженням.

Налаштування PHP для Бітрікс

/etc/php/8.1/fpm/php.ini (критичні для Бітрікс параметри):

; Пам'ять
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+. Для Бітрікс з його процедурним кодом дає 10–30% приріст CPU.

Порівняння параметрів PHP за замовчуванням та оптимізованих:

Чому потрібно розділяти пули для агентів та імпорту 1С?

Рекомендується розділяти пули:

• bitrix.conf — основний сайт, 30 воркерів, 256M memory
• agents.conf — агенти Бітрікс, 3–5 воркерів, 512M memory, longer 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, або оптимізувати код.

Типові помилки при налаштуванні PHP-FPM

• Занадто маленький pm.max_children. Якщо max_children менше кількості паралельних запитів, запити стають у чергу. Рішення — розрахунок за формулою вище.
• Відсутність slowlog. Без slowlog ви не дізнаєтесь, які запити гальмують. Вмикаємо request_slowlog_timeout = 5s.
• Спільний пул для всіх завдань. Імпорт 1С та агенти повинні мати окремі пули, інакше користувацькі запити блокуються.

Що входить у налаштування під ключ

Ми пропонуємо комплексну послугу з оптимізації PHP-FPM для 1С-Бітрікс. До неї входить:

• Аудит поточної конфігурації сервера та PHP
• Розрахунок оптимальної кількості воркерів та розміру пулів
• Налаштування окремих пулів для агентів та імпорту
• Оптимізація OPcache та JIT
• Перенесення сесій на Memcached або Redis
• Налаштування slowlog та моніторингу
• Документація з конфігурації
• Гарантія стабільної роботи під навантаженням

Зв'яжіться з нами для безкоштовного аудиту вашої конфігурації PHP-FPM. Замовте налаштування під ключ і отримайте економію на серверних ресурсах від 10 000 до 30 000 гривень на місяць. Економія на серверних ресурсах після налаштування може досягати 40%, що при оренді сервера за 30 000 гривень на місяць становить 12 000 гривень економії.

Читайте також Wikipedia: PHP-FPM та Офіційна документація 1С-Бітрікс по PHP для поглибленого вивчення.

rsync -avz на продакшен у п’ятницю ввечері, рестарт php-fpm — і сайт відповідає 502, бо в .settings.php залишилися локальні налаштування БД. Деплой «по-старому» — лотерея. Оновлення модуля через адмінку ламає кастомний шаблон компонента, правки не зафіксовані в Git — відновлення займає години.

Ми проєктуємо передбачуваний DevOps-цикл для проєктів на Бітрікс: від Docker-середовища до алертів у Telegram. Кожен деплой стає рутиною, а не стресом.

Проблеми, які ми вирішуємо

Бітрікс історично жив у парадигмі «правимо файли по FTP на бойовому сервері». Результат: двоє розробників одночасно правлять init.php, затираючи зміни один одного. Оновлення модуля через адмінку ламає шаблон компонента — файли не зафіксовані в /local/templates/. Про падіння сайту дізнаються від клієнта, staging-середовища немає, перевірки йдуть на проді. Вартість такого підходу — години відновлення та втрата бізнес-логіки.

Чому DevOps критичний для Бітрікс-проєктів?

Проєкти на Бітрікс мають специфіку: важкий торговий каталог, обмін з 1С через CommerceML, безліч агентів та подій. Без CI/CD та моніторингу кожна зміна — ризик. Ручний деплой може спричинити тижневий простій. Після впровадження DevOps середня економія трудовитрат — до 12 годин ручної роботи на місяць, а бюджету підтримки — 15 000–25 000 грн на місяць. Наш 5-річний досвід (понад 50 проєктів на Бітрікс) і ліцензійна чистота рішень — гарантія стабільності.

Інструменти та конфігурація

CI/CD: від коміту до продакшену без рук

Git — переводимо проєкт з FTP на Git (GitLab, GitHub, Bitbucket). Структура гілок: main, staging, develop, feature-гілки. .gitignore під Бітрікс — нетривіальне завдання:

/bitrix/cache/
/bitrix/managed_cache/
/bitrix/stack_cache/
/upload/
/bitrix/php_interface/dbconn.php
/bitrix/.settings.php
/bitrix/license_key.php

Пропустиш managed_cache/ — репозиторій розпухне на гігабайти. Забудеш виключити license_key.php — ключ витече.

CI-пайплайн перевіряє код: PHPStan level 5+ ловить звернення до неіснуючих методів CIBlockElement, PHP_CodeSniffer з Bitrix-стандартом, PHPUnit для бізнес-логіки, composer audit, збірка фронту. CD-пайплайн розгортає без участі людини. Мерж у staging — деплой на staging. Мерж у main — деплой на production (з ручним підтвердженням або без). Zero-downtime через symlink-стратегію: нова версія в окремій папці, current → symlink перемикається за мілісекунди. upload/ живе поза релізними директоріями. При помилці healthcheck після деплою symlink відкочується. Інструменти: GitLab CI/CD, GitHub Actions, Deployer (PHP). Deployer зручний для Бітрікс — є готові рецепти для symlink-деплою та shared-директорій.

Як Docker вирішує проблему «у мене працює»?

Docker-середовище фіксує версії всіх компонентів: nginx, PHP, MySQL, Redis. Docker скорочує час розгортання нового розробника в 10 разів порівняно з ручним налаштуванням. Локальна розробка — docker-compose.yml включає nginx + php-fpm 8.1/8.2 + MySQL 8.0 (або MariaDB 10.6) + Redis + Memcached. Новий розробник: git clone + docker-compose up -d — за 5 хвилин пише код. Паралельна робота над різними версіями PHP — через окремі compose-файли.

Особливості Бітрікс у Docker: /upload/ монтується як named volume (не bind mount — інакше на Windows/Mac проблеми з правами та швидкістю). Cron-завдання (/bitrix/modules/main/tools/cron_events.php) — через окремий контейнер з тим же образом або supervisord. Модуль «Проактивний захист» (security) блокує запити через reverse proxy — потрібен правильний REMOTE_ADDR через set_real_ip_from та realip_module. bitrix/php_interface/dbconn.php та .settings.php задаються через змінні оточення.

Production: мультистейдж-збірка (build-стадія для асетів, production-стадія з легким образом), Docker Registry для тегованих образів, оркестрація через Docker Swarm або Kubernetes для великих проєктів.

Як правильно налаштувати nginx та php-fpm для Бітрікс?

Різниця між «сайт гальмує» та 200 ms TTFB — у конфігурації. nginx: location-блоки під Бітрікс обробляють urlrewrite.php для ЧПУ. /bitrix/admin/ закриває доступ по IP через allow/deny. expires 30d для статики — CSS, JS, зображення кешуються браузером. Brotli (стиснення на 15-20% ефективніше gzip) вмикається brotli on; brotli_comp_level 6;. Rate limiting на /bitrix/tools/ захищає від брутфорсу. HTTP/2 push для критичних ресурсів.

php-fpm: pm = dynamic, розрахунок pm.max_children за формулою (RAM - RAM_інших_сервісів) / avg_memory_per_process. Для Бітрікс avg зазвичай 40-80 MB. OPcache: opcache.memory_consumption=256 (стандартних 128 MB недостатньо — Бітрікс тягне тисячі файлів), opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 у продакшені (скидання через cachetool opcache:reset при деплої). php.ini: memory_limit=256M (для важких операцій імпорту до 512M), max_execution_time=60, upload_max_filesize=100M. Slowlog з request_slowlog_timeout=5s знаходить вузькі місця до скарг користувачів.

Інфраструктура та автоматизація

Моніторинг, логування та резервне копіювання

Як відбувається моніторинг та реагування на інциденти? Prometheus + Grafana: метрики CPU, RAM, диска, мережі, стану сервісів. Алерти: CPU > 80% за 5 хвилин, вільна RAM < 500 MB, диск > 85%, php-fpm queue > 0. Node Exporter, MySQL Exporter, PHP-FPM Exporter збирають дані з кожного компонента. Uptime check кожні 60 секунд — алерт у Telegram за хвилину при падінні сайту. Sentry для PHP-помилок — структуровані помилки з контекстом. Моніторинг агентів Бітрікс (b_agent): завислий агент може тихо ламати обмін з 1С годинами — перевіряємо NEXT_EXEC < NOW() - INTERVAL 1 HOUR. Логування: ELK Stack або Loki + Grafana — nginx access/error, php-fpm slow log, MySQL slow query log, помилки Бітрікс. Ротація через logrotate — без неї через півроку access.log займе 50 ГБ.

Staging-середовище ідентичне production: ті ж версії nginx, PHP, MySQL, модулі, налаштування php.ini. Автоматичне оновлення при мержі у staging-гілку. Періодичний клон БД з production з знеособленням персональних даних — UPDATE b_user SET EMAIL = CONCAT('user', ID, '@test.local'), PHONE = ''. HTTP Basic Auth або IP-фільтрація. Robots.txt з Disallow: /. Sandbox-режим платіжних шлюзів для тестування оплати.

Ansible як інфраструктура як код: ansible-playbook site.yml -l production — через 15 хвилин сервер налаштований ідентично. Ролі: common (users, SSH, NTP), web (nginx + php-fpm), db (MySQL + backup), monitoring (Prometheus + exporters). Ansible забезпечує налаштування сервера за 15 хвилин замість 3 годин вручну.

Географічна розподіленість — S3-сумісне сховище + окремий сервер в іншому ЦОД. Тестове відновлення щомісяця — бекап без перевірки лише ілюзія безпеки. Cron з повідомленнями: якщо беказ не пройшов — алерт одразу.

Що входить в роботу

• Документація DevOps-процесу (схема деплою, політика гілок, опис інфраструктури)
• Налаштовані CI/CD пайплайни (GitLab CI / GitHub Actions) з робочими тригерами
• Docker-середовище (docker-compose.yml, Dockerfile, конфіги)
• Ansible-плейбуки для відтворення серверів
• Моніторинг (Grafana дашборди, алерти в Telegram/Slack)
• Захищені доступи з ролевою моделлю
• Навчання команди: два заняття з роботи з CI/CD, Docker та деплоєм
• Підтримка на етапі впровадження (два тижні після запуску)

Приклад GitLab CI для Бітрікс (фрагмент):

stages:
  - test
  - build
  - deploy

cache:
  paths:
    - vendor/

unit_tests:
  stage: test
  script:
    - composer install --no-progress
    - php vendor/bin/phpunit

deploy_staging:
  stage: deploy
  script:
    - ansible-playbook deploy.yml -l staging
  only:
    - staging

Як проходить впровадження?

1. Аудит поточного стану — оцінка інфраструктури, софту, процесів. Займає 2-3 дні.
2. Проектування архітектури — вибір стеку (Docker/K8s/Ansible), узгодження політик CI/CD, налаштування репозиторію.
3. Налаштування середовищ — Docker-середовище для локальної розробки, staging-середовище, production-сервери.
4. Реалізація CI/CD — написання пайплайнів, тестування деплою, інтеграція з моніторингом.
5. Моніторинг та алертинг — встановлення Prometheus + Grafana, налаштування дашбордів та оповіщень.
6. Навчання команди — два заняття з роботи з інструментами.

Типові терміни впровадження

DevOps — не проєкт з фінальною датою, а перехід від «закинув по FTP і молюся» до передбачуваних процесів. Кожен деплой — рутина, кожен інцидент — алерт з контекстом, кожен новий розробник — docker-compose up замість триденного налаштування середовища. Отримайте консультацію — зв'яжіться з нами, і за 2-3 дні підготуємо план впровадження. Замовте DevOps-впровадження під ключ — отримайте стабільність і контроль над інфраструктурою.