1C‑Битрикс на VDS: Nginx+PHP‑FPM, memcached и рекомендации по производительности

1C‑Битрикс предъявляет специфические требования к окружению: много PHP, активное дисковое и сетевое I/O, обширный кэш на уровне приложения и страницы, «тяжёлые» админ‑скрипты и интеграции. На VDS такую нагрузку удобнее всего держать на связке Nginx+PHP‑FPM с обязательным включением opcode‑кэша и внешнего in‑memory‑кэша. Ниже — практический план: от архитектуры до конкретных параметров, пригодных для большинства проектов на средних нагрузках. Если сервера ещё нет — подберите VDS с быстрыми SSD и достаточным объёмом RAM под ваш трафик и интеграции.

Архитектура: почему именно Nginx+PHP‑FPM и memcached

Классическая связка для Bitrix на VDS выглядит так: Nginx в роли фронтенда, PHP‑FPM как пул воркеров, база данных (чаще MySQL/MariaDB), и мемкеш для управляемого кэша и сессий. Nginx выдаёт статику, проксирует PHP, экономит память и эффективно работает под нагрузкой. PHP‑FPM позволяет точно лимитировать количество параллельных PHP‑процессов. Memcached снимает часть нагрузки с диска и базы за счёт хранения горячих данных в RAM.

Базовый принцип: «Сначала измеряй, затем оптимизируй». Любое изменение сопровождайте метриками — утилизацией CPU/RAM, количеством php‑fpm воркеров и пропускной способностью Nginx.

Подготовка окружения на VDS

Ниже — пример для Debian/Ubuntu. Идея та же и для других дистрибутивов, меняются названия пакетов и путей.

apt update
apt install nginx memcached php-fpm php-cli php-mysql php-xml php-gd php-curl php-zip php-mbstring php-intl php-bcmath php-opcache php-memcached
php -v
nginx -v
memcached -h

Убедитесь, что часовой пояс в PHP настроен корректно (через директиву date.timezone) и включён Opcache. Версию PHP выбирайте актуальную, поддерживаемую вашей редакцией Bitrix и модулями. Если удобнее работать через панель администрирования — оцените сравнение панелей для VDS.

Nginx: профиль для Bitrix

Bitrix требует корректной обработки «чпу» и штатных точек входа — в частности, /bitrix/urlrewrite.php. Для статики задаём длительные заголовки кеширования, для PHP — настраиваем fastcgi‑параметры, буферы и таймауты.

# /etc/nginx/conf.d/site.conf
server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/site/public;
    index index.php index.html;

    # Загрузка файлов и общие параметры
    client_max_body_size 64m;
    sendfile on;
    tcp_nopush on;
    keepalive_timeout 65s;
    keepalive_requests 1000;

    access_log /var/log/nginx/site_access.log;
    error_log  /var/log/nginx/site_error.log warn;

    # Статика: длительный кеш браузера
    location ~* \.(?:jpg|jpeg|png|gif|webp|avif|svg|css|js|ico|woff2?)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
        try_files $uri =404;
    }

    # Главная логика Bitrix (ЧПУ)
    location / {
        try_files $uri $uri/ /bitrix/urlrewrite.php?$args;
    }

    # Защита служебных файлов
    location ~* \.(?:htaccess|log|ini|sh|bak|conf)$ { deny all; }
    location ~* ^/(?:bitrix|upload)/.*\.(?:bak|tmp)$ { deny all; }

    # PHP: отправляем в php-fpm
    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        # сокет или порт - выберите свой
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;

        # Буферы и таймауты под тяжелые скрипты админки
        fastcgi_read_timeout 120s;
        fastcgi_connect_timeout 30s;
        fastcgi_send_timeout 60s;
        fastcgi_buffers 8 256k;
        fastcgi_buffer_size 128k;
        fastcgi_busy_buffers_size 256k;
        fastcgi_temp_file_write_size 256k;
    }
}

Ключевые моменты:

• try_files $uri $uri/ /bitrix/urlrewrite.php — критично для ЧПУ.
• client_max_body_size — подгоняйте под реальные лимиты загрузки в админке.
• Используйте unix‑сокет к PHP‑FPM, если Nginx и PHP на одном сервере: чуть меньше накладных расходов, чем TCP.
• Не раздавайте потенциально опасные расширения и резервные файлы.

Для продакшена обязательно включайте HTTPS и HSTS. Получить и подключить сертификаты можно через SSL-сертификаты.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

PHP‑FPM: пул, Opcache, realpath‑кеш

