База данных mysql запись как увеличить в битрикс

Оптимизация Brainy под Битрикс

Как правило, если на VPS или выделенном сервере размещаются только сайты под управлением CMS Битрикс, то используется специализированное решение от самой Битрикс — «1С-Битрикс: Веб-окружение» — Linux (BitrixEnv). В этом случае каких-либо дополнительных действий по оптимизации не требуется.

Но, если необходимо разместить на той же машине сайты на других CMS, то данное окружение мало применимо. Выходом послужит использование одной из панелей управления, например бесплатной BrainyCP. Арендовать VPS в России или выделенный сервер в России можно на нашем сайте.

1. Проверка типа таблиц

Проверим какой тип таблицы используется в базе данных. Сделаем это, подключившись к MySQL через утилиту phpmyadmin, далее выбрав нужную базу и нажав «Структура».

Если таблицы имеют тип InnoDB, то дальнейших действий не требуется.

Если же все или часть таблиц имеют тип MyISAM, то переведем их в InnoDB, поскольку в большинстве случаев они работают быстрее нежели MyISAM. Да и оптимизации MySQL под один тип таблиц проще.

Сначала обязательно сделаем дамп базы данных, на случай если что-то пойдет не так. Сделать это можно через тот же phpmyadmin, в разделе «Экспорт».

Для перевода таблиц в существующей базе можно воспользоваться следующим запросом через phpmyadmin
SET @DATABASE_NAME = ‘name_of_your_db’;
SELECT CONCAT(‘ALTER TABLE `’, table_name, ‘` ENGINE=InnoDB;’) AS sql_statements
FROM information_schema.tables AS tb
WHERE table_schema = @DATABASE_NAME
AND `ENGINE` = ‘MyISAM’
AND `TABLE_TYPE` = ‘BASE TABLE’
ORDER BY table_name DESC;
name_of_your_db заменяем на имя базы данных. Результатом выполнения данного запроса будет текст другого запроса, который нужно будет скопировать и выполнить для перевода таблиц из MyISAM в InnoDB.

В зависимости от количества таблиц в базе и их имен может потребоваться включить опцию «Полные тексты» и увеличить количество выводимых строк в phpmyadmin

2. Оптимизация настроек MySQL для InnoDB

Оптимизируем настройки MySQL под InnoDB, исходя из оперативной памяти VPS

Задать данные настройки можно, как через панель «База данных» — «Управление MySQL/MariaDB» — «Управления через пакетный менеджер» — кнопка «Настроить», так и через консоль, редактируя файл.

Важно! Перед редактированием данного файла, создадим резервную копию файла.

Проще всего сделать это консольной командой cp /etc/my.cnf /etc/my.cnf _back

А так же копию базы данных через дамп или целиком скопировав папку /var/lib/mysql

innodb_buffer_pool_size — Это очень важный параметр для настройки InnoDB. Обычно предполагается выделение 70-80% памяти для серверов, на которых ничего не запущено, кроме InnoDB. Если же на сервере будут запущены и другие процессы (php, Apache и т.д.), то размер лучше ограничить в 40-50% от объема оперативной памяти.

innodb_additional_mem_pool_size — Данная опция практически никак не влияет на производительность MySQL, однако рекомендуется оставлять для InnoDB около 20 МБ (или чуть больше) под различные внутренние нужды.

innodb_log_file_size — Эта опция влияет на скорость записи. Она устанавливает размер лога операций (так операции сначала записываются в лог, а потом применяются к данным на диске). Чем больше этот лог, тем быстрее будут работать записи (т.к. их поместится больше в файл лога). Но следует помнить, что увеличение этого параметра увеличит и время восстановления системы при сбоях. Обычно выставляют значение около 64-512 МБ в зависимости от размера сервера.

