Страница портала открывается 10–15 секунд, чат подвисает, при сохранении счёта вылетает 502 Bad Gateway. У ста сотрудников такие задержки складываются в тысячи потерянных часов за месяц. Мы в IT For Prof разбираем коробочный Битрикс24 на десятках проектов и видим повторяющуюся картину: тормозит обычно из-за настройки PHP-FPM, MySQL и дисковой подсистемы, апгрейд железа в таких случаях не помогает.
Что стоит за жалобами на медленный портал
Жалобы пользователей редко складываются в готовый диагноз. На старте мы переводим разрозненные сигналы в измеримые факты: не «карточка открывается долго», а TTFB 4,2 секунды на карточке сделки; не «иногда не работает», а 147 ошибок 502 за сутки. Конкретика отсекает половину гипотез.
Базовый набор симптомов, который мы фиксируем при первом контакте:
- Медленная загрузка страниц: TTFB больше 3 секунд при норме до 1 секунды.
- Разрывы сессий: повторная авторизация в течение дня, ошибки сессий в логах.
- Ошибки 502/504: таймауты PHP-FPM, переполнение очереди воркеров.
- Высокая загрузка сервера: Load Average выше числа ядер, iowait больше 5–10%.
- Длительные операции: отчёты строятся минуты, бизнес-процессы зависают.
Неочевидные сигналы важнее очевидных. Out of Memory в /var/log/messages, таймауты телефонии, зависание отдельных процессов появляются за неделю-две до массовых жалоб. У одного заказчика месяцами наращивали CPU, считая виновником процессор, а реальной причиной оказался раздутый журнал событий b_event_log: он упирал буферный пул InnoDB в потолок. После архивации таблицы скорость вернулась без апгрейда.
Экспресс-аудит коробки за 60–90 минут
За полтора часа мы отсекаем большинство типовых причин. Аудит разбит на 8 шагов примерно по 10 минут.
Шаги 1–3. Снимаем CPU, RAM, диски и PSI (Pressure Stall Information, счётчик ядра Linux о времени ожидания ресурса). Тревога: Load Average выше числа ядер, iowait стабильно больше 5%, swap больше 500 МБ. Дальше считаем 502/504 в логах nginx, ищем сообщение max_children reached: оно означает, что у воркеров кончилась очередь. Затем по базе: SHOW FULL PROCESSLIST, утилита mysqltuner и pt-query-digest для топа медленных запросов. Slow-log включаем на 10–30 минут с порогом 1 секунда, потом выключаем: постоянно включённый сам становится источником нагрузки.
Шаги 4–6. Запускаем встроенный Монитор производительности (балл ниже 30, серьёзная проблема), включаем режим DEBUG на самых медленных страницах. Если компонент crm.timeline даёт 5 секунд и 250 SQL-запросов, проблема в коде или базе, а не в общей перегрузке. Дальше идём в админку агентов: предупреждение «агенты работают без cron» означает, что они дёргают пользовательские хиты и съедают тот же воркер PHP-FPM, на котором сидит человек.
Шаги 7–8. Опрос пользователей (когда тормозит сильнее, кого касается, после какого изменения началось) и сведение находок в таблицу: что нашли, метрика-доказательство, гипотеза, приоритет. Без приоритизации оптимизация скатывается в борьбу с симптомами.
10 причин: три уровня проблем
Инфраструктура (причины 1–3). Медленный диск виден по iowait выше 5–10%, await двузначный в миллисекундах. Нехватку памяти выдают swap больше 500 МБ и сообщения OOM Killer в dmesg. Перегрузку CPU: Load Average выше числа ядер; на VPS добавляется параметр %steal больше 5%, означающий, что соседи по гипервизору забирают ресурсы.
Сервер (причины 4–6). Веб-стек страдает, когда статика (.css, .js, .jpg) проксируется через PHP-FPM вместо прямой отдачи nginx. PHP-FPM упирается в pm.max_children: считаем по формуле: (доступная RAM минус память под MySQL, Redis и ОС) делится на средний RSS воркера. На одном проекте видели pm.max_spare_servers = 35 при RSS 209 МБ — 7,3 ГБ только на простаивающие воркеры. После перевода на pm = static с max_children = 60 потребление упало с 9,3 до 0,975 ГБ, TTFB — с 5,2 до 0,8 секунды. Типичные тяжёлые таблицы базы: b_event_log, b_bp_tracking, b_im_message, b_disk_object, b_sale_order.
Прикладной уровень (причины 7–10). Агенты без перевода на cron работают на хитах пользователей. «Мусор» копится в /bitrix/cache/, /bitrix/managed_cache/, /upload/resize_cache/. В аудите типичен бакет S3 на 76–105 тысяч файлов и больше 200 ГБ. Кастомный код ломает скорость скрытно: внешние API дольше 1–2 секунд, забытый debug = true в .settings.php, тяжёлые обработчики OnAfter без кеширования. Некорректная эксплуатация: чаты на 1000+ человек, сотни наблюдателей в задачах, бизнес-процессы для массовых рассылок.
Один заказчик удвоил RAM на сервере, где b_bp_tracking занимал 9 ГБ. Выигрыш длился две недели, потом портал снова встал. Лечение идёт по доминирующей причине, а не по самой удобной для устранения.
Ориентиры по ключевым метрикам
Цифры без контекста бесполезны: 70% CPU при ровной нагрузке, это здоровый сервер, та же цифра с двукратным трендом за месяц: сигнал, что портал встанет через две недели. Поэтому мы фиксируем тренды минимум за 30 дней.
- Latency диска: SSD до 1–2 мс (тревога: больше 10 мс), HDD 5–15 мс (тревога: больше 20 мс).
- PSI io some avg10: норма до 5%, тревога: больше 10%. Точнее iowait, потому что показывает реальное ожидание процессов.
- Load Average: норма около 0,7–0,9 от числа ядер, тревога: больше числа ядер.
- InnoDB buffer pool hit rate: норма больше 99%, тревога: меньше 95%.
- TTFB основных страниц: норма 0,2–0,5 секунды, тревога — стабильно больше 3 секунд.
- SQL-запросов на страницу: норма 50–300, тревога: больше 500.
- Доля 5xx ответов: норма меньше 0,01%, тревога: больше 0,1%.
TTFB меряем по сценариям отдельно: главная, список лидов, карточка сделки, страница задачи с десятью комментариями, окно чата. Средний показатель скрывает кратную разницу между ними.
Регламент профилактики и запас ёмкости
Профилактика дешевле авралов. Регламент строим из трёх горизонтов плюс мониторинг 24/7.
Еженедельно (30–60 минут): загрузка ресурсов, логи nginx/PHP-FPM/MySQL, работа интеграций, алерты мониторинга. Если алерт срабатывал и был «потушен» без анализа, его нужно расследовать повторно, иначе он сработает в худший момент.
Ежемесячно: аудит объёма данных, OPTIMIZE TABLE в нерабочее время, обновление Bitrix24 и пакетов ОС, тестовое восстановление из бэкапа на стенде. У одного заказчика бэкапы не проверяли 14 месяцев: половина дампов оказалась битой, восстановление заняло 36 часов вместо плановых 2–3.
Ежеквартально: полный аудит по тем же 8 шагам, расчёт ёмкости, тест аварийного переключения, опрос пользователей. Иногда метрики зелёные, а 30% сотрудников жалуются на конкретный сценарий, который не попал в мониторинг.
Минимальный набор алертов: CPU выше 90% дольше 10 минут, свободного места меньше 10%, ошибки 502 больше 5 за час, swap больше 1 ГБ, недоступность сайта 2+ минуты. Внешние проверки доступности обязательны: внутренний мониторинг падает вместе с сервером и в момент аварии молчит.
Средний коробочный портал на 100–150 сотрудников растёт в данных на 20–30% в год. Подобранный «впритык» сервер через 1,5–2 года вернёт ту же проблему уже из-за объёмов, а не конфигурации. Закладывайте запас не меньше 50% по RAM и диску. Если в команде нет Linux-администратора с опытом nginx, PHP-FPM и MySQL, экспресс-аудит и квартальный регламент разумно вынести на внешнее сопровождение: это та работа, которую мы в IT For Prof делаем с фиксированным объёмом и измеримым результатом за известную цену.