База данных 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 — производительность не менялась. Может в настройках какая то проблема?

Буду очень признателен за любую подсказку, спасибо!

Низкая скорость записи база данных MySQL

Здравствуйте поставил на тестовую машину 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С-Битрикс: Управление сайтом. Политика конфиденциальности

Настройка базы данных MySQL

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

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

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

Рекомендуется переводить все таблицы проекта в формат данных InnoDB. Формат InnoDB, начиная с версии MySQL 4.0, входит в стандартную поставку продукта и обеспечивает надежное хранение данных, транзакционность и блокирование данных на уровне строки.

Два важных момента, которые дают основание предпочесть таблицы InnoDB перед MyISAM:

1. Надежность. В MyISAM высока вероятность сбоя таблиц, особенно больших, особенно при высокой посещаемости, особенно часто изменяемых. Есть риск потерять несколько (десятков, сотен) записей и целостность данных. В InnoDB чинить отдельные таблицы не придется. Если упадет, так все сразу. Но на практике это — исключительное явление, практически не встречаемое. Благодаря транзакционности, риск нарушения целостности минимальный. Недостатки InnoDB: нужно внимательно следить за свободным местом на диске; накапливающаяся фрагментация данных (лечится периодическим переводом таблиц из InnoDB в MyISAM и обратно).
2. Скорость. На невысокой посещаемости MyISAM ведет себя быстрее, как на модификацию, так и на чтение. Однако, при росте посещаемости достаточно быстро сказывается отсутствие транзакций и блокировка на уровне таблиц. При некоторой величине посещаемости проект просто реально умирает. В InnoDB запись будет медленнее (транзакции же), зато при высокой посещаемости блокировки наступят намного, намного позже, чем для MyISAM.

Поменять тип таблиц на InnoDB можно следующим образом:

В административном меню Настройки системы > Инструменты > SQL запрос выполнить команду:

SHOW TABLES

ALTER TABLE , type=InnoDB

define("MYSQL_TABLE_TYPE", "InnoDB");

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

Внимание! Обязательно конфигурируйте InnoDB. Для лучшей производительности базы данных при работе с InnoDB рекомендуется настроить my.cnf для MySQL в разделе параметров для InnoDB innodb_* .

Наибольшее внимание следует обратить на следующие параметры и примеры:

set-variable = innodb_buffer_pool_size=250M set-variable = innodb_additional_mem_pool_size=50M set-variable = innodb_file_io_threads=8 set-variable = innodb_lock_wait_timeout=50 set-variable = innodb_log_buffer_size=8M set-variable = innodb_flush_log_at_trx_commit=0

Рекомендуется: Для сокращения времени ответа сервера можно использовать отложенные транзакции и, в частности, устанавливать переменную set-variable = innodb_flush_log_at_trx_commit=0 .

Если MyISAM уже не используется активно, можно высвободить память в пользу InnoDB параметров.

Желательно, чтобы кэш данных вмещал в себя основной объем данных, используемых продуктом в работе. Обычно для работы базы данных выделяется порядка 60-80% свободной памяти в системе.

Рекомендуется: Производить многопотоковую (multithreading) сборку MySQL для улучшения производительности системы и возможностей по параллельной обработке запросов.

Пример рекомендуемых настроек для сервера с 2 Гб оперативной памяти, работающего с операционной системой FreeBSD/Linux:

set-variable = table_cache=4096

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

set-variable = key_buffer_size=16M set-variable = sort_buffer=8M set-variable = read_buffer_size=16M

Эти параметры используются только для MyISAM. Если в базе нет таблиц MyISAM, то лучше установить минимальные значения.

set-variable = query_cache_size=64M set-variable = query_cache_type=1

Кэширование результатов запросов. Обычно бывает достаточно 32 Мб (смотреть на статус Qcache_lowmem_prunes). Максимальный размер результата по умолчанию — 1 Мб, его можно регулировать.

set-variable = innodb_buffer_pool_size=780M

Основной буфер — чем больше, тем лучше.

set-variable = innodb_additional_mem_pool_size=20M

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

set-variable = innodb_log_file_size=100M set-variable = innodb_log_buffer_size=16M

Чем больше размер лог-файла, тем реже надо будет записывать в основной файл данных. Суммарный размер лог-файла может быть сопоставим с величиной innodb_buffer_pool_size (по умолчанию ведется два лога).

set-variable = innodb_flush_log_at_trx_commit=0

Отложенная фиксация транзакций, раз в секунду

set-variable = tmp_table_size=32m

Размер временных таблиц рекомендуется увеличивать до 32 Мб.

Рекомендуется так же увеличивать join_buffer_size до 2 Мб, это существенно влияет на скорость выполнения ряда запросов.

set-variable = join_buffer_size = 2M

Совет администратору Переход на InnoDB может привести к значительному замедлению некоторых масштабных операций записи и обновления данных. Это связано с тем, что все операции по изменению данных начинают выполняться с использованием транзакций. Кроме того, в отличие от MyISAM для кэширования таблиц InnoDB не используется кэш операционной системы, а все кэшированные данные хранятся в кэше БД, определяемом параметром innodb_buffer_pool_size . Вы должны сами определить оптимальность перехода вашего проекта на формат данных InnoDB.

Внимание! Если по каким-то причинам вы решили продолжить работу с типом данных MyISAM, обязательно проведите конфигурирование MySQL для увеличения объемов кэшируемой информации, областей сортировки и минимизации числа дисковых операций. Использование для базы данных 60-80% оперативной памяти может ускорить работу стандартного проекта в несколько раз.

Временная папка

При наличии достаточного количества ОЗУ рекомендуется выносить временную папку MySQL на ramdisk в памяти.

• Убедитесь, что в ядре реализована поддержка tmpfs.
• Создайте новую точку монтирования и дайте все права на использование:

# mkdir /mnt/tmpfs/ # chmod 777 /mnt/tmpfs/

# mount -t tmpfs -o size=1024M tmpfs /mnt/tmpfs/ или $ sudo mount -t tmpfs -o size=1024M tmpfs /mnt/tmpfs/

где 1024M есть размер RAMdisk в Мегабайтах.

Внимание! К размеру папки нужно подходить осторожно: если вы попросите создать ramdisk больше, чем имеете оперативной памяти, система начнёт сгружать всё в swap-файл и реальный результат подключения временной папки может быть отрицательным.

Список ссылок по теме: