Диагностика проблем производительности сайта на Битрикс24: с чего начать, какие логи смотреть, типичные узкие места

Введение

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

Объединяет их одно: симптомы разные, а корень часто один и тот же. Проблемы производительности Битрикс24 редко бывают уникальными. Обычно это комбинация из трёх-четырёх типовых узких мест, которые накладываются друг на друга и создают впечатление, что «портал сломался».

В этой статье — методология, по которой мы диагностируем такие обращения. Без магии и без «надо просто перезагрузить сервер». Только воспроизводимые шаги, конкретные логи и типичные причины.

Симптомы, по которым звонят клиенты

Прежде чем лезть в логи, полезно соотнести симптом с вероятной причиной. За годы практики сложилась примерная карта:

«Поиск зависает» — в 80% случаев проблема в индексе поиска. Либо переполнилась таблица b_search_index, либо cron переиндексации не отрабатывает, либо модуль поиска упёрся в лимит памяти. Реже — проблема в морфологии или в том, что ищут по кастомному полю без индекса.

«Портал не открывается» — здесь три главных подозреваемых. Первый: кончилось место на диске (сессионные файлы, кеш, логи). Второй: упала база данных или кончились коннекты. Третий: ошибка в кастомном коде, которая кладёт PHP при загрузке страницы.

«Битрикс24 тупит, почта не работает» — самое размытое описание, но обычно означает очередь агентов. Когда cron не справляется с объёмом отложенных задач, начинает тормозить всё: отправка писем, выполнение роботов, уведомления, поисковая индексация.

С чего начать диагностику: чек-лист на первые 10 минут

Когда клиент звонит с проблемой производительности, первые 10 минут решают, найдёте вы причину за час или будете гадать три дня. Порядок действий:

1. Проверить жив ли сервер

В случае с Имексом портал «не работал» потому, что на VDS кончилось место. Сессионные файлы заняли 40 ГБ, а мониторинг диска не был настроен. Клиент был уверен, что проблема в обновлении Битрикс24 — на деле диск был забит под завязку.

df -h
free -h
top -bn1 | head -5

Три команды, которые сразу показывают: есть ли место, есть ли память, не висит ли процесс на 100% CPU.

2. Открыть страницу performance в админке

Настройки → Производительность → Панель производительности. Эта страница даёт срез по ключевым метрикам без копания в логах:

Сессии и хиты — сколько пользователей сейчас на портале и сколько запросов в секунду
Кеш — процент попаданий и текущий размер
Агенты — сколько в очереди и сколько выполняется прямо сейчас

Если вкладка «Агенты» показывает больше 50 невыполненных агентов — вот причина «тупит Битрикс24». Это как раз был случай Гостя Кабеля: 240 зависших агентов, включая почтовые.

3. Проверить логи Битрикс24

Главный журнал, с которого стоит начинать — /bitrix/modules/main.log. Если его нет или он пустой, включите:

Настройки → Инструменты → Журнал событий → Настройка журнала.

Для диагностики производительности нужны как минимум три типа событий: main (ошибки ядра), search (индексация и поиск), mail (отправка писем).

Какие логи смотреть и в каком порядке

Логи Битрикс24 — это слоёный пирог. Каждый слой отвечает за свой уровень, и прыгать между ними без системы — верный способ потерять час и ничего не найти.

Слой 1: Журнал событий (админка)

То, что видно сразу и без доступа к серверу. Идём в Настройки → Инструменты → Журнал событий. Сортируем по типу события:

main — ошибки инициализации, фаталы, проблемы с подключением к БД
search — ошибки индексации, переполнение индекса, таймауты поиска
mail — ошибки подключения к SMTP, отклонённые письма

Фильтруем по последним 24 часам и смотрим количество ошибок. Для victoryshop журнал search показал 1400+ ошибок «не удалось проиндексировать» за сутки. Причина оказалась в cron — задача переиндексации падала из-за нехватки памяти.

Слой 2: Логи веб-сервера

tail -500 /var/log/nginx/error.log | grep -E "(upstream timed out|502|504)"
tail -500 /var/log/nginx/access.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -10

Первая команда показывает таймауты и ошибки шлюза — верный признак, что PHP не успевает ответить за отведённое время. Вторая — топ-10 самых долгих запросов.

В случае Имекса access.log показал, что 80% запросов уходят в /bitrix/admin/ с временем ответа больше 30 секунд. Это указывало на проблему в административной части, а не на фронтенде.

Слой 3: PHP-логи

tail -1000 /var/log/php-fpm/error.log | grep -E "(Allowed memory size|Maximum execution time|Fatal error)"
tail -200 /var/log/php-fpm/slow.log

Slow log — недооценённый инструмент. Он показывает конкретные скрипты, которые выполняются дольше заданного порога (обычно 5–10 секунд). Для Гостя Кабеля slow log показал, что cron_events.php висит по 45 секунд на каждой итерации — почтовые агенты блокировали всю очередь.

Слой 4: Логи базы данных