innodb_log_buffer_size — Стандартное значение данной опции вполне подойдёт для большинства систем со средним количеством операций записи и небольшими транзакциями. Если же в Вашей системе бывают всплески активности, или Вы активно работаете с BLOB-данными, то рекомендуется немного увеличить значение innodb_log_buffer_size. Однако не переусердствуйте — слишком большое значение будет пустой тратой памяти: буфер сбрасывается каждую секунду, поэтому Вам не понадобится больше места, чем требуется в течение этой секунды. Рекомендуемое значение — около 8-16 МБ, а для небольших баз — и того меньше.

innodb_file_per_table. Если включить эту опцию, Innodb будет сохранять данные всех таблиц в отдельных файлах (вместо одного файла по умолчанию). Прироста в производительности не будет, однако есть ряд преимуществ:

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

Следует выставить значение innodb_file_per_table = ON

innodb_flush_logs_at_trx_commit — Значение по умолчанию 1 означает, что после каждой завершенной транзакции (или после изменения состояния транзакции) лог должен быть сброшен на диск. Это достаточно ресурсоемкая операция.

Многие приложения, особенно те, в которых раньше использовался MyISAM будут хорошо работать при значении 2, который означает, что не надо сбрасывать буфер на диск, а следует отправить его в кэш операционной системы. Лог по-прежнему будет сбрасываться на диск каждую секунду и максимум, что вы можете потерять — это 1-2 секунды записей. Значение 0 обеспечивает более высокую скорость, но и более низкую надежность.

Следует выставить значение innodb_flush_logs_at_trx_commit = 0 или innodb_flush_logs_at_trx_commit = 2

innodb_flush_method Рекомендуется — innodb_flush_method = O_DIRECT, либо innodb_flush_method = O_DSYNC чтобы избежать двойного кеширования (выключает операционный кеш для файлов данных MySQL) .

O_DSYNC будет работать быстрее, чем O_DIRECT, но не так надежно.

transaction-isolation. Уровень изоляции транзакций. Рекомендуется значение READ COMMITTED. Это уровень изолированности, который устанавливается по умолча­нию — в большинстве СУБД (но не в MySQL!). Он соответствует приведенному ранее простому определению изолированности: транзакция увидит только те изменения, которые к моменту ее начала подтверждены другими транзакциями, а произведенные ею изменения останутся невидимыми для других транзакций, пока текущая не будет подтверждена. Задается строкой:

transaction-isolation = READ-COMMITTED

innodb_doublewrite. Doublewrite представляет собой буфер двойной записи и используется в InnoDB чтобы изменённые страницы были записаны в файл данных. Позволяет избежать потери данных при внезапном сбое сервера. В этом режиме InnoDB перед записью страниц в основной файл данных предварительно записывает их в непрерывную область — doublewrite. В целом не рекомендуется отключать на продакшене при работе с ценными данными, т.к. в результате сбоя сервера повреждается файл с данными без возможности сделать repair.

В остальных случаях можно ускорить работу выставив innodb_doublewrite = 0

innodb_io_capacity. Параметр контролирует, как много операций запросов на запись за секунду будет совершать сервер при выполнении операций сброса на диск. На стандартных значениях SSD-диски зачастую не могут реализовать полностью свой потенциал, для них рекомендуемое значение следующее: innodb_io_capacity = 2000

sync_binlog. Параметр sync_binlog определяет логику синхронизации данных из бинлога с диском. Если значение равно 1, запись на диск будет происходить после каждой транзакции. Это делает хранилище очень надежным, но крайне сильно нагружает дисковую подсистему. Значение 0 отключит синхронизацию из Mysql, и база данных будет полагаться на ОС в вопросе записи лога на диск. Такое значение может сильно увеличить производительность. Задаём значение sync_binlog = 0

Также для всех типов таблиц рекомендуется настроить следующие параметры:

skip-name-resolve — не определять доменные имена для IP-адресов подключающихся клиентов. При этом пользовательские разрешения нужно настраивать не на хосты, а на IP-адреса (за исключением localhost). Если вы соединяетесь с сервером только с локальной машины, то особого значения не имеет. Для внешних соединений ускорит установку соединения.

