• Как проявлялась проблема производительности
• Аудит
• Результаты аудита
  • Аппаратные ресурсы
  • Настройка платформы
  • Оптимальность кода и бизнес-логики
  • Режим использования портала
• Быстрые решения
  • Аппаратные ресурсы
  • Настройка платформы
  • Оптимальность кода и бизнес-логики
  • Режим использования портала
  • Первые результаты
• Плановые задачи
  • Аппаратные ресурсы
  • Настройка платформы
  • Код и бизнес-логика
  • Режим использования портала

Производительность корпоративного портала редко «падает» за один день. Сначала страницы открываются чуть дольше обычного, затем пользователи начинают закрывать лишние вкладки и избегать тяжёлых разделов. Кажется, что ничего критичного не происходит: оборудование в норме, число пользователей почти не изменилось, новых интеграций не было. Но каждый следующий запрос обрабатывается дольше, занимает всё больше ресурсов и создаёт дополнительную нагрузку. В какой-то момент работать с системой в привычном режиме становится невозможно.

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

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

К нам обратился российский университет из топа вузов-лидеров по количеству студентов. За пару месяцев до обращения корпоративный портал на Битрикс24 внезапно стал деградировать по производительности без явных на то причин. Диагностика внутренней IT-командой не дала однозначных результатов. Система была нагружена на 95% от предельных значений, что подтверждали графики производительности и жалобы пользователей. Ситуация постепенно усугублялась, всё сильнее требуя неотложных мер.

Аудит

Проверку мы обычно проводим комплексно на четырех уровнях системы. Вот что стали проверять в первую очередь:

1. Аппаратные ресурсы

2. Настройка платформы (ОС, веб-сервер, БД и т.д.)

3. Оптимальность кода и бизнес-логики Битрикс24

4. Режим использования информационной системы (ИС)

Результаты аудита

Аппаратные ресурсы

• Веб-сервер и сервер БД работают на раздельном оборудовании, что соответствует рекомендуемой архитектуре.

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

• Нагрузка на CPU и память росла одновременно с увеличением времени обработки запросов. Это указывало на постепенное увеличение количества и продолжительности выполняющихся операций.

• Оперативной памяти не хватало, поэтому активно использовался файл подкачки. В пиковые периоды свободными в нём оставалось около 500 МБ.

• Производительность дисковой подсистемы SAS является потенциальным узким местом: текущая нагрузка высока, а существенного запаса по I/O нет. 

• По трафику роста нет.

• Количество подключений на NGINX также не изменилось.

• Количество коннектов к БД подходит к пределу, количество потоков возрастает пропорционально общему росту нагрузки.

• Количество процессов на сервере БД тоже растет пропорционально и, что важно, в состоянии «State None».

• При синтетическом тестировании веб-сервера на соответствие требованиям Битрикс24 даже в период минимальной нагрузки на стороне сервера БД наблюдаются просадки по ОЗУ — система прибегает к использованию файла подкачки. Тест на нагрузке ЦП сервера БД явно не отразился. При этом результат проверки показал значение в ~10 раз меньше эталонных Битрикса. 
• Проведенные расчеты показывают, что ресурсов «железа» недостаточно для нормальной работы базы данных и веб-сервера.

Настройка платформы

• Архитектура системы в целом корректна, но уже не соответствует текущей нагрузке.

• Конфиг nginx в норме.

• В конфигурации Apache задано избыточное количество воркеров.

• Лимит подключений MySQL достаточен, однако из-за продолжительного выполнения запросов соединения длительное время остаются занятыми, что приводит к периодическим ошибкам.

Оптимальность кода и бизнес-логики

• В базе данных Битрикс24 таблица, связанная с правами доступа, содержит около 200 млн записей. Это многовато для таблицы, которая участвует в проверках прав доступа. По нашим подсчетам, соотношение записей прав к лидам примерно равно 5,36. В Битрикс24 условным ориентиром является 4 записи прав на сущность. Т.е. само по себе количество прав на одного лида не является аномалией, тем более, что по другим сущностям это соотношение меньше 4.
• Запросы к БД огромны, их выполнение загружает CPU, RAM и дисковую подсистему, блокирует новые соединения, создавая очереди из запросов.

• Выявили наиболее крупные таблицы БД. Рекомендовали провести ревизию полей CRM-сущностей, в первую очередь тех, которые при отображении списков генерируют дополнительные запросы к БД. Например, для каждого указанного ниже свойства при отображении в списке генерируется дополнительный запрос. Для лидов — 24 дополнительных запроса, для сделки — более 70. Необходимо рассмотреть их сокращение в первую очередь.

• После проработки этих полей необходимо также провести профилактическую ревизию около 300 кастомных полей у сделок и 120 у лидов. Дополнительных запросов они не генерируют, однако могут увеличивать объём обрабатываемых данных и влиять на производительность отдельных сценариев работы с CRM.

Режим использования портала

• Существенного роста количества пользователей и интенсивности эксплуатации системы, которые могли бы привести к увеличению нагрузки, не выявлено.
• Изменений в интеграциях, частоте обменов и т.д. — тоже.
• Выявлено изменение режима пользования системой:
  • сотрудники стали откладывать работу на вечер или выходные, когда работа более комфортна;
  • сотрудники минимизируют количество обращений путем избегания страниц со списками сущностей, предпочитая сохранять закладки для прямого обращения к сущностям и другие ухищрения;
  • отчеты используют только в крайних случаях.

