Битрикс24 тормозит: 10 причин, экспресс-аудит коробки и план действий

Битрикс24 тормозит: страницы портала открываются по 5–15 секунд вместо нормальной секунды, чаты подвисают, CRM-формы не сохраняются, в худших случаях — ошибки 502 Bad Gateway. Для бизнеса это не «технический нюанс»: задержка 10 секунд на каждое действие у 100 сотрудников складывается в тысячи потерянных рабочих часов в месяц, сорванные звонки и сделки, а 502 в момент сохранения счёта — прямой риск потери данных.

Главный вопрос руководителя: насколько это серьёзно и когда пора звать специалистов? Часть проблем решается настройкой за пару часов, другая — сигнал, что сервер работает на пределе. Эта статья помогает увидеть разницу — и администратору, и тому, кто принимает решение.

Когда Битрикс24 тормозит, симптомы редко складываются в чёткую картину сами по себе: пользователи жалуются на «медленный портал», техподдержка видит редкие 502 в логах, мониторинг показывает локальные пики CPU. Наша задача на старте — перевести разрозненные жалобы в количественные метрики, чтобы было что воспроизводить и измерять. Без этого шага оптимизация превращается в гадание, а не в инженерную работу.

Базовый минимум, который мы фиксируем при первом контакте, это пять признаков, встречающихся почти в каждом нашем аудите.

Каждая строка таблицы должна стать измеримым фактом: 147 ошибок 502 за сутки вместо «иногда не работает», TTFB 4,2 с на карточке сделки вместо «карточка открывается долго». Когда мы приходим на новый проект, первое, что просим у заказчика, это конкретные URL и точное время суток, когда Битрикс24 тормозит сильнее всего. Такая конкретика сокращает поиск причины в разы и сразу отсекает половину гипотез.

Помимо очевидных симптомов стоит фиксировать неочевидные: сообщения Out of Memory в /var/log/messages, таймауты конкретных модулей (телефония, открытые линии), зависание отдельных бизнес-процессов. На нашей практике именно эти «фоновые» сигналы первыми указывают на исчерпание ресурсов и видны за неделю-две до того, как пользователи начнут массово жаловаться. Если в логах появились первые OOM, считайте это предупредительным выстрелом.

Не делайте вывод о причинах по одному симптому: мы сталкивались со случаем, когда заказчик месяцами наращивал CPU, считая виновником загрузку процессора, а реальной проблемой оказался раздутый журнал событий b_event_log, упиравший буферный пул InnoDB в потолок. После архивации таблицы нагрузка вернулась в норму без апгрейда железа.

При сигнале «Битрикс24 тормозит» первый час работы критически важен: за 60–90 минут можно отсечь 7 из 10 типовых причин и понять, нужны ли срочные меры или плановая оптимизация. У нас аудит разбит на 8 шагов примерно по 10 минут каждый.

Шаг 1. Базовые метрики сервера. Снимаем загрузку CPU, RAM, дисков и PSI (Pressure Stall Information для ядер 4.20+). Тревожные индикаторы: LA выше числа ядер, %iowait стабильно больше 5%, использование swap свыше 500 МБ, свободного места меньше 10–15%.

PSI точнее традиционного %iowait, потому что показывает реальный процент времени, когда процессы ждали ресурс. Значение avg10 выше 10 для some — повод разбираться, выше 25 для full указывает на серьёзную проблему.

Шаг 2. Веб-сервер и PHP-FPM. Считаем 502/504 в логах nginx, ищем сообщения max_children reached и долю 5xx в access.log. Если сообщение про max_children встретилось хотя бы раз, у воркеров кончилось место в очереди, и пользователи получают таймауты.

Шаг 3. Анализ базы данных. SHOW FULL PROCESSLIST показывает зависшие SELECT, mysqltuner даёт быструю общую картину, pt-query-digest строит топ медленных запросов по slow-log. На крупных порталах мы временно включаем slow-log на 10–30 минут с порогом 1 сек, собираем выборку и выключаем обратно: постоянно включённый slow-log сам становится источником I/O-нагрузки.

Шаги 4 и 5. Встроенный мониторинг и диагностика страниц. Запускаем «Монитор производительности» (балл ниже 30 указывает на серьёзную проблему), проверяем «Проверку системы» и включаем режим ?DEBUG=Y на самых медленных страницах. Если компонент crm.timeline даёт 5 секунд и 250 SQL-запросов, это уже маркер причины 6 или 9, а не общей перегрузки сервера.

