Оптимизация 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–2024 «HANDYHOST.RU» 8-800-505-68-01
- Услуги
- Хостинг сайтов
- Домены
- Конструктор сайтов
- Linux VPS / Windows VPS
- Выделенные серверы
- SSL сертификаты
- Клиентам
- Контакты
- О компании
- Акции
- Оборудование
- Партнерская программа
- Поддержка
- Способы оплаты
- Регламент
- Документы
- Справка
Как ускорить сайт на 1С-Битрикс: 14 шагов, чтобы увеличить производительность и скорость
За последние три года мы оптимизировали производительность многих проектов на 1С-Битрикс. Среди них были как новые сайты, которые размещались на хостинге впервые, так и проекты, перенесённые с других хостингов и корпоративных серверов.
В этой статье вы узнаете основные шаги, которые мы рекомендуем, чтобы увеличить производительность сайта и сделать его более быстрым для посетителей и поисковых систем.
На какой результат можно рассчитывать?
Если пройти эти шаги последовательно, то можно увеличить производительность даже очень медленных сайтов, которые показывают 20-30 пунктов по шкале Битрикс, до 100 пунктов и выше.
С помощью правильных настроек вполне реально сделать так, чтобы “тормозной” сайт стал “летать” и радовать посетителей удобством и высокой скоростью.
Итак, вот 14 шагов для оптимизации сайта на 1С-Битрикс:
- Подобрать более мощное железо на хостинге.
- Использовать специализированное окружение Битрикс.
- Минимизировать скрипты и стили.
- Отследить и исправить медленные запросы.
- Сжать изображения.
- Отложить загрузку медиа-контента.
- Настроить время жизни кэша.
- Включить CDN.
- Обновить версию PHP до 7.1 и выше.
- Отключить лишние модули.
- Оптимизировать настройки БД.
- Создать фасетные индексы.
- Включить тип таблиц InnodDB в базе данных.
- Настроить innodb buffer pool size.
Рассмотрим каждый из этих шагов подробнее.
Подобрать более мощное железо на хостинге
Производительность сайта зависит от серверных мощностей – количества ядер и частоты процессора, объёма оперативной памяти, типа и ёмкости дисков.
Если вы настраиваете хостинг для нового проекта, важно выбрать конфигурацию сервера, соответствующую “прожорливости” сайта и предполагаемому уровню нагрузки. А уже затем делать тонкую настройку на основе мониторинга производительности.
Мы знаем, что Битрикс очень чувствителен к частоте процессора, скорости дисков и объёму памяти. Поэтому в шаблонах хостинга Максиплэйс предусмотрено несколько готовых конфигураций. На них большинство сайтов, которые переезжают к нам с обычных хостингов, сразу начинают показывать более высокую производительность.
Для сайтов компаний и интернет-магазинов с небольшой посещаемостью будет достаточно 1-2 ядер процессора, 2 Гб оперативной памяти и до 30 Гб на SSD-диске. Эта конфигурация подойдет и для тех, кто только запустил сайт и ещё не замерил нагрузку от посещаемости.
Если же ваш сайт достаточно “тяжёлый”, понадобится больше ресурсов. Так, для сайтов с высокой посещаемостью, а также интернет-магазинов с большим каталогом товаров или порталов, например, Битрикс24, мы рекомендуем использовать тариф “MIDDLE” с 4 ядрами процессора, 4 Гб RAM и 80 Гб на SSD-диске.
По стоимости переход с минимальной конфигурации на среднюю сопоставим со стоимостью одного (!) небольшого заказа в интернет-магазине (около 2 тыс. рублей). А результатом может быть как рост заказов за счёт ускорения работы сайта, так и повышение позиций сайта в поисковой выдаче.
После усиления или оптимизации “железа” переходим к настройке окружения и самого сайта.
Если вы настраиваете хостинг для нового проекта, важно выбрать конфигурацию сервера, соответствующую “прожорливости” сайта и предполагаемому уровню нагрузки. А уже затем делать тонкую настройку на основе мониторинга производительности.
Использовать специализированное серверное окружение Битрикс
Мы рекомендуем использовать на хостинге специализированное окружение – виртуальную машину BitrixVM, рекомендованную разработчиками платформы 1С-Битрикс.
Что даёт использование специализированного окружения?
«1C-Битрикс: Виртуальная машина» – это виртуальный сервер, полностью настроенный, протестированный и предназначенный для оптимальной работы с сайтами на «1С-Битрикс».
В нём уже учтены многие параметры, влияющие на производительность. Набор ПО и связка веб-сервисов уже настроена, чтобы обеспечить оптимальную работу сайта на 1С-Битрикс или портала Битрикс24.
Если же вы не используете окружение Битрикс, а самостоятельно конфигурируете среду на своём VPS-сервере, обратите внимание на режим использования php как модуль apache. Эту опцию вы увидите в настройках и можете использовать её для ускорения работы Битрикс. При этом есть много нюансов, так как при высокой нагрузке предпочтительным окажется другой режим, и придётся привлекать специалиста.
Поэтому для удобства и скорости развёртывания мы рекомендуем использовать готовое и многократно протестированное окружение BitrixVM. Мы используем его для всех клиентских проектов на платформе Битрикс.
Обновить версию PHP до 7.Х
Если вы устанавливали виртуальную машину больше года назад, скорее всего, у вас стоит одна из старых версий PHP.
Нужно проверить версию PHP и обновить её до 7.x, т.к. новые версии работают быстрее.
Когда основа серверной части настроена, пора переходить к настройкам, которые делаются из админ-панели 1С-Битрикс.
Минимизировать скрипты и стили
Большинство файлов стилей и скриптов не используются на начальном этапе загрузки страницы, поэтому их стоит перенести в самый конец. При этом минификация и объединение сократят их вес и снизят количество запросов.
В настройках главного модуля необходимо выставить галочки, как показано на скриншоте ниже.
Очень важно учесть момент подключения файлов скриптов и стилей, они должны быть подключены следующим образом:
Это важно, так как в случае статического подключения, оптимизировать файлы не удастся.
Уже только это может дать ощутимое ускорение загрузки страниц сайта.
Сжать изображения
Основным «тяжелым» ресурсом на веб-странице являются изображения. Чем больше их вес, тем медленнее загружается страница.
Для Битрикса существует отличное бесплатное решение для оптимизации изображений без потери качества. Работает оно буквально в один клик.
Часто веб-мастера упускают оптимизацию изображений, а зря. Нам приходилось встречать сайты, где в плейсхолдеры 300х400 пикселей вставлены картинки размером 1200х1600.
Представьте, насколько медленно грузится такой интернет-магазин, если в его каталоге 40 тысяч товаров.
Отложить загрузку медиа-контента
Что пользователю важнее увидеть в первую очередь: красивые картинки или основной контент сайта? Картинки, безусловно, важны, но лучше первым делом показать структуру и контент. Для решения этой задачи можете воспользоваться плагином JQuery Lazy. Для его работы также необходимо использовать библиотеку JQuery.
Подключение плагина в шаблоне сайта
use Bitrix\Main\Page\Asset;
Asset::getInstance()->addJs(SITE_TEMPLATE_PATH . «/js/jquery.min.js»);
Asset::getInstance()->addJs(SITE_TEMPLATE_PATH . «/js/jquery.lazyloading.min.js.js»);Инициализация плагина для выбранного класса изображений
Изображениям необходимо добавить выбранный класс .lazy-img , а также заменить атрибут src на data-src
» >
Для решения проблемы с изображениями являющимися background-ом, вместо css свойства background: url(/images/cloud.jpg) следует добавить класс .lazy-img и атрибут data-src для блока
Настроить время жизни кеша
Эта настройка определяет частоту обновления информации на странице.
Если информация на сайте обновляется раз в сутки, то ошибочно будет оставлять время жизни кэша по умолчанию (3600 с). Необходимо выставить значение 24 часа (86400 с), иначе каждый час посетитель будет заново загружать контент с сервера.
Этот параметр важно учитывать и выставлять с учётом периода реального обновления информации на сервере.
Проверить, что подключён механизм кеширования memcached
Memcached – это сервис кэширования данных в оперативной памяти на основе хеш-таблицы. Это самый быстрый способ кеширования, так как ОС при наличии ресурсов будет держать последние открытые файлы в памяти. Поэтому убедитесь, что он подключён.
Когда мы переносим сайты на хостинг, в нашем шаблоне он включен по умолчанию. Проверьте в настройках сайта (dbconn), что этот механизм включен и используется, потому что он также обеспечивает ускорение в работе.
Подключить CDN
Битрикс предоставляет возможность использовать технологию CDN (Content Delivery Network), которая позволяет загружать картинки, стили и скрипты с сервера, находящегося ближе всего к пользователю. Это увеличивает скорость загрузки всей страницы.
Для включения данной опции необходимо перейти в Настройки — Облако 1С-Битрикс — Ускорение сайта (CDN).
После включения CDN произведите замер скорости загрузки для исключения противоположного эффекта.
В Также в панели есть инструмент измерения скорости загрузки отклика сайта. Он измеряет скорость загрузки сайта у посетителей.
Этот тест показывает четыре зоны — “Очень быстро”, “Быстро”, “Медленно” и “Очень медленно”, а также среднее время загрузки. Рассчитывается для 1000 последних посетителей вашего сайта. Скорость сайта фактически показывает, как быстро отобразился ваш сайт для большинства из этих 1000 посетителей.
Также можно тестировать скорость загрузки и с помощью сервиса Google PageSpeed или с помощью средств разработчика в одном из современных браузеров.
Оптимизировать настройки БД
В настройках БД важно проверить несколько параметров.
Настроить тип таблиц
Если мы говорим про современные проекты, которые переносим с других серверов, проверьте, что тип таблиц в базе – InnoDB.
Сайты с этим типом таблиц работают быстрее и надёжнее с точки зрения сохранности данных. Это соответствует рекомендациям Битрикс.
Настроить параметр buffer pool size
Общая рекомендация — проверять и выставлять innodb buffer pool size примерно равным объёму БД.
В шаблоне BitrixVM он настраивается автоматически в зависимости от объема оперативной памяти на сервере.
Создать фасетные индексы
Данный механизм позволяет сэкономить время на выдаче результата запроса.
Например, вы решили найти на сайте информацию о BMW M5. Без использования фасетного индекса поиск осуществлялся бы сначала по маркам автомобилей, а затем по модельному ряду. Фасетные индексы заранее предопределяют возможные варианты и поиск выдаст результат быстрее.
Для создания фасетного индекса необходимо, чтобы свойства товара присутствовали в умном фильтре. После чего во вкладке Контент — Инфоблоки — Фасетные индексы следует запустить процесс создания индексов.
Включить композитный режим работы сайта
Заходим в панель управления сайтом. Переходим в раздел
Настройки > Настройки продукта > Композитный сайт > Настройки > Композит
Нажимаем «Включить композит»
Также нужно установить время жизни кэша сутки (86400 сек), так как 120 секунд ухудшат производительность.
Включаем настройки nginx для композитного сайта через утилиту командной строки
/opt/webdir/bin/bx-sites -o json -a composite —enable —site=default
(вместо default, если нужно, вписываем имя требуемого сайта)
Для отключения, соответственно:
/opt/webdir/bin/bx-sites -o json -a composite —disable —site=default
Отключить лишние модули
В Битриксе есть модули, которые не все используют. Они включены по умолчанию, но нужны далеко не каждому сайту.
К ним можно отнести AD/LDAP интеграцию, Push and Pull, Wiki, А/B-тестирование, Веб-аналитику, Веб-кластер, Веб-мессенджер, Веб-сервисы, Дизайнер бизнес-процессов, Документооборот, Календарь событий, Конструктор отчетов, Менеджер идей, Мобильную платформу, Мобильное приложение для интернет-магазина, Обучение, Перевод, Почту, Техподдержку, Универсальные списки, Управление масштабированием, а также модуль интеграции с “Битрикс24”. Все они отрицательно влияют на производительность. Поэтому неиспользуемые модули важно отключить.
Другой пример такого модуля – “Сайты24”, который позволяет быстро создавать простые сайты на 1С-Битрикс без веб-разработчика. Его тоже можно отключить, чтобы ускорить работу основного сайта.
Отследить медленные запросы и узкие места в структуре сайта и БД
Часто к нам обращаются клиенты с такой проблемой: начал тормозить сайт, который до этого работал хорошо.
Например, инженеры анализируют нагрузку и видят, что большинство запросов идёт со стороны сервиса MySQL. При этом по данным мониторинга за предыдущие дни повышенной загрузки раньше не было.
Сначала инженеры пробуют выяснить у клиента, что именно менялось на сайте. И если клиент не может сказать точно, тогда инженеры с помощью специальных утилит отслеживания, смотрят, какие запросы выполняются медленно или создают высокую нагрузку на базу данных.
- mytop
- mysqldumpslow
- pt-query-digest (требуется, если установлен Percona Server)
Иногда видно, что на сайте появились ресурсоёмкие циклические запросы, которые и тормозят работу.
Мы указываем на них заказчику. Он понимает, какими изменениями кода они вызваны, и принимает меры, чтобы исправить ситуацию.
Что-то из этого можно увидеть в админке Битрикса самостоятельно, включив отслеживание производительности и не обращаясь к инженерам. Это поможет понять, какие изменения на сайте или в логике его работы приводят к таким тормозящим запросам.
В панели производительности есть возможность посмотреть на показатели и проанализировать детально скорость загрузки страниц.
Несколько вариантов конфига mysql, где включить логирование:
/etc/my.cnf
/etc/mysql/mariadb.conf.d/50-server.cnf
/etc/my.cnf.d/server.cnf
/etc/mysql/conf.d/bx_replica.cnfПравим:
[mysqld]
slow_query_log = 1
long_query_time = 5 # нужное количество в секундах
slow_query_log_file = /var/log/mysql/mysql-slow.logРекомендуется включить режим диагностики и походить по своему сайту. Битрикс фиксирует это в диагностическом модуле и показывает, что вызвало задержки. Также можно посмотреть самые частые и самые медленные запросы к БД. И на основе этих данных решить, что можно оптимизировать в коде сайта.
На какой прирост производительности можно рассчитывать?
При отключении неиспользуемых модулей можно сразу получить прирост производительности в 10-20 пунктов.
Оптимизация запросов MySQL может дать очень много в зависимости от самих запросов. Если сайт работал совсем медленно, показывая индекс 20-30, то после ликвидации медленного запроса индекс может подняться до 100 пунктов.
Вот один из примеров:
Заказчик обратился к нам с интернет-магазином автозапчастей с большим каталогом. Сайт открывался очень медленно. Посмотрели производительность по страницам.
Главная открывалась быстро, переход по разделам тоже. А при открытии карточек товаров сайт начинал тормозить. Так, страница с товаром загружалась 25-30 секунд. Посмотрели на сервере – особенной нагрузки при этом не было.
Стали выяснять у заказчика, что он делал на сайте до появления проблемы. Заказчик вспомнил, что включал модуль нанесения водяных знаков на изображения. Сначала модуль работал нормально, но потом стал переполняться диск, и заказчик этот модуль отключил. Видимо, модуль не отключился полностью и начал вызывать огромную задержку при просмотре товаров.
В итоге клиент заново установил и удалил этот модуль, после чего проблема исчезла.
Правило: вспомните, что вы меняли перед тем как сайт стал тормозить, даже если это, казалось бы, никак не связано с замедлением его работы.
При переносе сайтов на наш хостинг мы проверяем все настройки конфигурации и выставляем их правильно, так как сайты переносятся на подготовленное окружение.
Дополнительно инженеры выставляют параметры, основываясь на специфике каждого отдельного сайта, чтобы обеспечить его максимальную производительность.
Для проектов с высокой нагрузкой иногда приходится придумывать отдельные решения.
Использовать масштабируемый кластер серверов без покупки дорогостоящего решения
Недавно у медиа-компании, которая прогнозировала большой наплыв посетителей, появилась задача увеличить параметры сервера, чтобы гарантированно справиться с нагрузкой.
Мы посчитали, что даже максимальных показателей одного сервера будет недостаточно. Компания обратилась к нам с вопросом, что можно сделать в этой ситуации.
Конечно, есть коробочное решение – пакет Битрикс Enterprise, который позволяет размещать сайты на нескольких серверах, чтобы справляться с высокой нагрузкой. Но это решение очень дорогостоящее, стоимостью в сотни тысяч рублей. Заказчик пока не рассматривал такие инвестиции.
Поэтому мы предложили создать простую версию масштабируемого кластера без необходимости покупать дорогую лицензию.
Контент сайта мы разместили на двух серверах так называемых “php бэкендах”, и добавили отдельный сервер в качестве балансировщика. Он распределял нагрузку между двумя серверами в зависимости от количества запросов к сайту. База данных была вынесена на отдельный сервер.
Тестирование показало, что максимальное количество запросов (RPS) которые способен обработать кластер, выросло как минимум в три раза по сравнению с одиночным сервером. При этом появилась возможность дальнейшего масштабирования кластера за счёт добавления дополнительных бэкендов.
При очередном скачке посетителей такое кластерное решение справилось с возросшей нагрузкой, и задача была решена.
Таким образом, клиент получил кластерное решение без необходимости платить сотни тысяч рублей за покупку дорогой лицензии. Задача была решена на порядок меньшим бюджетом.
Двойной эффект от ускорения сайта
Увеличение скорости работы сайта имеет двойной эффект.
Во-первых, быстрые сайты, которые “летают”, имеют для посетителей “вау-эффект”. По сравнению с ними сайты конкурентов кажутся ещё более медленными и задержки при работе с ними начинают раздражать. А выделяющийся на их фоне быстрый сайт не только подтверждает, что компания вложилась в технологии и подумала об удобстве пользователей, но и создаёт “эффект притяжения” — на таком сайте хочется дольше находится, чаще возвращаться и совершать больше транзакций.
И во-вторых, как отмечают многие из наших клиентов, ускорение загрузки страниц сайта повышает его позиции в поисковой выдаче Google и Яндекс. А это уже прямая коммерческая выгода.
Мы постарались в этой статье написать о тех приёмах увеличения скорости загрузки, которые можно как использовать самостоятельно, так и обратиться за консультацией к нашим специалистам. Будем рады помочь ускорить и ваш интернет-проект.
Если у вас есть что добавить к этим способам или вы захотите поделиться своими – напишите в комментариях. Будет полезно всем, кто работает в этом направлении.
Статья добавлена 1 год назад. Автор — Eltigro
Настройка базы данных MySQL
Оптимизация работы с базой данных для MySQL-версии продукта является одной из важнейших стратегий в оптимизации системы в целом, так как продукт активно работает с базой данных.
Простой формат данных MyISAM хранит каждую таблицу с данными или индекс в отдельном файле. В целом, на небольших по нагрузке сайтах данный формат является наиболее быстрым, хотя и не обеспечивает полной целостности и надежного хранения данных за счет отсутствия транзакций.
Основным недостатком MyISAM с точки зрения производительности является блокировка на уровне таблицы при выполнении тех или иных операций. В результате, при большой нагрузке MySQL именно MyISAM таблицы становятся основным узким местом в системе, мешая увеличивать утилизацию машины и число обрабатываемых запросов. Это также приводит к увеличению времени работы страницы за счет ожидания используемых таблиц на уровне MySQL.
Рекомендуется переводить все таблицы проекта в формат данных InnoDB. Формат InnoDB, начиная с версии MySQL 4.0, входит в стандартную поставку продукта и обеспечивает надежное хранение данных, транзакционность и блокирование данных на уровне строки.
Два важных момента, которые дают основание предпочесть таблицы InnoDB перед MyISAM:
- Надежность. В MyISAM высока вероятность сбоя таблиц, особенно больших, особенно при высокой посещаемости, особенно часто изменяемых. Есть риск потерять несколько (десятков, сотен) записей и целостность данных. В InnoDB чинить отдельные таблицы не придется. Если упадет, так все сразу. Но на практике это — исключительное явление, практически не встречаемое. Благодаря транзакционности, риск нарушения целостности минимальный. Недостатки InnoDB: нужно внимательно следить за свободным местом на диске; накапливающаяся фрагментация данных (лечится периодическим переводом таблиц из InnoDB в MyISAM и обратно).
- Скорость. На невысокой посещаемости 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-файл и реальный результат подключения временной папки может быть отрицательным.
Список ссылок по теме:
11 «рецептов приготовления» MySQL в Битрикс24
Проектируя, разрабатывая и запуская наш новый большой проект — «Битрикс24», мы не только хотели сделать по-настоящему классный сервис для командной работы (к тому же еще и бесплатный — до 12 пользователей), но еще и собрать и накопить опыт по эксплуатации облачных веб-сервисов, «прокачать» свою компетенцию в разработке высоконагруженных отказоустойчивых проектов и — самое главное — поделиться этими знаниями как с нашими партнерами, так и со всеми веб-разработчиками, кому близка тема «хайлоада». 🙂
Конечно, в одной статье (и даже не в одной) невозможно описать универсальный «рецепт», который бы подошел абсолютно для всех проектов: для кого-то важнее производительность (иногда — даже в ущерб надежности), для кого-то — наоборот, отказоустойчивость превыше всего, где-то много маленьких таблиц, где-то — большой объем данных…
Мы постарались описать те «изюминки», которые не раз помогали нам в работе в решении тех или иных практических задач. Надеемся, они окажутся полезными и для вас. 🙂
Начнем по порядку.
Мы не раз уже говорили и писали о том, что «Битрикс24» развернут в Амазоне. И раз мы так любим и активно используем различные облачные сервисы, первый же вопрос…
1. Почему не используем RDS?
Amazon Relational Database Service (Amazon RDS) — облачная база данных. Есть поддержка MS SQL, Oracle и — что было интересно нам — MySQL.
Долго присматривались, хотели использовать в своем проекте… В итоге отказались от этой идеи. Несколько ключевых причин:
- Во-первых, система недостаточно гибкая и прозрачная. Например, вы не получаете полноценного root-доступа к базе. А это значит, что какие-то специфичные (конкретно для вашего проекта) настройки, возможно, не получится сделать.
- Есть риск долгого даунтайма в случае какой-либо аварии. И практика показывает, что риск этот вполне реален. Да, чаще страдают те базы, которые расположены только в одной зоне, и для обеспечения отказоустойчивости можно использовать так называемые Multi-AZ DB Instances. Но — о них далее.
- При использовании Multi-AZ DB Instances для базы постоянно пишется standby бэкап в другую AZ (Availability Zone), и в случае аварии в первой зоне происходит автоматическое переключение на другую. Но в этом случае один инстанс с базой стоит ровно в два раза дороже. При этом пользователь эффективно использует ресурсы только одной машины (в отличие от схемы с «мастер-мастер» репликацией, о которой мы недавно писали).
2. Master-Slave? Нет, Master-Master!
Стандартная схема репликации в MySQL «Master-Slave» давно и успешно применяется на многих проектах и решает несколько задач: масштабирование нагрузки (только на чтение) — перераспределение запросов (SELECT’ов) на слейвы, отказоустойчивость.
Но решает — не полностью.
1. Хочется масштабировать и запись.
2. Хочется иметь надежный failover и продолжать работу автоматически в случае каких-либо аварий (в master-slave в случае аварии на мастере нужно один из слейвов в ручном или полу-автоматическом режиме переключить в роль мастера).Чтобы решить эти задачи, мы используем «мастер-мастер» репликацию. Не буду сейчас повторяться, этой технике у нас недавно был посвящен отдельный пост на Хабре.
3. MySQL? Нет, Percona Server!
Первые несколько месяцев (на прототипах, в процессе разработки, в начале закрытого бета-тестирования сервиса) мы работали на стандартном MySQL. И чем дольше работали, тем больше присматривались к различным форкам. Самими интересными, на наш взгляд, были Percona Server и MariaDB.
Выбрали мы в итоге Перкону — конечно, из-за похожего «перевернутого» логотипа. 😉
… и нескольких фич, которые оказались крайне важными для нас:
- Percona Server оптимизирован для работы с медленными дисками. И это очень актуально для «облака» — диски там почти всегда традиционно медленнее (к сожалению), чем обычные диски в «железном» сервере. Проблему неплохо решает организация софтверного рейда (мы используем RAID-10), но и оптимизация со стороны серверного ПО — только в плюс.
- Рестарт базы (при большом объеме данных) — дорогая долгая операция. В Перконе есть ряд фич, которые позволяют делать рестарт гораздо быстрее — Fast Shut-Down, Buffer Pool Pre-Load. Последняя позволяет сохранять состояние буфер-пула при рестарте и за счет этого получать «прогретую» базу сразу после старта (а не тратить на это долгие часы).
- Множество счетчиков и расширенных отчетов (по пользователям, по таблицам, расширенный вывод SHOW ENGINE INNODB STATUS и т.п.), что очень помогает находить, например, самых «грузящих» систему клиентов.
- XtraDB Storage Engine — обратно совместим со стандартным InnoDB, при этом гораздо лучше оптимизирован для хайлоад проектов.
Важный момент — переход со стандартного MySQL на Percona Server вообще не потребовал изменения какого-либо кода или логики приложения.
А, вот, сам процесс «переезда» был достаточно интересным. И благодаря использованию схемы с «мастер-мастер» репликацией, прошел совершенно незаметно для наших пользователей. Даунтайма просто не было.
Схема переезда была такой:
- «Нулевой» шаг — подняли тестовый стенд их снэпшота машины с базой с реальными данными. И на нем стали отлаживать конфигурацию для стабильной работы. Ну и, конечно, подбирать специфичные для Перконы опции в конфигурационном файле.
- Получив стабильную конфигурацию, переключили весь траффик на один ДЦ, а базу без нагрузки выключили из репликации.
- На этой базе осуществили переход на Percona Server.
- Включили базу в репликацию (стандартный MySQL и Percona Server совместимы).
- Дождались синхронизации данных.
- После этого проделали ту же процедуру со второй базой.
4. MyISAM? InnoDB?
- На долгих запросах в MyISAM лочится вся таблица. В InnoDB — только те строки, с которыми работаем. Соответственно, в InnoDB долгие запросы в меньшей степени влияют на другие запросы и не отражаются на работе пользователей.
- На больших объемах данных и при высокой нагрузке таблицы MyISAM «ломаются». Это — известный факт. В нашем сервисе это недопустимо.
- Ну, и раз уж у нас есть «улучшенный» InnoDB — XtraDB, конечно, мы будем использовать именно этот storage engine. 🙂
Переходим от архитектурных вопросов к более практическим. 🙂
5. Все ли данные нужно реплицировать? Нет, не все.
Почти в любом проекте есть некритичные для потери или восстанавливаемые данные. В том числе — и в базе данных.
В нашем случае такими данными были сессии. Что было плохого в том, что реплицировалось все подряд?
- В таблицах сессий наряду с SELECT’ами много операций записи (INSERT, UPDATE, DELETE). Это значит, что мы даем лишнюю нагрузку на slave базу. Ту нагрузку, которую можно избежать.
- Кроме того, при достаточно большом значении query_cache_size мы столкнулись с тем, что активная работа с этими таблицами и их участие в репликации приводят к тому, что многие треды «подвисают» в состоянии «waiting for query cache lock» (видно в SHOW PROCESSLIST). Далее это чревато повышенной нагрузкой на CPU и общей деградацией производительности.
Как исключать? Есть разные способы.
1. На уровне приложения в том коннекте, где идет работа с таблицами, которые мы хотим исключить из репликации, выполняем:
SET sql_log_bin = 0;2. Более простой и понятный способ — указать исключение в конфигурационном файле MySQL.
replicate-wild-ignore-table = %.b_sec_sessionТакая конструкция исключает из репликации таблицы b_sec_session во всех базах.
Все немножко более сложно в том случае, если вам нужна более сложная логика. Например, не реплицировать таблицы table во всех базах, кроме базы db.
В таком случае вам придется немного порисовать схемки наподобие тех, которые дает MySQL, чтобы составить правильную комбинацию опций — фильтров.
- Evaluation of Database-Level Replication and Binary Logging Options
- Evaluation of Table-Level Replication Options
Много споров вызывает вопрос, использовать ли STATEMENT-based или ROW-based репликацию. И тот, и другой вариант обладают и плюсами, и минусами.
По умолчанию в MySQL (Percona) 5.5 используется STATEMENT-based репликация.
На нашем приложении в такой конфигурации мы регулярно видели в логах строки: «Statement may not be safe to log in statement format».
Кроме того, сравнение двух баз в мастер-мастер репликации показывало, что могут появляться расхождения в данных. Это, конечно, было недопустимо.
В MySQL есть интересное решение, которое нас полностью устроило — использовать MIXED формат бинлога:
binlog-format = mixedВ этом случае по умолчанию репликация идет в режиме STATEMENT и переключается в ROW как раз в случае таких небезопасных операций.
7. Репликация сломалась. Что делать?
Репликация иногда все-таки ломается. Особенно страшно (поначалу :)) это звучит при работе с «мастер-мастер».
На самом деле, ничего страшного нет. Правда. 🙂
В первую очередь нужно помнить о том, что описанная схема «мастер-мастер» репликации — это на самом деле просто две обычные «master-slave» репликации. Да, с некоторыми нюансами, но большинство практик, используемых в стандартной схеме, работают и здесь.
Самая простая (и самая часто случающаяся) проблема — ошибка вида «1062 Error ‘Duplicate entry’».
Причины могут быть разными. Например, мы в случае какой-либо аварии с базой переключаем траффик на другой ДЦ. Если запрос уже был выполнен в ДЦ 1, но не успел среплицироваться в ДЦ 2 и был выполнен там повторно — да, получим именно такую ошибку.
Лечится выполнением вот таких команд на слейве:
STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE;Тем самым пропускаем лишний запрос. Далее смотрим состояние репликации:
SHOW SLAVE STATUS\GЕсли требуется, повторяем процедуру.
Да, мы сейчас детально рассматриваем самый простой вариант. Все бывает значительно хуже — рассыпается файловая система, бьются файлы и т.п.
Универсального рецепта «как все починить» нет. Но всегда важно помнить следующее:
- Не паниковать.
- Видеть состояние слейва с помощью SHOW SLAVE STATUS\G.
- Видеть состояние мастера с помощью SHOW MASTER STATUS.
- Всегда вести лог (log-error = /var/log/mysqld.log) — в нем очень много полезной информации. Например, данные о том, до какой позиции слейв дочитал бинлог мастера. Очень помогает при авариях.
- Если все совсем сломалось — подниматься из бэкапа.
Что же делать, если в схеме с двумя мастерами все-таки что-то пошло не так (например, во время аварии в Амазоне несколько дней назад у нас необратимо повредились файловые системы на нескольких серверах)?
Решение «в лоб» — перелить данные из одного сервера на другой и запустить репликацию с нуля — слишком долго.
В Амазоне мы используем механизмы снэпшотов дисков и создание образов (AMI) целых машин. Это позволяет очень быстро развернуть полную копию нужного сервера — например, по состоянию на несколько часов назад.
Если мы просто развернем машину из бэкапа, мы получим интересный эффект: мы начнем читать данные из бинлогов «живого» мастера (с момента, когда создавался бэкап), но прочитаем лишь половину их, так как по умолчанию записи с сервера с тем же server-id (из «будущего» относительно времени бэкапа) реплицироваться не будут. Это делается для того, чтобы избежать «зацикливаний» в «мастер-мастер».
1. Весь траффик идет на «живой» ДЦ. На тот сервер, который мы восстанавливаем нагрузки нет.
2. На сервере, поднятом из бэкапа, сразу останавливаем mysqld и вписываем в конфиг:skip-slave-start replicate-same-server-id #log-slave-updates = 1 ; комментируем!3. Запускаем mysqld и стартуем репликацию.
4. После того, как данные синхронизированы, возвращаем конфиг в исходное состояние:#skip-slave-start #replicate-same-server-id log-slave-updates = 15. Так как у нас — «мастер-мастер», нам нужно запустить репликацию и в обратную сторону. Останавливаем репликацию на том сервере, который мы восстанавливали, и выполняем:
SHOW MASTER STATUS;Если репликацию не остановим, данные будут меняться.
6. Стартуем с нужной позиции репликацию на первом (живом) сервере:STOP SLAVE; CHANGE MASTER TO MASTER_LOG_FILE='. ', MASTER_LOG_POS = . ; START SLAVE;Вписываем данные, полученные в пункте 5.
7. Стартуем репликацию и на втором сервере.9. Где баланс между производительностью и надежностью репликации?
Есть много опций в MySQL / Percona, которые позволяют кардинально повысить надежность и сохранность данных в случае, например, внезапных ребутов. Практически все они столь же кардинально снижают быстродействие системы.
Мы для себя нашли баланс в такой комбинации опций:
sync_binlog = 1 sync_master_info = 0 sync_relay_log = 0 sync_relay_log_info = 0 innodb-flush-log-at-trx-commit = 2Бинлог для нас критически важен, поэтому sync_binlog = 1. Но при этом бинлоги хранятся на отдельном диске в системе, поэтому запись на этот диск не снижает производительность системы в целом.
10. Как вообще оценивать производительность системы?
Если у нас есть большие «тяжелые» запросы, то, конечно, мы банально ориентируемся на время их выполнения.
Чаще же (и в нашем случае — именно так) система обрабатывает много-много мелких запросов.
Конечно, можно использовать различные синтетические тесты для оценки производительности системы. И некоторую оценку они дадут. Но ведь хочется иметь какие-то реальные показатели (желательно — в цифрах :)), которые можно было бы применять «в бою».
В Percona Server есть замечательный инструмент:
SELECT * FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME;+----------------+-------+----------------+ | time | count | total | +----------------+-------+----------------+ | 0.000001 | 0 | 0.000000 | | 0.000010 | 6555 | 0.024024 | | 0.000100 | 56132 | 2.326873 | | 0.001000 | 23165 | 6.686421 | | 0.010000 | 9755 | 39.737027 | | 0.100000 | 1437 | 40.831493 | | 1.000000 | 141 | 31.785571 | | 10.000000 | 9 | 17.891514 | | 100.000000 | 0 | 0.000000 | | 1000.000000 | 0 | 0.000000 | | 10000.000000 | 0 | 0.000000 | | 100000.000000 | 0 | 0.000000 | | 1000000.000000 | 0 | 0.000000 | | TOO LONG | 0 | TOO LONG | +----------------+-------+----------------+ 14 rows in set (0.00 sec)Такая гистограмма распределения времени выполнения запросов очень хорошо помогает оценивать общее состояние системы.
Например, мы для себя определили некий критический порог — не более 5% запросов (от общего числа) с временем выполнения более 0.01 сек.
Чтобы отслеживать это состояние в динамике, написали простой плагин к Munin’у, который как раз и рисует график по данному соотношению. Очень удобно, и — главное — это живая понятная метрика.
11. Сбалансированность по памяти.
Настройки MySQL должны быть такими, чтобы потребление памяти было сбалансировано!
Вроде, простое и понятное правило, но о нем часто забывают. Каюсь, сами пару раз (в начале, на прототипе :)) получили OOM (Out of memory) и — как следствие — «убитый» операционной системой процесс mysqld.
В идеале — процесс mysqld должен работать так, чтобы полностью помещаться в оперативной памяти и не оперировать свопом.
Обязательно — все процессы системы должны помещаться в память+swap.
Зачастую подсчеты, сколько памяти может потребить mysqld, оказываются для многих неочевидными.
Формула примерно такова:
- Размер глобальных буферов: key_buffer_size + tmp_table_size + innodb_buffer_pool_size + innodb_additional_mem_pool_size + innodb_log_buffer_size + query_cache_size
- Размер буфера для одного коннекта: read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + join_buffer_size
- Максимально возможное использование памяти: глобальные буферы + буферы подключений * максимальное число коннектов
# wget mysqltuner.pl # perl mysqltuner.plСпасибо, что дочитали до этого места! 🙂
Мы рассмотрели лишь некоторую часть практических вопросов и приемов, которые мы используем в работе «Битрикс24». В том числе благодаря им, сервис растет и развивается.
Надеемся, что наш опыт поможет и вам в создании и развитии ваших проектов.
И уже сейчас видно, что объема одной статьи совершенно недостаточно. В ближайшее время постараемся продолжить тему использования MySQL в больших проектах, поделимся новыми рецептами и опишем наиболее интересные и востребованные темы более подробно.
- Блог компании Битрикс24
- MySQL