«Битрикс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. Они индивидуальны для каждого проекта и конфигурации, поэтому единого идеального рецепта не существует. Будет интересно узнать ваши лайфхаки по оптимизации проектов в «Битрикс». Делитесь мнением в комментариях.
База знаний
Скорость сайта на Битрикс зависит от оптимизации компонентов сайта (вопрос разработчиков), набора модулей, оптимизации серверного ПО и достаточного количества ресурсов сервера.
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. Оптимизируем базу данных
Переходим в Настройки — Инструменты — Диагностика — Оптимизация БД.
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
Скажите, есть какой то волшебный совет в моем случае)?
Может под определенные объемы БД нужны какие то определенные конфиги?
База данных mysql запись как увеличить в битрикс
Помогите разобраться с проблемой производительности | Bitrix | mysql | php
Приветствую всех Недавно начал развертывать ВМ, параметры (2 CPU/4 RAM/ 10 + 5G (db + os)). Накатил на нее Bitrix По рекомендациям с офф сайта установил все рекомендованные параметры mysql/php В ходе проверок bitrix_test.php все ОК, в ходе проверок отдельно db и php — все ОК. В ходе проверки настроек производительности выходит приблизительно: Конфигурация 11.38 30
Среднее время отклика 0.0879 0.0330 секунд
Процессор (CPU) 2.0 9.0 миллионов операций в секунду
Файловая система 4776.8 10000 файловых операций в секунду
Почтовая система 0.0204 0.0100 время отправки одного письма (в секундах)
Время старта сессии 0.0002 0.0002 секунд
Конфигурация PHP оптимально оптимально
База данных MySQL (запись) 2503 5600 количество запросов на запись в секунду
База данных MySQL (чтение) 6250 7800 количество запросов на чтение в секунду
База данных MySQL (изменение) 2347 5800 количество запросов на изменение в секунду
Ось — Centos 7 параметры mysql 5.6 (основные):
Cache parameters
query_cache_size = 64M table_open_cache = 1200 thread_cache_size = 4 key_buffer_size = 256M thread_stack = 128K join_buffer_size = 18M sort_buffer_size = 18M query_cache_limit = 8M query_cache_type = 1 read_buffer_size = 16M
InnoDB parameters
innodb_file_per_table innodb_buffer_pool_size=32M innodb_lock_wait_timeout=50 innodb_buffer_pool_size = 512M innodb_flush_log_at_trx_commit = 2 innodb_log_file_size = 64M innodb_log_buffer_size = 8M innodb_flush_method = O_DIRECT innodb_strict_mode = OFF
realpath_cache_size 4096k opcache.max_accelerated_files 100000 opcache.enable 1 opcache.validate_timestamps 1 opcache.memory_consumption 128 opcache.memory_usage.used_memory 72.88 МБ opcache.memory_usage.free_memory 55.01 МБ Регулярные выражения PHP: Да Регулярные выражения Perl: Да Zlib extension: Да GD lib extension: Да Free Type extension: Да Модули шифрования: mcrypt Модуль Hash: Да XML: Да JSON: Да Поддержка mbstring: Да Включен режим UTF для mbstring: Да
Сервер прям свежий, только установил, накатил свежий bitrix и обновил только недавно систему. Пробовал менять тип дисков, добавлять ОЗУ/CPU — производительность не менялась. Может в настройках какая то проблема?
«Битрикс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 env и как их изменять
Я периодически работаю с сайтами на битрикс, которые работают в готовом web окружении от разработчиков. Сегодня я поделюсь информацией о том, где хранятся и как изменять настройки mysql на сервере с bitrix env. Многие простые вещи становятся очень сложными, если ты не знаком с нюансами работы этого окружения.
Проверяем, кто занимает всю память на сервере
Я столкнулся с неожиданным поведением сервера, на котором работал сайт на битриксе. Длительное время он работал, занимая всю доступную оперативную память. Я получал об этом уведомления от заббикса, но не обращал большого внимания на сервер, так как в целом это нормальная ситуация, когда у тебя mysql и apache трудятся вместе. Где-то пол года он работал нормально, а потом стал сильно деградировать по производительности. В общем, начались настоящие проблемы.
Я пошел на сервер и стал разбираться, в чем дело. Начал с того, что посмотрел, кто занимает оперативную память.
Не удивился, увидев, что mysql. Первое, что сделал — перезапустил его и стал наблюдать. Увидел такую картинку в zabbix.
Дальше сервер кушал весь своп и прибивал процесс mysql с сообщением в системном логе:
Mysql перезапускался автоматом и дальше все продолжалось по кругу. Надо было разбираться в первую очередь с ним.
Где в bitrix env настройки mysql
Для начала нужно было проверить, где на сервере с bitrixenv хранятся настройки mysql. По аналогии с остальными настройками (php, apache, nginx), предвкушал долгие поиски и не ошибся. В итоге выяснил, что хранятся они в файле /etc/mysql/conf.d/bvat.cnf. Но мало узнать, где они хранятся. Как оказалось, этот файл формируется динамически при каждом запуске сервера, в зависимости от доступной оперативной памяти. Тут то я и понял, в чем проблема. Расскажу обо всем по порядку.
В bitrix env есть служба под названием bvat. Она стартует при загрузке сервера через /etc/init.d/bvat. Эта служба определяет количество оперативной памяти на сервере и в зависимости от этого меняет некоторые настройки web окружения. В частности mysql, php, apache. Можно посмотреть этот скрипт, чтобы понять, что он делает. Если кратко, то он запускает скрипт /etc/ansible/library/bx_perf, который подключает некоторые переменные и формирует новые конфиги. Свою работу логирует в файле /opt/webdir/logs/bvat.log.
В моем случае bvat не изменял конфиг для mysql. Я проверил документацию по нему на сайте битрикса. Четко сказано, что он работает при загрузке системы. Я запускал руками те проверки из скрипта, что должны менять именно mysql конфиг. Удалял конфиг, но bvat неизменно создавал новый конфиг, из расчета, что на сервере 16Гб памяти. Это так и было на момент первоначальной установки. Но со временем гипервизор нагрузили и память сделали динамическую, уменьшив максимально доступную.
В какой-то момент всем памяти на гипервизоре стало не хватать и он начал распределять ее по виртуальным машинам. Конкретно подопытному серверу стало доставаться меньше памяти, чем 16 Гб, но все конфиги были заточены под это количество. Из-за этого серверу не хватало памяти и он начинал уходить в своп и аварийно перезапускать службы, пожирающие память.
Когда я все понял, сделал виртуальной машине статическую память (меньше 16Гб) и перезагрузился. Но конфиг mysql не изменился. Тут явно какой-то глюк. bvat по прежнему откуда-то доставал 16Гб памяти и на основе их рисовал конфиг. Я просмотрел весь скрипт. Там используется несколько проверок памяти. Я посмотрел основную, через free -m, она показывает корректное значение, которое меньше 16Гб, но bvat откуда-то берет другое число. Я не стал разбираться с этим, так как налицо баг, который скорее всего либо уже исправлен, либо будет исправлен после какого-нибудь обновления.
Как изменить настройки mysql в bitrixenv
Для того, чтобы руками изменить какие-то параметры в mysql, которые не будут изменяться динамически, необходимо воспользоваться файлом /etc/mysql/conf.d/z_bx_custom.cnf. Основной параметр, который приводит к тому, что mysql занимает всю оперативную память — innodb_buffer_pool_size. В первую очередь следует переназначить именно его. Сделать где-то в треть реальной оперативной памяти. С остальными параметрами надо разбираться отдельно. Я не стал тратить на это время, пока временно отдал серверу первоначальный объем памяти в 16Гб. В ближайшее время обновлю полностью сервер вместе с bitrix env и посмотрю, исчез ли глюк с тем, что память определяется неправильно. Если нет, буду руками выставлять параметры под реальную оперативную память сервера.
Заключение
К bitrixenv у меня неоднозначное отношение. С одной стороны удобно, что все собрано в одном месте, связано друг с другом и быстро устанавливается, настраивается. Но когда нужно дебажить какие-то проблемы, уходит в разы больше времени, чем если бы ты использовал классический веб сервер, настроенный собственноручно. Сейчас я уже неплохо ориентируюсь в bitrixenv, решаю вопросы быстро, но с mysql столкнулся впервые. Обычно там проблемы с конфигами php, apache, nginx, с отправкой почты.
Закономерный вывод в конце — bitrixenv не предназначен для работы на сервере с динамической оперативной памятью. Надо либо отключать bvat, либо ставить статическую память виртуальной машине.
Онлайн курс по Kubernetes
Онлайн-курс по Kubernetes – для разработчиков, администраторов, технических лидеров, которые хотят изучить современную платформу для микросервисов Kubernetes. Самый полный русскоязычный курс по очень востребованным и хорошо оплачиваемым навыкам. Курс не для новичков – нужно пройти вступительный тест.
MySQL, InnoDB, Монитор производительности
Приветствую.
Хочу поделится радостью : удалось оптимизировать работу MySQL.
В БУС монитор производительности на мощном сервере показывал следуюшее:
Чего я только с настройками мускуля не крутил, ничего сильно ощутимого результата не давало.
Но нашлась все-таки одна настроечка, которая ну очень сильно меня обрадовала: innodb_flush_log_at_trx_commit=2
После того как я ее прописал, получил следующие циферки:
Увелечение скорости записи в 60 раз меня ну очень обрадовало.
- Огромное спасибо Петру Невенчанному за помощь в ковыряниях настроек.
- Монитору производительности (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 — общий индекс производительности вырос в два раза, но при этом почему-то параметры базы данных (именно запись) упали в два раза:
Параметр 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
Скажите, есть какой то волшебный совет в моем случае)?
Может под определенные объемы БД нужны какие то определенные конфиги?