Правильная конфигурация пула — основа стабильности. Основной рычаг — ограничение числа воркеров и их «времени жизни» через pm.* и pm.max_requests. Для Bitrix полезно включить статус и ping для мониторинга.

# /etc/php/8.2/fpm/pool.d/www.conf (пример)
user = www-data
group = www-data
listen = /run/php/php8.2-fpm.sock
listen.owner = www-data
listen.group = www-data

pm = dynamic
pm.max_children = 12
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5
pm.max_requests = 500

; Завершать чрезмерно долгие запросы (интеграции бывают тяжелыми)
request_terminate_timeout = 120s

; Диагностика "тормозов"
request_slowlog_timeout = 5s
slowlog = /var/log/php8.2-fpm.slow.log

; Включим статус/пинг для наблюдения
pm.status_path = /fpm_status
ping.path = /ping
ping.response = pong

; Базовые лимиты, Opcache и кеше пути
php_admin_value[memory_limit] = 256M
php_admin_value[upload_max_filesize] = 64M
php_admin_value[post_max_size] = 64M
php_admin_value[max_execution_time] = 120
php_admin_value[realpath_cache_size] = 4096k
php_admin_value[realpath_cache_ttl] = 600
php_admin_value[opcache.enable] = 1
php_admin_value[opcache.memory_consumption] = 192
php_admin_value[opcache.interned_strings_buffer] = 16
php_admin_value[opcache.max_accelerated_files] = 100000
php_admin_value[opcache.validate_timestamps] = 1
php_admin_value[opcache.revalidate_freq] = 2

Как оценить pm.max_children? Прикиньте средний RSS одного PHP‑процесса под типовой нагрузкой (например, 120–180 МБ для Bitrix с плагинами) и выделите под пул фиксированный бюджет памяти. Пример: при 2 ГБ RAM на PHP и среднем 150 МБ на процесс получаем около 13 воркеров, ставим с запасом 10–12. Слишком маленькое значение даст очереди и 504, слишком большое — своп и 502. Обязательно включите Opcache (он уже задан выше). opcache.memory_consumption в районе 128–256 МБ на средних проектах обычно достаточно; контролируйте заполнение по метрикам.

Memcached: управляемый кеш и сессии

Bitrix умеет хранить управляемый кеш и сеансы в memcached. Это снижает нагрузку на диск и БД, ускоряет повторные запросы. Настроим сам демон и клиентское расширение PHP.

# /etc/memcached.conf (пример)
-m 512        # объем в MB
-p 11211      # порт
-l 127.0.0.1  # слушаем только localhost
-U 0          # отключить UDP
-c 2048       # одновременные подключения
-t 4          # число потоков memcached
-I 2m         # max размер одного объекта

systemctl enable --now memcached
ss -lntp | grep 11211

В PHP используйте расширение php-memcached. В админке Bitrix укажите сохранение сессий в memcached и включите управляемый кеш. Для надёжности запрещайте доступ извне к порту 11211 (локальный bind уже делает это), а в фаерволе оставляйте только 127.0.0.1.

Сессии в memcached уменьшают диск I/O при высокой параллельности. Главное — не допускать переполнения памяти: следите за показателем evictions в статистике memcached.

Проверка работы memcached

echo "stats" | nc 127.0.0.1 11211

Посмотрите ключевые счётчики: curr_items, bytes, get_hits/get_misses, evictions, limit_maxbytes. При росте evictions увеличивайте -m либо оптимизируйте TTL и объём кэша на стороне приложения.

Настройки под Bitrix: что чаще всего помогает

• Загрузка файлов: выставьте в PHP‑FPM значения upload_max_filesize и post_max_size с запасом; в Nginx — client_max_body_size не меньше этих значений.
• Буферы FastCGI: увеличенные fastcgi_buffers и fastcgi_buffer_size снижают вероятность временных файлов и перерасхода I/O при тяжёлых ответах.
• realpath cache: повышает скорость файловых операций Bitrix за счёт кеширования резолвинга путей. На проектах с большим числом include — заметный плюс.
• pm.max_requests: 300–800 помогает «подстригать» возможные утечки памяти в PHP‑коде длительно работающих воркеров.
• Оптимизация статики: долгие expires и Cache-Control снижают RPS на сервер. Для динамики — полагайтесь на «Композитный сайт» Bitrix и memcached.

Мониторинг и диагностика

PHP‑FPM статус и slowlog

Мы включили /fpm_status и /ping в пуле. Добавьте их в Nginx, ограничив доступ по IP.

