Оптимизация Битрикс24: убрали зависания и 9 ГБ лишней памяти за один день
Оптимизация Битрикс24 в этом кейсе заняла один день: к нам обратилась оптовая торговая компания на 120 сотрудников, у которой коробочный портал каждое утро отдавал ошибки 502, карточки сделок открывались по 5–15 секунд, а добавление оперативной памяти не помогало. За один день работ мы провели экспресс-аудит, нашли четыре корневые причины и вернули порталу скорость без апгрейда сервера. Потребление памяти PHP-FPM упало с 9,3 ГБ до 1 ГБ, время отклика — с 5,2 до 0,8 секунды.
9,3 → 1 ГБ
Потребление RAM веб-стеком
5,2 → 0,8 с
Время отклика (TTFB)
1 день
От аудита до результата
Проблема: портал вставал по утрам, а железо было ни при чём
Менеджеры жаловались одинаково: с утра Битрикс24 «висит». Карточка сделки открывалась 5–15 секунд вместо нормальной секунды, в пиковые часы портал отдавал 502 Bad Gateway, и работа отдела продаж останавливалась на 10–20 минут. К полудню отпускало само.Внутренний админ пошёл по очевидному пути — добавил серверу оперативной памяти. Через две недели проблема вернулась в полном объёме. При этом графики мониторинга выглядели спокойно: процессор холодный, MariaDB отвечает за миллисекунды, swap почти пуст. Классическая ситуация, когда «по приборам всё хорошо», а пользователи каждый день теряют время. Почему так происходит в принципе, мы разбирали в гайде «Битрикс24 тормозит: причины и решение». Именно с этим запросом — «оптимизация Битрикс24 без бесконечного наращивания сервера» — компания и пришла к нам.
Решение: экспресс-аудит вместо апгрейда
Мы начали не с покупки ресурсов, а с замеров. За 60–90 минут экспресс-аудита по логам nginx, PHP-FPM и медленному логу MariaDB стало видно, что узкое место не в мощности железа, а в конфигурации стека.
Сложились четыре независимые причины. Первая: пул PHP-FPM держал десятки простаивающих воркеров, которые впустую занимали гигабайты памяти. Вторая: модуль «Почта» синхронизировался с внешними ящиками по блокирующему IMAP прямо в общем пуле — и в часы синхронизации воркеров не оставалось живым пользователям. Третья: файлы из облачного S3-хранилища Reg.ru уходили не напрямую, а через PHP, на каждый — отдельный воркер и TLS-рукопожатие вместо прямой отдачи через прокси nginx. Четвёртая: база данных работала на значениях по умолчанию, буферный пул InnoDB не вмещал рабочие данные. Поэтому оптимизация Битрикс24 в этом проекте свелась к настройке, а не к покупке дополнительных ядер и гигабайтов.
Этапы работы
Сняли метрики сервера, посчитали число 502 в логах nginx, разобрали медленный лог PHP-FPM и MariaDB, замерили реальное потребление памяти на один воркер. За полтора часа локализовали четыре независимые причины — без догадок и «пробного» апгрейда.
Перевели www-пул со стихийной динамики (pm = dynamic) на статический режим pm = static и рассчитали число воркеров по формуле «доступная память ÷ средний размер процесса» (≈40–60 МБ на воркер Битрикс24). Десятки простаивающих процессов перестали впустую занимать гигабайты, освободившийся запас ушёл под базу.
Вынесли синхронизацию IMAP в отдельный пул PHP-FPM с жёстким request_terminate_timeout. Теперь медленный или зависший почтовый ящик упирается в собственный лимит воркеров и не отнимает процессы у живых пользователей портала.
Добавили в nginx прямое проксирование S3 Reg.ru через X-Accel-Redirect: записи звонков и вложения из чатов уходят клиенту напрямую, минуя PHP. Включили Brotli на статике и текстовых ответах — меньше трафика и времени на отдачу.
Подняли innodb_buffer_pool_size под реальный рабочий объём, чтобы горячие данные жили в памяти, а не читались с диска. Поправили таймауты и размер пакета, вынесли всё в отдельный конфиг в /etc/my.cnf.d, который переживает обновления окружения.
Через сутки сравнили память, TTFB и число 502, зафиксировали результат и передали клиенту регламент профилактики — еженедельные, ежемесячные и ежеквартальные проверки, чтобы тормоза не вернулись по мере роста данных.
Результаты: скорость вернулась, бюджет на железо не понадобился
Главный итог — оптимизация Битрикс24 убрала зависимость портала от утренней синхронизации почты, и он стабильно держит нагрузку отдела продаж. Все изменения уложились в один рабочий день, апгрейд сервера не потребовался. Ниже — измеримый результат до и после работ.
| Метрика | До | После | За счёт чего |
|---|---|---|---|
| Потребление RAM веб-стеком | 9,3 ГБ | 1 ГБ | статический пул PHP-FPM вместо стихийной динамики |
| Время отклика (TTFB) на тяжёлых страницах CRM | 5,2 с | 0,8 с | буферный пул InnoDB и прямая отдача файлов через nginx |
| Утренние ошибки 502 в часы синхронизации почты | регулярно | 0 | изоляция IMAP в отдельном пуле PHP-FPM |
| Мусор в медленном логе PHP-FPM | ~21 МБ в неделю | десятки КБ | устранение блокирующих воркеров |
- Потребление памяти веб-стеком: с 9,3 ГБ до 1 ГБ — освободившийся запас ушёл под буферный пул базы.
- Время отклика портала (TTFB): с 5,2 до 0,8 секунды на тяжёлых страницах CRM.
- Утренние ошибки 502 в часы синхронизации почты прекратились.
- Медленный лог PHP-FPM очистился: с ~21 МБ мусора в неделю до десятков килобайт, диагностика реальных проблем снова стала возможной.
- Записи звонков и файлы из чатов открываются и перематываются мгновенно — отдача идёт напрямую с S3.
«Мы были уверены, что упёрлись в железо и надо закладывать бюджет на новый сервер. Вместо этого за день получили портал, который не висит по утрам, и подробный отчёт, что и почему было настроено. Отдел продаж сразу почувствовал разницу.»
Руководитель ИТ-отдела компании-клиента
Кому подходит это решение
Такая оптимизация Битрикс24 повторяется на коробочных порталах среднего размера почти дословно. Если узнаёте свою ситуацию — скорее всего, дело не в мощности сервера, а в настройке.
- Коробочный Битрикс24 на 50+ сотрудников, который тормозит или отдаёт 502, хотя мониторинг показывает свободные ресурсы.
- Портал с десятком и более подключённых почтовых ящиков, который встаёт именно в часы синхронизации почты.
- Установки с облачным S3-хранилищем (Reg.ru, FirstVDS и совместимыми), где медленно открываются файлы и записи звонков.
- Компании, которым предложили «просто добавить памяти», но эффект от апгрейда быстро сошёл на нет.
Часто задаваемые вопросы
Да, в большинстве случаев. Оптимизация Битрикс24 начинается с экспресс-аудита: чаще всего тормоза вызывает не нехватка мощности, а неоптимальная конфигурация PHP-FPM, базы данных и отдачи файлов. В этом кейсе мы вернули скорость только настройкой, апгрейд не потребовался.
Экспресс-аудит и устранение основных причин укладываются в один рабочий день, если есть доступ к серверу. Глубокая оптимизация под высокую нагрузку и внедрение регламента профилактики — отдельный этап на несколько дней.
Если не следить за ростом данных — со временем да. Поэтому мы передаём клиенту регламент еженедельных, ежемесячных и ежеквартальных проверок и при необходимости берём сервер на сопровождение, чтобы ресурсы наращивались заранее, а не по факту аварии.
Потому что лечится симптом, а не причина. Если память впустую занимают простаивающие воркеры PHP-FPM или портал блокируется медленной синхронизацией почты, новые гигабайты тоже закончатся — просто чуть позже. Сначала нужно найти доминирующую причину, а уже потом решать, нужен ли апгрейд.
Константин Тютюнник — основатель и инженер IT For Prof. Сопровождает корпоративную ИТ-инфраструктуру российского бизнеса: серверы, почтовые системы, мониторинг, корпоративные мессенджеры и платформы вроде Битрикс24. Делится практикой импортозамещения и self-hosted-решений в блоге и GitHub-организации IT-for-Prof.
Если коробочный Битрикс24 тормозит или отдаёт 502, а добавление ресурсов не помогает — проведём экспресс-аудит и настроим сервер под вашу нагрузку. Закажите сопровождение сервера Битрикс24.