Шаг 6. Агенты Bitrix24. Смотрим /bitrix/admin/agent_list.php, ищем просроченные записи и растущий retry_count. Если вверху страницы предупреждение, что агенты работают без cron, дальше можно не разбираться: первая мера — перевести запуск на crontab. Без этого агенты дёргают пользовательские хиты и съедают тот же воркер PHP-FPM, на котором сидит человек.

Шаги 7 и 8. Опрос пользователей и сведение находок. Спрашиваем, когда Битрикс24 тормозит сильнее всего, всех ли касается или только бухгалтерии, после какого изменения началось. Эти ответы вместе с метриками формируют карту, по которой видно, какие из 10 причин (C1–C10) бьют по производительности. Сведение делаем в формате таблицы: что нашли, метрика-доказательство, гипотеза по C1–C10, приоритет (критично, срочно, плановое). Без приоритизации оптимизация скатывается в борьбу с симптомами вместо причин.

Десять причин, по которым на наших проектах Битрикс24 тормозит чаще всего, делятся на три уровня: инфраструктурный, серверный и прикладной. Такое разделение помогает понять, чем лечить: апгрейдом, конфигурацией или организационными мерами.

Инфраструктурный уровень — причины 1–3: медленный дисковый ввод-вывод, нехватка RAM и перегрузка CPU. Признаки диска: %iowait стабильно выше 5–10%, await двузначный в миллисекундах, %util около 100%. Нехватка памяти видна по swap больше 500 МБ, ненулевым si/so в vmstat и сообщениям OOM Killer в dmesg. Перегрузка CPU характерна сочетанием LA выше числа ядер и %idle около нуля, а на VPS ещё и %steal больше 5%, означающим, что соседи по гипервизору забирают ресурсы.

Серверный уровень — причины 4–6. Веб-стек страдает, когда статика (.css, .js, .jpg) проксируется через PHP-FPM вместо прямой отдачи nginx через try_files, когда отсутствует gzip или brotli, когда брошены дефолтные значения worker_connections; сетевые требования и порты коробки мы разбираем в отдельном материале о портах Битрикс24. Отдельно держите сам веб-сервер в актуальной версии: о критической уязвимости nginx и безопасном обновлении без простоя мы рассказали в разборе NGINX Rift (CVE-2026-42945). PHP-FPM упирается в pm.max_children: формула расчёта такая: (Доступная RAM минус RAM_MySQL минус RAM_Redis минус RAM_ОС) делённая на средний RSS воркера. На реальном проекте мы видели pm.max_spare_servers = 35 при RSS 209 МБ, что означало 7,3 ГБ только на idle-воркеры; после перевода на pm = static и max_children = 60 потребление упало с 9,3 до 0,975 ГБ, TTFB с 5,2 до 0,8 с. Проблемы БД проявляются в SHOW FULL PROCESSLIST: SELECT висят дольше 5 секунд, hit rate InnoDB buffer pool падает ниже 99%, типичные «тяжёлые» таблицы Bitrix24 на нашей практике: b_event_log, b_bp_tracking, b_im_message, b_disk_object, b_sale_order.

Прикладной уровень — причины 7–10. Агенты Bitrix24 без перевода на cron запускаются на хитах и тормозят веб-запросы; признак в b_agent: просроченное NEXT_EXEC и растущий RETRY_COUNT. «Мусор» в данных накапливается в b_bp_tracking, /bitrix/cache/, /bitrix/managed_cache/, /upload/resize_cache/; на аудите типичен бакет S3 на 76–105 тыс. файлов и более 200 ГБ. Кастомный код и модули из /local/ ломают производительность скрытно: внешние API-вызовы дольше 1–2 с, забытый ‘debug’ => true в .settings.php, тяжёлые обработчики OnAfter* без кеширования; а если сайт ещё и заражён, тормоза — наименьшая из бед (как мы вычищали Битрикс после вирусной атаки). Некорректная эксплуатация проявляется в чатах на 1000+ человек, сотнях наблюдателей в каждой задаче, бизнес-процессах для массовых рассылок: Push&Pull захлёбывается, обновление счётчиков превращается в лавину.

Не делайте апгрейд при прикладной причине: у нас был заказчик, который удвоил RAM на сервере, где b_bp_tracking занимал 9 ГБ, и выигрыш составил две недели, после чего портал снова встал. Лечение всегда идёт по доминирующей причине, а не по самой удобной для устранения.