Тестирование не выявило единственной причины, которая могла бы объяснить резкое ухудшение производительности: отказа оборудования, критических ошибок конфигурации или резкого роста интенсивности использования портала. Напротив, система постепенно приближалась к пределу своих возможностей. Отмеченный на графиках «перелом» хоть и выглядит внезапным, на самом деле стал результатом накопления ограничений, которые со временем начали усиливать друг друга. Замедление обработки запросов приводило к росту числа одновременно выполняющихся операций, увеличению нагрузки на серверы и дальнейшему снижению производительности.

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

Читайте также

Почему Битрикс24 тормозит и как ускорить его работу

Быстрые решения

Аппаратные ресурсы

• Остановить и вывести все вторичные, тестовые сервисы за пределы контура, чтобы они не конкурировали за ресурсы.

• Снизить использование SWAP за счёт высвобождения и перераспределения ресурсов в пользу сервера БД. После устранения дефицита оперативной памяти оценить целесообразность отключения SWAP на сервере БД. Активный SWAP ухудшает производительность БД, но его отключение не должно приводить к уходу в дисковый обмен.

• Заменить SAS диски на SSD (т.к. NVME недоступна на устаревшем оборудовании) на сервере БД.

• Настроить файловую систему для снижения избыточного количества и длительности операций чтения/записи на диск.

• Оптимизировать фрагментированные таблицы.

Настройка платформы

• Оптимизировать количество веб-воркеров с учётом фактической производительности БД и допустимого уровня параллельной нагрузки.

Оптимальность кода и бизнес-логики

• Временно ограничить использование наиболее ресурсоёмких функций и сценариев работы с CRM, например, вывод дополнительных полей, использование тяжёлых отчётов и других сценариев, создающих повышенную нагрузку на БД.

• Проанализировать структуру и объём данных о правах доступа и устранить избыточные записи, если они будут выявлены. 200 млн кажутся огромной цифрой, но относительные значения (5,3 записи прав на лид при ориентире 4) — это небольшое превышение.

• Если MySQL не будет обновляться до восьмой версии, то включить кеширование запросов (query_cache_size) на уровне БД. Query Cache не универсальное временное решение, т.к. у него были проблемы с масштабируемостью и валидацией при изменении данных.

• Перенести периодические агенты на cron.

Режим использования портала

• Провести разъяснительную работу с пользователями:временно исключить открытие множества вкладок, сократить лишние переходы, уменьшить количество выводимых полей в таблицах.

Первые результаты

• Среднее время открытия страницы в пиковые периоды упало с 10 до 4 сек.

• Работа пользователей стабилизировалась: основные операции снова выполнялись без существенных задержек, хотя скорость работы портала всё ещё оставалась ниже желаемой.

• У команды сопровождения высвободилось время для плановых работ по устранению проблемы.

Читайте также

Вечно живой, вечно доступный: как создать отказоустойчивый кластер для Битрикс24

Плановые задачи

Аппаратные ресурсы

• Переезд на современную аппаратную платформу с возможностью масштабирования по требованию.

• Использование высокочастотных процессоров и NVME дисков для сервера БД.

Настройка платформы

• Перевод сервера БД и веб-сервера на новую версию ОС с возможностью использования PHP 8.2.

• Обновление MySQL до последней стабильной версии 8.x.

• Обновление «коробки» Битрикс 24 до актуального релиза.

• Создание кластерной архитектуры серверов БД и горизонтальное масштабирование веб-сервера для повышения отказоустойчивости.

• Расчёт математической сервисно-ресурсной модели оптимального количества воркеров и размера памяти относительно текущих значений.

Код и бизнес-логика

• Анализ и оптимизация запросов к БД, их проработка на оптимальность, начиная с самых ёмких и часто используемых.

• Увеличение бин-логов, декомпозиция и, как осознанный компромисс, денормализация таблиц.

• Переработка системы прав на сущности CRM.

Режим использования портала

• Настройка представления и пользовательских интерфейсов, минимизирующих использование «необязательных» функций и данных для всех категорий пользователей.

• Выставление по умолчанию коротких значений периодов отчётов.

• Определение владельца продукта для отказа от противоречивых доработок.

Итоги

Проект был коротким, в большей степени консалтинговым, с ограниченным доступом только к непродуктивным системам. Совместно с командой заказчика мы выработали план действий по стабилизации высоконагруженной системы для её подготовки к дальнейшему росту нагрузки. Несмотря на то, что проект не получил продолжения, он стал для нас очередной интересной вехой в работе с нагруженными кластерными системами.

Высокая нагрузка не должна становиться проблемой для Битрикс24. Если портал всё же начал работать медленнее, производительность снизилась и это начинает мешать вашей работе — обратитесь в ИНТЕРВОЛГУ. Проведём аудит, найдём узкие места, поможем стабилизировать систему, вернуть её в привычное состояние и подготовить к дальнейшему масштабированию.