Приветствую. Хочу поделится радостью: удалось оптимизировать работу MySQL.
В БУС монитор производительности на мощном сервере показывал следуюшее:
База данных MySQL (запись) 72 5 600 количество запросов на запись в секунду
База данных MySQL (чтение) 5 869 7 800 количество запросов на чтение в секунду
База данных MySQL (изменение) 4 251 5 800 количество запросов на изменение в секунду
Чего я только с настройками мускуля не крутил, ничего сильно ощутимого результата не давало.
Но нашлась все-таки одна настроечка, которая ну очень сильно меня обрадовала: innodb_flush_log_at_trx_commit=2 После того как я ее прописал, получил следующие циферки:
База данных MySQL (запись) 4 395 5 600 количество запросов на запись в секунду
База данных MySQL (чтение) 6 220 7 800 количество запросов на чтение в секунду
База данных MySQL (изменение) 4 643 5 800 количество запросов на изменение в секунду
Увелечение скорости записи в 60 раз меня ну очень обрадовало.
innodb_flush_log_at_trx_commit - Вам кажется, что InnoDB в сто раз медленнее MyISAM? Вероятно, вы забыли изменить значение этого параметра. Значение по умолчанию 1 означает, что после каждой завершенной транзакции (или после изменения состояния транзакции) лог должен быть сброшен на диск. Это достаточно дорогая операция, особенно если у вас нет Battery backed up cache. Многие приложения, особенно те, в которых раньше использовался MyISAM будут хорошо работать при значении 2, который означает, что не надо сбрасывать буфер на диск, а следует отправить его в кэш операционной системы. Лог по-прежнему будет сбрасываться на диск каждую секунду и максимум, что вы можете потерять - это 1-2 секунды записей. Значение 0 обеспечивает более высокую скорость, но и более низкую надежность. Есть вероятность потерять транзакции даже при падении mysql-сервера. При значении равном 2 единственная возможность потерять данные - это фатальный сбой операционной системы.
Немного передохнем и продолжим оптимизировать. Надеюсь тема не баян, и будет полезна. Обновление Руководство по настройке и установке уже рекомендует ставить innodb_flush_log_at_trx_commit=0
Последнюю неделю расширили каталог магазина на 300 000 товаров. Так же очень глубокая иерархия разделов товаров (книг), к слову одних только разделов 11000. Заметил, что при хождении по каталогу, запросы ответы из компонента catalog.section.list очень долгие до 20 секунд.
16 ядер проца 16 гб оперативы ssd винты Используется стандартное битрикс окружение со стандартными параметрами.
Так вот, при небольшой посещаемости сайт начинает виснуть очень сильно, главная страница прогружается до минуты-двух. Процессор в это время загружен на 400% mysqld. Начал использовать mysqltuner. Повышал параметры как требовал отладчик, вылеты стали по реже. Я не силен в настройках mysql, и не могу оценить правильность моих настроек. Вылеты продолжаются. Не могу понять, почему проц. загружается сильно, когда сайт никто не посещает, проверял в nload статистику по трафику (думал вдруг ddos).
Для начала посмотрите MySQL slow log, что бы понять, на чём тормоза возникают.
Новоселов Артем написал: Не могу понять, почему проц. загружается сильно, когда сайт никто не посещает, проверял в nload статистику по трафику (думал вдруг ddos).
Новоселов Артем, проверьте для начала работу кеша на вашем сайте. Т.к. при нормальном кешировании структура разделов не должна запрашиваться на каждом хите. Может у вас отключено кеширование в компоненте меню или еще каком. То что вы описали не есть нормальная работа сайта.
Потом уже смотрите на мускуль и прочее. Как уже выше написали помогут только логи слоу кваери. Ну а если запросы выполняются долго, то можно попробовать их отследить в сеансе мускуля show full processlist;
Смотрите какой запрос висит и начинаете его анализировать: логи, профилировка и explain
Не согласен с предыдущим оратором по кешу. Кеш кешом, он должен быть, но это не решение проблемы. К кешу лучше относиться как к решению, ускоряющему сайт, но не решающему проблемы его производительности. Банально, может что-нибудь бомбануть, и весь кеш сайта на время похерится. Если система отвечает пользователю с такими тормазами, то покрытие кешом в данном случае будет костылём.
Самохвалов Никита, а я позволю не согласится с вами. Отсутствие кеширования даёт лишнюю нагрузку на мускуль, выстраивая очереди ненужных запросов и смазывая общую картину. А если меню выводит структуру разделов каталога из 11 000 разделов, да еще и считая количество активных элементов в разделе, то там любой сервер будет умирать, так как на каждом хите будет выполнятся сложнейший запрос с подзапросами, который сожрет все буферы мускуля, вытеснит в своп, еще и диск просадит . При этом получим общую деградацию производительности системы. Так что я бы не рассматривал кеш как просто ускоритель сайта
Яковенко Дмитрий, Яковенко Дмитрий, Спасибо, ребят, за скорые ответы. С кэшем все в порядке, на всех страницах работает кэш плюс композит. С использованием кэша страница грузится быстро. Тормоза проверял с отключенным кэшем, в режиме отладки панели битрикса, с подстветкой секунд. Меню у меня, естественно, только 3 уровневой глубины и вся иерархия разделов не подгружается. Битрикс окружение поднято на KVM виртуалке. До это не имел дела с таким объемом БД, все работает отлично на других сайтах. Аппаратных ресурсов думаю с излишком хватает.
Все таки проблема в конфигурации Mysql, думаю.
Самохвалов Никита, И еще все настолько плохо, что я не понимаю что такое воркеры
Новоселов Артем написал: Может ли решить проблему операция "Оптимизация БД" или optimization table?
Выполните, но я практически уверен, что проблемы это не решит. Это спасает только когда рушится БД.
Новоселов Артем написал: Тормоза проверял с отключенным кэшем, в режиме отладки панели битрикса, с подстветкой секунд.
Ну так открывайте эту инфу отладочную и смотрите какие запросы в каких компонентах тупят. И тогда уже можно обсуждать что-то более детальнее. Я делал копирование запросов из откладки в эксель, сортировал по времени выполнения запроса и потом уже разбирался с каждым тяжелым запросом.
Яковенко Дмитрий написал: Отсутствие кеширования даёт лишнюю нагрузку на мускуль
Обратите внимание, что я не советовал его отключать: «он должен быть, но это не решение проблемы».
Яковенко Дмитрий написал: А если меню выводит структуру разделов каталога из 11 000 разделов, да еще и считая количество активных элементов в разделе,
Такие объёмы вычисляемых данных лучше «кешировать» не в кеш приложения, а сохраняя промежуточные значения в БД. Кеш может похериться, и чем оптимизированнее будет система, тем меньша риск простоя.
Сталкивались с проблемой? Инструмент анализа индексов не показывает часть медленных запросов. Здесь ребята пишут, что этот инструмент сломан
Я нашел запросы через отладку, которые отрабатываются по 5 - 8 секунд, связаны с умным фильтром и catlog.section.list. Но они такие огромные, что я вряд ли смогу добавить к ним правильный индекс самостоятельно.
Дмитрий, тема не баян. Ссылку на руководство надо поправить https://dev.1c-bitrix.ru/learning/cour...ON_ID=3371 Интересно как можно ещё ускорить работу базы данных? Чтобы было красиво) Ибо даже в данном примере до норматива всё же не дотягивает.
Павел Зюкин написал: Ибо даже в данном примере до норматива всё же не дотягивает.
Это 2012 год, с сервером на WinSrv2008 и IIS7. Там все проблемы от ужасно медленной NTFS были.
Павел Зюкин написал: Интересно как можно ещё ускорить работу базы данных?
Я давно этим вопросом не занимаюсь и не считаю себя в нем большим спецом. Но что касается конфигов, базово это ОЗУ чтоб база влезала, быстрые ssd диски, тюнинг размеров буферов InnoDB. Ну и страница диагностики /bitrix/admin/perfmon_db_server.php?lang=ru
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».