«Битрикс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 на проекте Bitrix
На имеющихся проектах с виртуальной машиной Bitrix можно добиться большей производительности и попугаев при проверке системы, если подправить несколько параметров в конфиге MySQL.
Таблицы должны быть в InnoDB, а значения такие:
Первый параметр желательно ставить в 70-80% от ОЗУ. Второй отвечает за размер файлов файлов, куда сначала записываются данные, а уже оттуда в БД. Соответственно, чем больше объем файлов, тем больше будет данных.
Данные параметры были применены на дефолтный конфиг MySQL, конечно же есть ещё варианты по оптимизации, но на данном этапе лично мне хватило и таких.
Проверено на рекомендуемой ОС для Битрикса – CentOS 7.4.
На RedHat значения не сильно выросли.
UPD Выявил некоторые нюансы при настройке вышеописанных параметров на MySQL 5.7:
Файл для временных запросов, находящийся по пути /var/lib/mysql/ibtmp1, начал стремительно расти до огромных размеров. Решение – ограничить его размер параметром:
MySQL, InnoDB, Монитор производительности
Приветствую.
Хочу поделится радостью : удалось оптимизировать работу MySQL.
В БУС монитор производительности на мощном сервере показывал следуюшее:
Чего я только с настройками мускуля не крутил, ничего сильно ощутимого результата не давало.
Но нашлась все-таки одна настроечка, которая ну очень сильно меня обрадовала: innodb_flush_log_at_trx_commit=2
После того как я ее прописал, получил следующие циферки:
Увелечение скорости записи в 60 раз меня ну очень обрадовало.
| innodb_flush_log_at_trx_commit — Вам кажется, что InnoDB в сто раз медленнее MyISAM? Вероятно, вы забыли изменить значение этого параметра. Значение по умолчанию 1 означает, что после каждой завершенной транзакции (или после изменения состояния транзакции) лог должен быть сброшен на диск. Это достаточно дорогая операция, особенно если у вас нет Battery backed up cache. Многие приложения, особенно те, в которых раньше использовался MyISAM будут хорошо работать при значении 2, который означает, что не надо сбрасывать буфер на диск, а следует отправить его в кэш операционной системы. Лог по-прежнему будет сбрасываться на диск каждую секунду и максимум, что вы можете потерять — это 1-2 секунды записей. Значение 0 обеспечивает более высокую скорость, но и более низкую надежность. Есть вероятность потерять транзакции даже при падении mysql-сервера. При значении равном 2 единственная возможность потерять данные — это фатальный сбой операционной системы. |
- Огромное спасибо Петру Невенчанному за помощь в ковыряниях настроек.
- Монитору производительности (P.S.: Сергей Рыжиков, да он помогает диагностировать проблемы (это я к Вашему выступлению на highload).
- Теме на форуме http://dev.1c-bitrix.ru/community/for. opic21767/
какая версия мускула ?
а если MyISAM я думаю можно получить что то типа
База данных MySQL (запись) 14 395 5 600 количество запросов на запись в секунду
База данных MySQL (чтение) 16 220 7 800 количество запросов на чтение в секунду
База данных MySQL (изменение) 14 643 5 800 количество запросов на изменение в секунду
| какая версия мускула ? |
| а если MyISAM я думаю можно получить что то типа |
По нашему опыту MyISAM работает не быстрее (примерно также по показателям монитора) InnoDB на одном и том же железе.
Рекомендую также обратить внимание на параметры:
tmp_table_size
join_buffer_size
У нас на одном VPS при установке
tmp_table_size = 64M
join_buffer_size = 2M
Скорость выполнения запросов возрастает (порой существенно)
Ура получилось — с трепетом следил за попытками поднять эти параметры, так как цифры меня просто напрягали, теперь на душе стало легче.
Первые цифры было — вторые стало
База данных MySQL (запись) 98 — 4 550
База данных MySQL (чтение) 8 166 — 7 319
База данных MySQL (изменение) 103 — 4 503
Немного просело чтение — но не шибко — за то остальное реально поднялось, посмотрим как скажется на производительности.
| База данных MySQL (запись) 11 209 (было 2 413) База данных MySQL (чтение) 30 349 (было 23 754) База данных MySQL (изменение) 13 382 (было 12 442) |
Опишу alt=»:)» width=»» height=»» />
Проц Core2Duo E8400 (3.0Ghz), память — 6Gb (ddr3), жесткий 2x500Gb (сата2, рейд)
Если честно, то на подобной конфе хотелось цифры по-вкуснее alt=»:)» width=»» height=»» />
Я так понимаю, еще есть куда стремиться.
P.S. Софт — Ubuntu 8.04LTS x64, php 5.2.4, mysql 5.0.51a, apache2.2.8
У меня на Битрикс сложилась следующая ситуация: после довольно резкого увеличения посещаемости на сайте, база начала выбрасывать ошибку, а сайт, соответственно, переставал функционировать.
Решил подтюнить базу. Для начала, прописал все рекомендуемые параметры конфига из Панели производительности. Прироста не дало.
Переконвертил все таблицы из MyISAM в InnoDB — общий индекс производительности вырос в два раза, но при этом почему-то параметры базы данных (именно запись) упали в два раза:
| База данных MySQL (запись) | 551 | 5 600 | количество запросов на запись в секунду |
| База данных MySQL (чтение) | 1 822 | 7 800 | количество запросов на чтение в секунду |
| База данных MySQL (изменение) | 1 614 | 5 800 | количество запросов на изменение в секунду |
Параметр innodb_flush_log_at_trx_commit=2 , разумеется, присутствует.
Не могли бы Вы показать весь свой конфиг my.cnf, чтобы можно было оптимально подобрать параметры и увеличить тем самым скорость чтения/записи. Заранее спасибо за любую помощь.
P.S. Конфигурация сервера БД:
10 Гб ОЗУ, Xeon E5420 2.50GHz
ОС — Debian 6.0
Косьяненко Антон, пожалуйста
Вай-вай! Спасибище!
Скорость записи и обновления увеличилась с 60 до 6200!
Ковыряю тут хостинг на Hetzner
| Сброс логов buffer_pool’а — innodb-flush-log-at-trx-commit можно выставить в значении 2. В этом случае логи будут сбрасываться достаточно часто, но не на каждый коммит. |
Рома, я же только за
Это есть и в мониторе БД.
Я об этом писал давно, и после того как нашел — битрикс стал рекомендовать.
Последнюю неделю расширили каталог магазина на 300 000 товаров. Так же очень глубокая иерархия разделов товаров (книг), к слову одних только разделов 11000. Заметил, что при хождении по каталогу, запросы ответы из компонента catalog.section.list очень долгие до 20 секунд.
16 ядер проца
16 гб оперативы
ssd винты
Используется стандартное битрикс окружение со стандартными параметрами.
Так вот, при небольшой посещаемости сайт начинает виснуть очень сильно, главная страница прогружается до минуты-двух. Процессор в это время загружен на 400% mysqld.
Начал использовать mysqltuner. Повышал параметры как требовал отладчик, вылеты стали по реже. Я не силен в настройках mysql, и не могу оценить правильность моих настроек. Вылеты продолжаются. Не могу понять, почему проц. загружается сильно, когда сайт никто не посещает, проверял в nload статистику по трафику (думал вдруг ddos).
На данный момент конфиг mysql:
[mysqld]
query_cache_size = 128M
query_cache_limit = 8M
innodb_buffer_pool_size = 7512M
max_connections = 140
table_open_cache = 14240
thread_cache_size = 32
max_heap_table_size = 256M
tmp_table_size = 256M
key_buffer_size = 128M
join_buffer_size = 256M
sort_buffer_size = 12M
bulk_insert_buffer_size = 2M
myisam_sort_buffer_size = 8M
Скажите, есть какой то волшебный совет в моем случае)?
Может под определенные объемы БД нужны какие то определенные конфиги?
База знаний
Скорость сайта на Битрикс зависит от оптимизации компонентов сайта (вопрос разработчиков), набора модулей, оптимизации серверного ПО и достаточного количества ресурсов сервера.
1. Снижение нагрузки на диск:
В большинстве случаев, чтобы повысить производительность, нужен анализ текущей нагрузки на сервере. Для этого достаточно воспользоваться утилитами top, htop, iostat.В свою очередь на скорость загрузки сайта, помимо параметров сервера где расположен сайт, влияет нагрузка на сайт со стороны роботов различных сервисов и спам-ботов. Поэтому, очень полезно запретить нежелательным “посетителям” заходить на ваш сайт.
Для проверки текущих обращений к сайту в лог-файле доступа сервера Apache можно воспользоваться командой:
#tail -f /var/log/httpd/site_name_access_log
Для проверки количества всех обращений служит команда:
#cat /var/log/httpd/site_name_access_log | grep SemrushBot | wc -l
Запрещать доступ ботам будем при помощи nginx, для этого в конфигурационный файл каждого виртуального хоста в директриву server добавляем следующее условие:
#if ($http_user_agent
* SemrushBot|MJ12bot|AhrefsBot|bingbot|DotBot|LinkpadBot|SputnikBot|statdom.ru|MegaIndex.ru|WebDataStats|Jooblebot|
Baiduspider|BackupLand|NetcraftSurveyAgent|openstat.ru) <return 444;>
2. Настройка базы данных MySQL
Оптимизация работы с базой данных для MySQL-версии продукта является одной из важнейших стратегий в оптимизации системы в целом, так как продукт активно работает с базой данных.Основным недостатком MyISAM с точки зрения производительности является блокировка на уровне таблицы при выполнении тех или иных операций. В результате, при большой нагрузке MySQL именно MyISAM таблицы становятся основным узким местом в системе, мешая увеличивать утилизацию машины и число обрабатываемых запросов. Это также приводит к увеличению времени работы страницы за счет ожидания используемых таблиц на уровне MySQL. Рекомендуется переводить все таблицы в формат данных InnoDB.
Создаем дамп базы данных и создаем ее копию:
#mysqldump -u root —opt -R database > database.sql && cp database.sql database_backup.sql
Переводим все таблицы в формат данных InnoDB:
#find database.sql -type f -exec sed -i ‘s#MyISAM#InnoDB#g’ ‘<>‘ \;
Заливаем дамп базы данных:
#mysql -u root database < database.sql
Сервер баз данных Mysql читает конфигурацию из следующих файлов /etc/mysql/conf.d/bvat.cnf, /etc/my.cnf. При этом настройки в файле /etc/mysql/conf.d/bvat.cnf конфигурируются CMS автоматически при загрузке сервера в зависимости от количества ресурсов сервера. Поэтому настройки можно изменять в файлах /etc/mysql/conf.d/z_bx_custom.cnf и /etc/my.cnf. В большинстве случаев автоматические настройки не требуют корректировки, но если сервер начинает уходить в своп, то следует уменьшить размер буферов.
Копируем текущие настройки Mysql в файл /etc/mysql/conf.d/z_bx_custom.cnf:
#cat /etc/mysql/conf.d/bvat.cnf > /etc/mysql/conf.d/z_bx_custom.cnf
Открываем файл /etc/mysql/conf.d/z_bx_custom.cnf:
[mysqld]
query_cache_type = 1
query_cache_size = 128M
query_cache_limit = 16M
innodb_buffer_pool_size = 5120M
max_connections = 85
table_open_cache = 14336
thread_cache_size = 128
max_heap_table_size = 256M
tmp_table_size = 256M
key_buffer_size = 96M
join_buffer_size = 18M
sort_buffer_size = 18M
bulk_insert_buffer_size = 2M
myisam_sort_buffer_size = 18M
Так как MyISAM таблицы не используются устанавливаем минимальные значения для query_cache:
query_cache_type = 1
query_cache_size = 64M
query_cache_limit = 2M
Важнейшей настройкой MySQL при работе с InnoDB является innodb_buffer_pool_size, устанавливается по принципу «чем больше, тем лучше». Рекомендуется выделять до 50 — 60 % от имеющейся памяти на сервере:
innodb_buffer_pool_size = 5120M
Установка большого размера innodb_log_file_size может привести к увеличению быстродействия, при этом увеличится время восстановления данных, выберите от 258M до 1G.
Внимание! При изменении параметра innodb_log_file_size остановите MySQL, сделайте резервную копию файлов ib_logfile<x> (файлы чаще всего в /var/lib/mysql/), измените значение параметра innodb_log_file_size и запустите MySQL. В результате MySQL создаст новый лог-файл указанного в конфигурации размера.
Также необходимо снизить размеры буферов:
key_buffer_size = 32M
join_buffer_size = 1M
sort_buffer_size = 16M
Изменяем значение innodb_flush_log_at_trx_commit = 0Переносим временные файлы Mysql в оперативную память — в файле /etc/my.cnf указываем tmpdir = /dev/shmЗначение innodb_open_files и table_open_cache рассчитывается как количество таблиц во всех базах, умноженное на 2, ориентировочно рекомендуем устанавливать обе опции в 4096 или 8192.
table_open_cache = 4096
innodb_open_files = 4096
Количество потоков ввода/вывода файлов в InnoDB задается опциями innodb_read_io_threads, innodb_write_io_threads, обычно этому параметру присваивается значение 4 или 8, на быстрых SSD-дисках установите в 16. Значение innodb_thread_concurrency установите в количество ядер * 2.
innodb_read_io_threads = 4
innodb_write_io_threads = 4
innodb_thread_concurrency = 32
После внесения всех изменений перезапускаем mysqld:
systemctl restart mysqld или service mysqld restart
Часто возникющая проблема — не меняется параметр table_open_cache из-за неверных системных лимитов в самой ОС.Изменяем значение LimitNOFILE:
vi /usr/lib/systemd/system/mysqld.service LimitNOFILE = 50000
Применяем значение:
# systemctl daemon-reload # systemctl restart mysqld Изменяем лимит открытых файлов в системе: vi /etc/security/limits.conf root soft nofile 100000 root soft nofile 100000 # ulimit -n 100000
После внесения всех изменений перезапускаем mysqld:
systemctl restart mysqld или service mysqld restart
3. Оптимизация изображений
Для оптимизации изображений на сервере используем jpegoptim и optipng.Перейдем в директорию с сайтом и выполнить следующие команды:
find . -type f -iname ‘*.jpg’ -exec jpegoptim —strip-all <> \;
find . -type f -iname «*.png» -exec optipng -strip all -o4 <> \;
4. Оптимизация в административной части CMS Битрикс
4.1. Тестируем производительность
Перейдите в панель производительности: Настройки → Производительность → Панель производительности. Нажмите кнопку Тестирование производительности» и подождите несколько минут.
4.2. Переход на версию PHP 7+
Прирост производительности от перехода на версию PHP c 5+ до 7+ составляет порядка 40 %. Уточните перед переходом у разработчиков может ли работать сайт на новой версию PHP.
4.3. Настройка кеширование
- Если товары на сайте обновляются вручную или несколько раз в неделю.
Рекомендуемое время кеширования: не менее 172800 секунд (2 суток).
- Если товарны на сайте обновляются один раз в день, выгрузка из 1С или другой системы складского учета происходит ночью.
Рекомендуемое время кеширования: 86400 секунд (1 сутки)
- Нечасто, но бывает: цены обновляются через реал-тайм обмен с 1С и бывает, что несколько раз в течение дня.
Рекомендуемое время кеширования: 7200 секунд (2 часа).
4.4. Создание индексов в базах данных
Переходим в Настройки → Производительность → Индексы → Анализ индексов.
Нажмите на кнопку «Выполнить анализ собранных SQL запросов». Если появившиеся индикаторы зеленые, все в порядке: индексы созданы. Если индикаторы желтые, создайте их самостоятельно.
Инструкция Битрикс https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=32&LESSON_ID=3798
4.5. Отключаем неиспользуемые модули
-
AD/LDAP интеграция (ldap)
-
Push and Pull (pull)
-
Wiki (wiki)
-
А/B-тестирование (abtest)
-
Веб-аналитика (statistic)
-
Веб-кластер (cluster)
-
Веб-мессенджер (im)
-
Веб-сервисы (webservice)
-
Дизайнер бизнес-процессов (bizprocdesigner)
-
Документооборот (workflow)
-
Календарь событий (calendar)
-
Конструктор отчетов (report)
-
Менеджер идей (idea)
-
Мобильная платформа (mobileapp) — если не подключено мобильное приложение
-
Мобильное приложение для интернет-магазина (eshopapp) — если не подключено мобильное приложение
-
Обучение (learning)
-
Перевод (translate)
-
Почта (mail)
-
Техподдержка (support)
-
Универсальные списки (lists)
-
Управление масштабированием (scale).
Включается здесь : Настройки → Облако 1С-Битрикс → Ускорение сайта (CDN). Необходимо тестировать опытным путем, так как может отрицательно влиять на скорость загрузки сайта.
4.7. Объединение и сжатие CSS и JS-файлов
В настройках главного модуля «Оптимизация CSS» устанавливаем необходимые галочки.
4.8. Оптимизируем базу данных
Переходим в Настройки — Инструменты — Диагностика — Оптимизация БД.
