Приветствую. Хочу поделится радостью: удалось оптимизировать работу 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
Не согласен с предыдущим оратором по кешу. Кеш кешом, он должен быть, но это не решение проблемы. К кешу лучше относиться как к решению, ускоряющему сайт, но не решающему проблемы его производительности. Банально, может что-нибудь бомбануть, и весь кеш сайта на время похерится. Если система отвечает пользователю с такими тормазами, то покрытие кешом в данном случае будет костылём.
Самохвалов Никита, а я позволю не согласится с вами. Отсутствие кеширования даёт лишнюю нагрузку на мускуль, выстраивая очереди ненужных запросов и смазывая общую картину. А если меню выводит структуру разделов каталога из 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С-Битрикс».