# Фрагмент локаций для статуса FPM
location = /fpm_status {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    allow 127.0.0.1;
    deny all;
}
location = /ping {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    allow 127.0.0.1;
    deny all;
}

Смотрите очередь (listen queue), занятые воркеры и средние времена. Slowlog укажет «узкие» места в PHP‑коде и сторонних интеграциях.

Nginx логи

Контролируйте распределение статуса ответов, общее время ответов и пики нагрузки. Ошибки 502/504 подскажут, где искать: 502 — вместе с PHP‑FPM (пул, память, падения), 504 — чаще таймауты на стороне PHP‑логики или внешних сервисов.

Memcached статистика

Регулярно сверяйте хиты/промахи и показатель evictions. Если доля промахов высока, проверьте корректность подключений Bitrix к memcached и TTL ключей. Если наблюдаются выселения, увеличьте память или облегчите кэш на уровне приложения.

Типичные проблемы и быстрые решения

• 502 Bad Gateway: чаще всего закончилась память, php‑fpm воркеры падают, либо превышен pm.max_children и пул не успевает обслужить очередь. Проверьте OOM‑события, уменьшите средний per‑process RSS (отключите лишние расширения) или подберите новый баланс pm.max_children/memory_limit.
• 504 Gateway Timeout: скрипт работает дольше, чем fastcgi_read_timeout или request_terminate_timeout. Увеличьте таймауты с пониманием причин длительной работы (импорт, отчёт, интеграция) и вынесите тяжёлые операции в задачи по расписанию или очереди.
• Статика не кешируется: проверьте expires/Cache-Control, отсутствие заголовка no-store и корректность путей сборки ассетов.
• Memcached «сбрасывает» ключи: признак переполнения. Увеличьте -m, снизьте TTL или сократите объём кэшируемых структур.
• Ждём диск: если логи показывают много временных fastcgi‑файлов, увеличьте fastcgi_buffers/fastcgi_buffer_size и проверьте наличие свободного места в каталоге temp.

План емкостной оценки: сколько воркеров и памяти?

1. Запустите стендовую нагрузку или наблюдайте прод на пике.
2. Зафиксируйте средний RSS одного PHP‑процесса и 95‑й перцентиль.
3. Решите, какой объём RAM выделяете под пул (оставьте запас под ОС, Nginx, memcached и файловый кеш).
4. Вычислите грубо pm.max_children ≈ RAM_под_пул / avg_RSS, скруглите вниз и закладывайте запас 10–20%.
5. Настройте pm.max_requests 300–800, чтобы сгладить утечки.

Практические мелочи, которые часто забывают

• Локаль и таймзона: некорректная локаль может ломать сортировки и сравнения строк. В PHP задайте date.timezone.
• Разрешения и владелец: веб‑корень должен принадлежать пользователю пула. Иначе — случайные 403/404 и проблемы с кэшем.
• Логи и ротация: убедитесь, что ротация включена, иначе полный диск остановит всё окружение.
• TCP backlog: при очень пиковых RPS проверьте системные лимиты соединений и worker_connections у Nginx.
• Сеансы: храните в memcached, чтобы не блокировать файловую систему при высоком параллелизме.

Если предстоит перенос сайта на новый сервер, используйте контролируемый сценарий без простоя — пригодится материал про миграцию сайта без даунтайма.

Мини‑чек‑лист перед релизом

• Nginx корректно обрабатывает ЧПУ через /bitrix/urlrewrite.php.
• PHP‑FPM: pm.max_children рассчитан, включены slowlog, статус и pm.max_requests.
• Opcache включён, заполнение < 90% под пиковой нагрузкой.
• Memcached слушает только 127.0.0.1, параметра -m хватает без evictions.
• Логи и ротация настроены, диск с запасом свободного места > 20%.
• Таймауты Nginx/PHP согласованы с реальными длительными операциями.
• Статика отдаётся Nginx с долгими заголовками кеширования.

Резюме

Для 1C‑Битрикс на VDS связка Nginx+PHP‑FPM и memcached — надёжная «рабочая лошадка». Упор делаем на три вещи: аккуратный лимит воркеров PHP‑FPM, полноценный opcode‑кэш и перенос горячих данных в память через memcached. Дополнительно выигрываем за счёт бережной настройки fastcgi‑буферов и разумных таймаутов. Начните с приведённого профиля, замерьте метрики, подстройте под свою нагрузку — и получите ощутимый прирост производительности без избыточной сложности.