Ниже — реальные конфигурации с боевых серверов под эти причины, каждая копипастабельна: nginx-блок для Reg.ru S3 и Brotli (причина 4, веб-стек), статический пул PHP-FPM (причина 5), запрос для аудита S3-бакета (причина 8), реальный Apache MPM event против мёртвого блока worker.c (причина 4) и MySQL z_bx_custom.cnf (причина 6).

Метрики без контекста бесполезны: 70% CPU при равномерной нагрузке означает здоровый сервер, та же цифра с двукратным трендом за месяц сигнализирует, что Битрикс24 тормозит уже сейчас на пиках, а через две недели встанет полностью. Поэтому мы фиксируем не только моментальные значения, но и тренды за период не меньше 30 дней.

Базовый набор ориентиров, на которые мы опираемся при аудите:

Несколько практических замечаний по интерпретации. Высокий iowait при заведомо быстром NVMe означает не проблему диска, а избыточный I/O на уровне софта: разросшийся slow-log MySQL, бесконтрольная запись логов nginx, паразитный fsck по расписанию. Hit rate InnoDB buffer pool ниже 99% не всегда сигнализирует о маленьком пуле: возможно, кто-то регулярно делает полные сканирования по неиндексированным полям и вытесняет рабочие страницы. PSI io some avg10 выше 10% мы считаем приоритетнее iowait, потому что PSI учитывает реальное ожидание процессов, а не среднее по всем CPU.

TTFB в 0,5 секунды на главной портала и 4 секунды на карточке сделки даёт «средний TTFB 2 секунды», но это две разные истории. Мы всегда измеряем TTFB по сценариям: главная, список лидов, открытая карточка сделки, страница задачи с десятью комментариями, окно чата. Между ними бывает кратная разница, и общий усреднённый показатель её скрывает.

Тренды важнее моментальных значений: если за месяц latency диска выросла вдвое, дело не в моментальной нагрузке, а в накоплении данных или деградации носителя. Поэтому мы настраиваем сбор метрик в Zabbix или Prometheus + Grafana с хранением минимум на 90 дней. Без исторических данных любой пик трактуется как случайность, а через полгода окажется, что портал плавно деградировал, и нет точки отсчёта.

Профилактика дешевле авралов: это аксиома, проверенная нами на десятках проектов. Регламент, который мы внедряем у заказчиков, состоит из трёх горизонтов (еженедельный, ежемесячный, ежеквартальный) плюс непрерывный автоматический мониторинг.

Еженедельный цикл занимает 30–60 минут и включает четыре проверки: загрузка ресурсов (CPU, RAM, диск, swap) на устойчивые аномалии; логи nginx, PHP-FPM и MySQL на ошибки 502, timeout, OOM; работоспособность интеграций (1С, телефония, внешние сервисы); статус алертов мониторинга. Главное правило еженедельной проверки: если алерт срабатывал и был «потушен» без анализа причины, его нужно повторно расследовать, иначе через месяц он сработает в худший момент.

Ежемесячный цикл шире: аудит объёма данных (размер БД, /upload/, кешей), OPTIMIZE TABLE для таблиц с большим Data_free в нерабочее время, обновление Bitrix24 и пакетов ОС с обязательным бэкапом до и проверкой после, тестовое восстановление из бэкапа на стенде, анализ трендов LA, swap и числа slow queries за месяц. Тестовое восстановление чаще всего «забывают»: бэкап есть, а вот что он восстанавливается полностью и портал стартует на чистой машине, проверяют только когда уже горит. Не делайте так: мы участвовали в восстановлении после сбоя у заказчика, который не проверял бэкапы 14 месяцев; половина дампов оказалась битой, восстановление заняло 36 часов вместо плановых 2–3.

Ежеквартально проводим полный аудит по тем же 8 шагам экспресс-аудита, планирование ёмкости (при текущем тренде роста, когда закончатся ресурсы), тест аварийного восстановления (failover на резервный узел), ревизию регламентов, опрос пользователей об удовлетворённости скоростью портала. Опрос важен как нетехнический инструмент: иногда метрики «зелёные», а 30% сотрудников жалуются на конкретный сценарий, который мы не фиксировали отдельно.

Автоматический мониторинг 24/7 строим на Zabbix, Prometheus + Grafana или их аналогах — его можно вынести на наш мониторинг сайта и сервера. Минимальный набор алертов, который мы ставим в первую очередь:

