«Битрикс24». Играемся с настройками и оптимизируем проект
В этой статье мы расскажем, как оптимизировать крупный проект в «Битрикс24» и увеличить его производительность в 3 раза, изменяя настройки MySQL и режим питания CPU.
300 Гб файлов и
80 Гб БД на выделенном сервере с BitrixVM.
До изменения настроек показатели были следующими:
Стандартный тест производительности в панели администратора «Битрикс»
Из всех параметров стоит обратить особое внимание на работу с MySQL и «Конфигурацию PHP». Именно эти показатели особенно важны для нас, так как они косвенно отражают уровень производительности проекта.
Запрос клиента
Наш клиент хотел не только перенести проект на новый выделенный сервер, но и улучшить параметры производительности. Например, среди сложностей можно назвать отсутствие возможности делать дампы базы данных на исходном сервере, а также медленную работа самого портала.
Решение
Настройки MySQL — первое, с чем мы начинаем работать.
Заменим стандартные значения BitrixVM на:
Следующий шаг — изменим режим питания CPU, так как «Битрикс» любит большую частоту процессора.
В зависимости от количества ядер меняем в каждом
файле /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor powersave на performance.
Далее проверим результат:
Мы видим, что больше всего изменилась работа с MySQL: параметры “запись” и “изменение” выросли почти в 3 раза; показатель “чтение” вырос в 5 раз. Это значит, что при обращении сайта к базе данных этот тип операции будет выполняться в несколько раз быстрее. Как следствие, вырастет и общая производительность сайта.
Из-за изменения режима питания CPU (это возможно, так как используется выделенный сервер) увеличилось количество операций на CPU.
Теперь необходимо отредактировать настройки для OPcache.
В файле /etc/php.d/10-opcache.ini заменяем его исходное значение на:
Примечание: Тест «Битрикс» сообщит вам, что параметр opcache.revalidate_freq должен иметь значение 0 а не 1, но с указанным нами он будет работать лучше.
Сам параметр opcache.revalidate_freq отвечает за проверку кеша: при значении 0 она выполняется каждый раз при запуске скрипта, а при значении 1 — раз в секунду.
После изменения настроек проверяем результат:
Из таблицы следует, что показатель работы с MySQL еще немного вырос. В то же время операции на CPU и общая производительность «Битрикс» увеличились значительно за счет изменения настроек PHP и кеширования скриптов.
Вывод
Благодаря таким несложным изменениям в настройках, мы смогли увеличить производительность проекта в 3 раза, а взаимодействие с БД — от 3 до 5 раз (на основании общей оценки теста «Битрикс»). Работой проекта на новом сервере наш клиент полностью доволен. We did it!
В данном способе оптимизации мы сделали акцент на основных моментах, с которыми взаимодействует «Битрикс», а также на сам тест. Клиенты часто обращают внимание именно на него.
Среди других способов повышения производительности «Битрикс» можно назвать установку и настройку кеширующего сервиса (например, Redis). Показатель производительности в CMS может упасть, но общая работа сайта должна быть лучше. Кроме того, можно использовать php-fpm, но в нашем случае переделывать ОС, изначально настроенную под «Битрикс», было бы нерационально.
Также можно еще поиграться с настройками MySQL. Они индивидуальны для каждого проекта и конфигурации, поэтому единого идеального рецепта не существует. Будет интересно узнать ваши лайфхаки по оптимизации проектов в «Битрикс». Делитесь мнением в комментариях.
Форум пользователей MySQL
Прощу помочь мне оптимально настроить mariadb для высоконагруженного сайта, в котором большинство таблиц InnoDB, остальные Myisam. Проблема в том, что сервер сейчас с этой настройкой сильно грузит CPU, при пиковом посещении может вообще положить mariadb. На сервере висит несколько сайтов, пару из которых на битриксе
У меня выделенный сервер: 4хIntel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz, 32Gb Memory
Также есть второй точно такой же (пока не используется)
Тесты битрикса говорят что запись у меня страдает (первое значение мой тест, второй рекомендуемый):
База данных MySQL (запись) — 1 945 — 5 600 — количество запросов на запись в секунду
База данных MySQL (чтение) — 22 621 — 7 800 — количество запросов на чтение в секунду
База данных MySQL (изменение) — 6 924 — 5 800 — количество запросов на изменение в секунду
Скорость чтения/записи БД
Приветствую.
Хочу поделится радостью: удалось оптимизировать работу MySQL.
В БУС монитор производительности на мощном сервере показывал следуюшее:
Чего я только с настройками мускуля не крутил, ничего сильно ощутимого результата не давало.
Но нашлась все-таки одна настроечка, которая ну очень сильно меня обрадовала: innodb_flush_log_at_trx_commit=2
После того как я ее прописал, получил следующие циферки:
Увелечение скорости записи в 60 раз меня ну очень обрадовало.
Исправляем ошибку MySQL «Row size too large» в 1с-Битрикс
Если Вы используете в своих проектах инфоблоки 2.0 и таблицы InnoDB, то есть шанс в один прекрасный момент столкнуться с ошибкой MySQL «SQL Error (1118): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. You have to change some columns to TEXT or BLOBs» (или «Got error 139 from storage engine»). Ниже рассмотрены причины и условия ее возникновения, а также различные методы устранения, с вмешательством в настройки сервера или без него.
Причины
Данная ошибка возникает в таблицах InnoDB при попытке чтения строки с большим количеством заполненных текстовых полей. Сумма длин всех текстовых полей (но не более 768 байтов каждого поля) не должна превышать половины страницы памяти, которая указана в настройках MySQL. В моем случае это было 16кб, отсюда и цифра 8126 байт в названии ошибки.
Условия возникновения в 1с-Битрикс
К ошибке приводит совокупность факторов:
— использование инфоблоков 2.0, т.е. хранение свойств в отдельных таблицах;
— MySQL в качестве сервера базы данных;
— тип InnoDB для таблицы свойств инфоблока;
— большое количество свойств строкового типа. Точная цифра зависит от настроек сервера.
Методы решения
Условно решения можно разделить на 2 группы — с необходимостью правки конфигурации сервера и без нее. Все советы даны применительно к битриксу. Естественно перед экспериментами нужно сделать резервную копию.
Без правки конфигурации:
1. Перевести таблицу в MyISAM. В моем случае это вызвало 2 проблемы — битрикс неправильно конвертировал заполненные значения свойств и при первом добавлении элемента инфоблока пропали половина свойств других элементов. Почему именно так получилось не ясно, но факт остается фактом — риск поломать таблицу есть.
2. Вернуться на инфоблоки 1.0. В этом случае каждое свойство будет храниться в отдельной строке общей таблицы, строка «влезет» в отведенную ей память и ошибка пропадет. Метод не всегда применим, потому что есть некоторые различия в форматах объектов, возвращаемых функцией CIBlockElement::GetList(), и в некоторых случаях придется переписывать код.
С вмешательством в настройки сервера:
1. Увеличить размер страницы памяти. Для этого в файле univ.i установить значения
и пересобрать MySQL.
Минусы подхода хорошо описаны в этой статье.
2. Для MySQL версии > 5.5 изменить формат таблиц на DYNAMIC
Для MySQL версии > 5.0 нужно сначала подключить InnoDB через плагин, поддерживающий формат файлов barracuda.
Хостинг TimeWeb точно подвержен этой ошибке. Будьте внимательны и заранее продумывайте архитектуру проекта.
3 комментария “ Исправляем ошибку MySQL «Row size too large» в 1с-Битрикс ”
У меня была такая проблема на одном из сайтов, но тип таблиц был MyISAM, перевод в InnoDB ничего не изменил, так что тип таблицы здесь ни при чем.
Дело действительно в режиме хранения свойств, помог перевод инфоблока обратно в инфоблоки 1.0
Спасибо за наводку!
Маленький хак.
Если нужно добавить в инфоблок всего пару-тройку свойств, то можно просто для некоторых свойств сменить тип данных у столбцов DESCRIPTION_ с VARCHAR(255) на TEXT в таблице b_iblock_element_prop_s.
Если описания значений не используются совсем, то таким образом можно увеличить максимальное количество свойств где-то до 500 — то есть упираемся уже в другое ограничение таблиц InnoDB — максимально 1000 столбцов (http://dev.mysql.com/doc/refman/5.0/en/column-count-limit.html).
Блин, парсер съел текст…
DESCRIPTION_[PROPERTY_ID] и b_iblock_element_prop_s[IBLOCK_ID]