Конфигурация 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 остались локальные настройки подключения к БД. Классическая ситуация: деплой «по старинке» превращается в лотерею. Другой пример: обновление модуля через админку ломает кастомный шаблон компонента — правки не зафиксированы в системе контроля версий, и восстановление занимает часы.

Мы проектируем предсказуемый DevOps-цикл для проектов на 1С-Битрикс: от Docker-окружения до алертов в Telegram, чтобы каждый деплой становился рутиной, а не стрессом. Ниже — как именно мы решаем реальные проблемы Битрикс-команд.

Проблемы, которые решаем

Битрикс исторически жил в парадигме «правим файлы по FTP на боевом сервере». Сегодня так работают десятки команд. Результат — двое разработчиков одновременно правят init.php, затирая изменения друг друга. Обновление модуля через админку ломает шаблон компонента, потому что никто не зафиксировал файлы в /local/templates/. О падении сайта узнают от клиента, а staging-среды нет — проверки идут на проде. Стоимость такого подхода — часы восстановления и потеря бизнес-логики. Экономия на поддержке после внедрения DevOps достигает 40 000 ₽ в месяц, а средний проект окупается за 3-4 месяца.

Почему DevOps критичен для Битрикс-проектов?

Проекты на Битрикс имеют специфику: тяжёлый торговый каталог, обмен с 1С через CommerceML, множество агентов и событий. Без CI/CD и мониторинга каждое изменение становится риском. Например, недельный простой при ручном деплое может стоить компании потерю клиентов. Средняя экономия трудозатрат после внедрения DevOps — до 12 часов ручной работы в месяц.

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

Git — переводим проект с FTP на Git (GitLab, GitHub, Bitbucket). Структура веток: main (production), 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. Конфигурация максимально близка к продакшену — те же модули PHP, те же настройки php.ini.

Локальная разработка — 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 задаются через переменные окружения, а не через volume с продакшен-конфигами.

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

Как правильно настроить 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 за минуту при падении сайта. Время отклика ключевых URL: /, /catalog/, /personal/order/make/. 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-среда

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

Ansible: инфраструктура как код

Новый сервер? ansible-playbook site.yml -l production — через 15 минут всё настроено идентично текущему. Плейбуки покрывают nginx, php-fpm, MySQL, Redis, certbot, firewall. Роли переиспользуемые: common (users, SSH, NTP), web (nginx + php-fpm), db (MySQL + backup), monitoring (Prometheus + exporters). Идемпотентность — повторный запуск ничего не ломает. Inventory: [production], [staging], [development] для групп серверов. Подробнее — Ansible Documentation.

Резервное копирование

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

Что входит в работу

Наш 5-летний опыт (более 50 проектов на Битрикс) позволяет предоставить полный набор результатов для услуги DevOps для 1С-Битрикс:

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

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-внедрение под ключ — получите стабильность и контроль над инфраструктурой.