• CPU выше 90% дольше 10 минут — уведомление в чат;
• свободного места меньше 10% — уведомление в чат;
• ошибки 502 больше 5 за час — уведомление в чат;
• swap больше 1 ГБ — уведомление в чат;
• сайт недоступен 2+ минуты — звонок или SMS ответственному.

Внешние проверки доступности (UptimeRobot, StatusCake) обязательны: внутренний мониторинг падает вместе с сервером и в момент аварии молчит. На наших проектах правило простое: если о падении сообщил пользователь, а не алерт, это инцидент в работе мониторинга, который разбирается так же серьёзно, как сам сбой.

Когда Битрикс24 тормозит, итоговая сводка нужна, чтобы за 30 секунд оценить картину и собрать план действий: что критично, что подождёт, что требует ресурсов. Эту таблицу мы используем как чек-лист в финальном отчёте по аудиту, на её основе формируем приоритеты и оценку трудозатрат для заказчика.

Несколько правил, которыми мы пользуемся при работе с этой таблицей. Первое: критичные пункты (502 в продакшене, OOM Killer, зависшие процессы) делаем немедленно, независимо от плановых работ. Второе: quick wins (noatime, очистка кешей, перевод агентов на cron) запускаем в первые 1–2 дня, поскольку они не требуют закупки и согласований. Третье: стратегические меры (апгрейд RAM, перенос на SSD, миграция БД на отдельный сервер) выносим в отдельный план с обоснованием через расчёт ёмкости.

Не пытайтесь закрыть все 10 причин одновременно. На нашей практике это всегда заканчивается тем, что после серии параллельных изменений невозможно понять, какое именно дало эффект, а какое — регресс. Идём по одной причине за раз: измерили исходные метрики, изменили параметр, измерили снова, зафиксировали результат. Когда Битрикс24 тормозит из-за нескольких причин одновременно, последовательная работа займёт неделю-две; параллельная займёт месяц с риском внести новые проблемы.

«Измерили → изменили одно → измерили снова» — этого принципа держимся в любой оптимизации. Когда Битрикс24 тормозит, соблазн поменять сразу пять параметров велик, но именно это превращает оптимизацию в гадание. Документируйте каждое изменение: какой параметр, с какого значения на какое, когда применили, через сколько и какие метрики поменялись. Без такого журнала через две недели не получится откатить изменение, которое внесло регресс.

Экспресс-аудит за 60–90 минут покажет, где болит, и поможет приоритизировать работы. Quick wins из каждого раздела (от noatime и очистки кешей до правильного pm.max_children) дают первые ощутимые результаты в пределах рабочего дня. Регламент еженедельных, ежемесячных и ежеквартальных проверок превращает обслуживание из реактивного в проактивное: ресурсы наращиваются заранее, лог-таблицы архивируются по расписанию, бэкапы проверяются регулярно, а не «как-нибудь потом».

Разумно разделять, что закрывается своими силами, а когда разумнее позвать внешних специалистов. Если в команде есть Linux-администратор с опытом nginx, PHP-FPM, MySQL и доступом к серверу, описанная методика закрывает большинство кейсов. Если такого специалиста нет или его время уходит на другие задачи, экспресс-аудит и квартальный регламент — это та работа, которую разумно вынести на внешнее администрирование серверов: фиксированный объём, измеримые метрики, понятный результат за известную цену.

Не забывайте о расчёте ёмкости. По нашим данным средний коробочный портал на 100–150 сотрудников растёт в объёме данных на 20–30% в год. Это значит, что подобранный «впритык» сервер через 1,5–2 года вернёт ту же проблему: вы снова увидите, что Битрикс24 тормозит на тех же сценариях, но уже из-за накопленного объёма, а не конфигурации. Закладывайте запас не меньше 50% по RAM и дисковому пространству и держите план апгрейда на ближайший горизонт.

Техническая документация по ключевым механизмам из статьи: PSI в ядре Linux, InnoDB buffer pool в MariaDB, try_files в nginx и vmstat для диагностики памяти.

Тормоза коробочного Битрикс24 почти всегда лечатся настройкой PHP-FPM, MySQL и дисковой подсистемы, а не покупкой нового сервера.

Константин Тютюнник — ведущий инженер IT For Prof. Специализируется на высоконагруженных проектах на базе 1С-Битрикс. За 10 лет практики развернул и оптимизировал более 200 серверных инфраструктур для коробочных версий Битрикс24. Эксперт в тюнинге MySQL, Nginx и PHP-FPM для обеспечения отказоустойчивости бизнес-критичных систем.