Содержание:
Как правило, если на 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