skip-external-locking — опция установлена по умолчанию, начиная с версии 4. Указывает MySQL-серверу не использовать внешние блокировки при работе с базой. Внешние блокировки необходимы в ситуациях, когда несколько серверов работают с одними и теми же файлами данных, т.е. имеют одинаковую datadir, что на практике не используется.

sql_mode. Контроль режимов работы sql. Рекомендуется режимов не задавать, задав строку в виде

sql_mode = »

table_open_cache. Оптимальное значение рассчитывается как количество таблиц во всех базах, умноженное на 2, ориентировочно рекомендуем устанавливать опцию в 2048.

thread_cache_size определяет максимальное количество тредов в кеше. Когда новый клиент устанавливает соединение с Mysql, Mysql открывает создает новый тред (thread) для этого клиента. В средах с больших количеством клиентов и соединений, создание и удаление тредов становится дорогой операцией. Для того, чтобы оптимизировать этот процесс, существует настройка thread_cache_size. Вместо постоянного создания и удаления, Mysql может сохранять неактивные треды в кеш (и использовать в случае необходимости).

Если есть возможность, рекомендуется установить это значение не меньше, чем значение переменной max_used_connections. Если значение max_used_connections больше 128, рекомендуется ограничиться этим значением.

Проверить значение max_used_connections можно подключившись к MySQL и введя команду:
show status LIKE «max_used_connections%

Чтобы изменения вступили в силу необходимо перезагрузить mysql командой:
service mysqld restart

3. Изменение настроек PHP

Переходим в хост-аккаунт, на котором будем размещать сайт

В разделе «WWW» — «Конфигурация php.ini» задаем для соответствующей версии PHP значение параметров:
opcache.revalidate_freq=0
max_input_vars = 10000

4. Изменение настроек opcache

Через консоль (по ssh) или через файловый менеджер под пользователем root правим файл по пути /home/имя хост-аккаунта/etc/версиязрз/php.d/10-opcache.ini (В данном примере это для пользователя admin и версии php7.4 это /home/admin/etc/php74w/php.d/10-opcache.ini), в котором задаем значение:
opcache.max_accelerated_files = 10000

и перезапускаем веб-сервер командой:
service httpd restart

Все способы

© 2009–2023 «HANDYHOST.RU» 8-800-505-68-01

• Услуги
• Хостинг сайтов
• Домены
• Конструктор сайтов
• Linux VPS / Windows VPS
• Выделенные серверы
• SSL сертификаты

• Клиентам
• Контакты
• О компании
• Акции
• Оборудование
• Партнерская программа

• Поддержка
• Способы оплаты
• Регламент
• Документы
• Справка

Помогите разобраться с проблемой производительности | 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.

Дано

Корпоративный портал в «Битрикс24», рассчитанный на несколько сотен пользователей, c ~300 Гб файлов и ~80 Гб БД на выделенном сервере с BitrixVM.

До изменения настроек показатели были следующими:

Стандартный тест производительности в панели администратора «Битрикс»

Из всех параметров стоит обратить особое внимание на работу с MySQL и «Конфигурацию PHP». Именно эти показатели особенно важны для нас, так как они косвенно отражают уровень производительности проекта.

Запрос клиента

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

Решение

Настройки MySQL — первое, с чем мы начинаем работать.

Заменим стандартные значения BitrixVM на:

explicit_defaults_for_timestamp = 1 expire_logs_days = 10 max_binlog_size = 100M max_allowed_packet = 128M transaction-isolation = READ-COMMITTED performance_schema = OFF sql_mode = "" # Cache parameters query_cache_type = 1 query_cache_size=16M query_cache_limit=4M key_buffer_size=256M join_buffer_size=2M sort_buffer_size=4M # Parameters for temporary tables tmpdir = /tmp tmp_table_size=128M max_heap_table_size=128M thread_cache_size = 4 table_open_cache = 2048 # InnoDB parameters innodb_file_per_table innodb_buffer_pool_size = 8192M innodb_buffer_pool_instances = 1 innodb_flush_log_at_trx_commit = 0 innodb_flush_method = O_DIRECT innodb_strict_mode = OFF # Database charset parameters character-set-server=utf8 collation-server=utf8_general_ci init-connect="SET NAMES utf8" [mysqldump] quick quote-names default-character-set = utf8

Следующий шаг — изменим режим питания CPU, так как «Битрикс» любит большую частоту процессора.

В зависимости от количества ядер меняем в каждом
файле /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor powersave на performance.

Далее проверим результат:

Мы видим, что больше всего изменилась работа с MySQL: параметры “запись” и “изменение” выросли почти в 3 раза; показатель “чтение” вырос в 5 раз. Это значит, что при обращении сайта к базе данных этот тип операции будет выполняться в несколько раз быстрее. Как следствие, вырастет и общая производительность сайта.

Из-за изменения режима питания CPU (это возможно, так как используется выделенный сервер) увеличилось количество операций на CPU.

Теперь необходимо отредактировать настройки для OPcache.

В файле /etc/php.d/10-opcache.ini заменяем его исходное значение на:

zend_extension=opcache.so opcache.enable = 1 opcache.enable_cli = 1 opcache.memory_consumption = 256 opcache.max_file_size = 2M opcache.interned_strings_buffer = 64 opcache.max_accelerated_files = 130987 opcache.fast_shutdown = 1 opcache.revalidate_freq = 1 opcache.fast_shutdown=1 opcache.save_comments=1 opcache.load_comments=1 opcache.use_cwd = 1

Примечание: Тест «Битрикс» сообщит вам, что параметр opcache.revalidate_freq должен иметь значение 0 а не 1, но с указанным нами он будет работать лучше.

Сам параметр opcache.revalidate_freq отвечает за проверку кеша: при значении 0 она выполняется каждый раз при запуске скрипта, а при значении 1 — раз в секунду.

После изменения настроек проверяем результат:

Из таблицы следует, что показатель работы с MySQL еще немного вырос. В то же время операции на CPU и общая производительность «Битрикс» увеличились значительно за счет изменения настроек PHP и кеширования скриптов.

Вывод

Благодаря таким несложным изменениям в настройках, мы смогли увеличить производительность проекта в 3 раза, а взаимодействие с БД — от 3 до 5 раз (на основании общей оценки теста «Битрикс»). Работой проекта на новом сервере наш клиент полностью доволен. We did it!

В данном способе оптимизации мы сделали акцент на основных моментах, с которыми взаимодействует «Битрикс», а также на сам тест. Клиенты часто обращают внимание именно на него.

Среди других способов повышения производительности «Битрикс» можно назвать установку и настройку кеширующего сервиса (например, Redis). Показатель производительности в CMS может упасть, но общая работа сайта должна быть лучше. Кроме того, можно использовать php-fpm, но в нашем случае переделывать ОС, изначально настроенную под «Битрикс», было бы нерационально.

Также можно еще поиграться с настройками MySQL. Они индивидуальны для каждого проекта и конфигурации, поэтому единого идеального рецепта не существует. Будет интересно узнать ваши лайфхаки по оптимизации проектов в «Битрикс». Делитесь мнением в комментариях.

• Блог компании Timeweb Cloud
• IT-инфраструктура
• 1С-Битрикс

Форум

Здравствуйте поставил на тестовую машину bitrix, i5-3570 256SSD 8Gb, смущает в тесте производительности низкая скорость записи св базу MYSQL , конфиг следующий 8.0.23-0 mysql, ubuntu0.20.04.1, php7.4,с парметрами в my.cf игрался, параметр innodb_flush_log_at_trx_commit = 2 менял, если ставлю 2 то скорость около 370 если 1 то около 200. Куда копать ? В Мониторе производительности пишет.
Эта версия MySQL не поддерживается данной диагностикой. Результаты могут быть неверными. но как я понимаю это относится к монитору диагностики. 8 версия sql c битриксом нормально рабоатет вроде.