tail -500 /var/log/mysql/slow.log

Медленные запросы к базе — частая причина «тупит портал». Особенно когда запрос с JOIN по пяти таблицам выполняется при каждой загрузке карточки сделки.

Слой 5: Системные логи

dmesg | tail -50
journalctl -u nginx -u php-fpm -u mysql --since "1 hour ago" | grep -iE "(kill|oom|error|fail)"

Последний рубеж — когда проблема не в Битрикс24, а на уровне ОС. OOM-killer, переполнение inode, проблемы с диском.

Типичные узкие места

Сессии и хиты

Битрикс24 по умолчанию хранит сессии в файлах. На активном портале с 50+ пользователями за неделю может накопиться 2–5 ГБ сессионных файлов. Особенно если пользователи не выходят из системы, а просто закрывают браузер — сессия живёт, пока не истечёт её TTL.

Что делать:

Перевести сессии в Redis или memcached — это заодно ускорит их чтение
Уменьшить время жизни сессии в Настройки → Производительность → Сессии (по умолчанию 60 минут, для ненагруженных порталов можно оставить)
Настроить ротацию сессионных файлов через cron на уровне ОС

Кеш

Кеш Битрикс24 — одновременно спасение и источник проблем. Когда кеш работает правильно, портал летает. Когда кеш переполнен или не сбрасывается вовремя — начинаются чудеса: старые данные на страницах, расхождения между разными пользователями, непредсказуемое время ответа.

Три главных правила работы с кешем:

Использовать управляемый кеш, а не файловый. Redis, memcached — что угодно, лишь бы не файлы на диске. На портале с 100+ пользователей файловый кеш превращается в бутылочное горлышко из-за операций ввода-вывода.
Настроить автоподчистку. В Настройки → Производительность → Автокеширование включить очистку устаревшего кеша. По умолчанию кеш чистят раз в сутки — на активном портале этого мало.
Не злоупотреблять тегированным кешем. Каждый тег сброса генерирует запрос к базе. Если в компоненте 20 тегов, а компонент вызывается на 50 страницах — это 1000 лишних запросов при каждом сбросе кеша.

Для Имекса проблема оказалась именно в кеше: после обновления ядра старый файловый кеш конфликтовал с новым, и при загрузке любой страницы PHP тратил 5–8 секунд на попытки прочитать битые файлы кеша.

Cron и агенты

Агенты — это сердце фоновых процессов Битрикс24. Через них идёт всё: отправка писем, выполнение роботов, индексация поиска, генерация отчётов, рассылка уведомлений.

Проблема в том, что агенты выполняются последовательно. Если один агент зависает или падает — очередь встаёт. Агент отправки почты, который не может подключиться к SMTP-серверу и ждёт таймаута 30 секунд, блокирует всех остальных.

Диагностика агентов:

-- Сколько агентов в очереди
SELECT COUNT(*) FROM b_agent WHERE ACTIVE = 'Y' AND NEXT_EXEC <= NOW();

-- Какие агенты зависли (не выполнялись больше часа)
SELECT MODULE_ID, NAME, LAST_EXEC FROM b_agent
WHERE ACTIVE = 'Y' AND LAST_EXEC < DATE_SUB(NOW(), INTERVAL 1 HOUR)
ORDER BY LAST_EXEC ASC
LIMIT 20;

У Гостя Кабеля второй запрос показал, что 47 почтовых агентов не выполнялись больше 3 часов. Причина: сменился пароль на SMTP-сервере, агенты уходили в ошибку подключения и не освобождали очередь.

Решение для профилактики:

Разнести агентов по группам с разной периодичностью запуска
Настроить мониторинг количества невыполненных агентов
Перевести почтовые агенты на отдельный cron с высоким приоритетом

Поиск

Поиск в Битрикс24 — это отдельная вселенная со своими таблицами, своими индексами и своим cron-ом. Когда клиент говорит «поиск зависает», в 90% случаев проблема в одной из трёх вещей:

Переполнение поискового индекса. Таблица b_search_content может разрастись до гигабайтов на порталах с большим количеством товаров или документов. Каждый новый элемент добавляет записи в индекс, а старые не удаляются автоматически.

-- Размер поисковых таблиц
SELECT TABLE_NAME,
       ROUND(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2) AS `Size_MB`
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'bitrix_db'
  AND TABLE_NAME LIKE 'b_search%'
ORDER BY Size_MB DESC;

Морфологический поиск без настройки. Битрикс24 по умолчанию использует морфологию для русского языка. Это хорошо для качества поиска, но плохо для производительности: каждый поисковый запрос прогоняется через словарь, что добавляет 0.5–2 секунды к времени ответа. Если на портале 500+ одновременных пользователей — это критично.

Отсутствие или сбой cron переиндексации. Индекс устаревает, поиск выдаёт неверные результаты или зависает, пытаясь проиндексировать на лету то, что должен был проиндексировать cron.

В случае victoryshop проблема была комбинированной: индекс занимал 3.2 ГБ (при базе в 8 ГБ), cron переиндексации падал по памяти, а менеджеры тем временем добавляли по 200 товаров в день. Решение: ручная переиндексация с ограничением по времени выполнения, затем настройка инкрементальной индексации каждые 15 минут вместо полной раз в сутки.

База данных

База данных — самый частый виновник, которого почему-то проверяют в последнюю очередь. Три вещи, которые стоит смотреть сразу:

Медленные запросы. Включить slow_query_log в MySQL и смотреть, какие запросы выполняются дольше 2 секунд. Часто это запросы к таблицам b_uts_* (пользовательские поля), которые не проиндексированы.

Блокировки. На активных порталах с большим количеством одновременных операций (импорт, экспорт, массовые изменения) блокировки таблиц могут парализовать всю работу.

-- Текущие блокировки
SHOW ENGINE INNODB STATUS\G

Размер базы. База Битрикс24 растёт быстрее, чем кажется. Особенно таблицы событий (b_event_log), истории изменений и поискового индекса. Если база выросла в 2 раза за полгода — пора настраивать ротацию.

Почта

Почта в Битрикс24 работает через агентов — и это главная проблема. Почтовый ящик проверяется раз в N минут (по умолчанию каждые 10 минут), письма отправляются через SMTP-агенты, а входящие обрабатываются через почтовые ящики.

Типичные проблемы:

SMTP-сервер недоступен или сменил пароль — агенты отправки зависают и блокируют очередь. Случай Гостя Кабеля в чистом виде.
Почтовый ящик переполнен — IMAP-подключение висит, пока не получит полный список писем (10 000+ писем во входящих).
Вложенные письма создают нагрузку — каждое вложение сохраняется на диск, проверяется антивирусом (если настроен), индексируется. Лавина из 500 писем с вложениями может положить портал.

Инструменты диагностики

Кроме встроенных средств Битрикс24, полезно иметь под рукой внешние инструменты:

Мониторинг сервера (Netdata, Grafana + Prometheus). Показывают аномалии до того, как их заметят пользователи: скачок CPU, падение свободной памяти, рост очереди запросов.

Профайлер запросов (xhprof, tideways). Для случаев, когда проблема в конкретной странице или компоненте. Показывает, сколько времени занимает каждый вызов — от подключения к базе до рендеринга шаблона.

Анализатор логов (goaccess). Превращает access.log веб-сервера в читаемый отчёт: какие URL самые медленные, какие часы пиковые, откуда идёт подозрительный трафик.

Мониторинг крона Битрикс24. Проверять, что cron_events.php не просто запускается по расписанию, но и отрабатывает за разумное время. Если cron выполняется дольше своего интервала — это красный флаг.

Профилактика: что настроить один раз, чтобы не тушить пожары

Большинство проблем производительности можно предотвратить настройкой пяти вещей:

Мониторинг дискового пространства и настроенная ротация логов. 90% аварийных остановок портала — кончилось место. Логи, сессии, кеш, бекапы — всё это растёт, и без автоматической очистки диск заполняется за 2–4 недели.
Управляемый кеш (Redis/memcached) вместо файлового. Одна настройка в dbconn.php или .settings.php убирает целый класс проблем с дисковым вводом-выводом.
Мониторинг очереди агентов. Если количество невыполненных агентов превышает порог (скажем, 30) — слать уведомление администратору. Это позволяет поймать проблему до того, как «Битрикс24 тупит» станет жалобой клиента.
Регулярная реиндексация поиска. Не раз в сутки, а инкрементально, каждые 15–60 минут. И следить за размером поисковых таблиц.
Резервный SMTP-сервер. Для случаев, когда основной SMTP недоступен. Битрикс24 не умеет переключаться между серверами автоматически, но можно настроить внешний почтовый релей, который маршрутизирует письма.

Заключение

Три компании, три разных симптома, а причина одна и та же: нет мониторинга, нет автоматической очистки, очередь агентов никто не проверяет. Проблемы производительности Битрикс24 — это не магия и не баги ядра (в 90% случаев). Это накопившиеся последствия недель и месяцев работы без присмотра.

Если вы интегратор или администратор портала — настройте мониторинг сегодня. Пять пунктов из раздела «Профилактика» займут час, но сэкономят десятки часов на аварийных разборах. И главное — клиенты не будут звонить с фразой «у нас всё сломалось».

SEO-блок

Высокочастотные:

диагностика проблем производительности Битрикс24
Битрикс24 тупит
Битрикс24 не работает
производительность Битрикс24

Среднечастотные:

Битрикс24 зависает поиск
Битрикс24 не открывается портал
Битрикс24 не работает почта
логи Битрикс24
агенты Битрикс24
кеш Битрикс24

Низкочастотные (long-tail):

как настроить мониторинг производительности Битрикс24
почему тормозит портал Битрикс24
переполнение сессий Битрикс24
переиндексация поиска Битрикс24
медленные запросы Битрикс24 база данных
мониторинг агентов Битрикс24
ошибка отправки почты Битрикс24 SMTP