Заглянувший
Сообщений: 1 Регистрация: 30.12.2016
17.06.2021 06:19:55

ЯИшница, нашли решение? Столкнулись с этой же проблемой. Скорость записи в БД упала до 170 запросов в секунду

Сообщений: 5439 Баллов: 643 Регистрация: 16.07.2012
19.06.2021 13:01:59

Цитата
ЯИшница написал: конфиг следующий 8.0.23-0 mysql

Встроенный тест производительности не работает с mysql 8
Постоянный посетитель
Сообщений: 213 Баллов: 36 Регистрация: 08.10.2010
31.07.2021 13:32:41
Кто-нибудь решил проблему? Именно после обновления MySQL до версии 8 упала скорость записи.
Заглянувший
Сообщений: 3 Регистрация: 20.05.2020
04.10.2021 19:46:11
аналогично, сильно упала скорость записи в БД. 491.
Заглянувший
Сообщений: 12 Баллов: 1 Регистрация: 19.07.2013
30.10.2021 02:26:58
Такая же ситуация, уже не знаю что прописать чтобы скорость записи была выше.
Заглянувший
Сообщений: 1 Регистрация: 23.09.2021
03.02.2022 21:08:54

Была такая же проблема, после обновления mysql с 5.7 до 8.0
Получилось поправить путем тюнинга конфига /etc/my.cnf и /etc/my.cnf.bx_mysql80. Изменял следующие значения:

innodb_buffer_pool_size = 250M
innodb_log_file_size = 600M
sync_binlog= 0

Увеличение скорости записи в БД получилось с 217 до 4600

Сообщений: 261 Баллов: 46 Регистрация: 04.05.2010
04.04.2022 11:44:16

innodb_buffer_pool_size = 250M
innodb_log_file_size = 600M
sync_binlog= 0

Спасибо, нам помогло.
Коллеги из Битрикс, почему включаете в ВМ плохосовместимые элементы?
И смаое главное, почему не предупреждаете при апгрейде?

Мы учимся на них:
https://www.plus-aliance.ru
Заглянувший
Сообщений: 12 Баллов: 1 Регистрация: 19.02.2015
07.09.2022 23:37:06

Мне помог такой наборчик для mysql 8:

[mysqld]
innodb_buffer_pool_size = 2048M
innodb_redo_log_capacity = 2048M
sync_binlog = 0
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT

Скорость записи была 500-700, стала 4200.

Заглянувший
Сообщений: 1 Регистрация: 10.11.2022
26.12.2022 16:57:15

[mysqld]
innodb_buffer_pool_size = 2048M
innodb_redo_log_capacity = 2048M
sync_binlog = 0
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT

Доброго дня. Попробовал ваши настройки. Не меняется скорость. Не можете сбросить целиком конфиг? Буду благодарен.

Страницы: 1

Центр поддержки

Продукты

Управление сайтом

Битрикс24

Интернет-магазин + CRM

Решения

Для интернет-магазинов

Каталог готовых решений

Внедрение

Выбрать партнера

Проверить партнера

Стать партнером

1С-Битрикс http://www.1c-bitrix.ru Общие вопросы info@1c-bitrix.ru Приобретение и лицензирование продуктов : sales@1c-bitrix.ru Маркетинг/мероприятия/PR marketing@1c-bitrix.ru Партнерская программа partners@1c-bitrix.ru Мы работаем с 10:00 до 19:00 по московскому времени. Офис в Москве 127287 Россия Московская область Москва 2-я Хуторская улица дом 38А строение 9 Офис в Калининграде +7 (4012) 51-05-64 Офис в Калининграде 236001 Россия Калининградская область Калининград Московский проспект 261 Офис в Киеве ukraine@1c-bitrix.ru Телефон в Киеве +3 (8044)221-55-33 Офис в Киеве 01033 Украина Калининградская область Киев улица Шота Руставели 39/41 офис 1507

© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом. Политика конфиденциальности