Bitrix. Mysql жрет процессор как не в себя. Куда копать?

Question

[Виктор Рябов]

Имеется интернет магазин на Bitrix управление сайтом. редакция бизнес.

В инфоблоке 170 тыс. элементов , 2000+ секций, 2000+ свойств. нагрузка: 10-40 обращений в минуту.

top показывает что mysql постоянно потребляет 500-600% (5-6 ядер).

/bitrix/admin/perfmon_db_server.php?lang=ru жалуется на
"Процент временных таблиц потребовавших создание на диске (Created_tmp_disk_tables / (Created_tmp_tables + Created_tmp_disk_tables)). Процент более 30% и требуется увеличить параметры tmp_table_size"

Запросы к СУБД выполняются относительно быстро (В show processlist практически пусто. Попытка сопоставить thread и запросы в нем выполняющиеся согласно статьи тоже ничего не дала )

Попытка средствами bitrix найти где можно создать/изменить/удалить индексы ничего не дала. (Выигрыш в несколько процентов на конкретных редких запросах не считается значимым результатом)

если оставить 90 тыс позиций - нагрузка на процессор падает больше чем втрое. (mysql ест 3 ядра максимум. среднее значение : 60-200%)

суть вопроса: как проверить почему нагрузка на процессор так зависит от количества элементов в инфоблоке? (кто виноват: сам фреймворк, установленное готовое решение, или настройки субд )

(Если проблема в mysql по пожалуйста поделитесь правилом по которому надо рассчитывать значение параметров tmp_table_size и max_heap_table_size. Или хотя бы верхней границей , выше которого ставить значения параметров смысла нет)

Comments

[SunTechnik]

А почему бы не попробовать выполнить рекомендуемые : увеличить tmp_table_size

Почему нагрузка зависит от размера инфоблока - данные перестают влазит в какую-то из структур.

[Виктор Рябов]

SunTechnik, поделитесь правилом рассчета значения параметров. Изменение значений параметров tmp_table_size и max_heap_table_size в диапазоне от 200 МБ до 1.5 ГБ никак не меняют наблюдаемую картину.

[ThunderCat]

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

[Виктор Рябов]

спасибо за комментарий. добавил тег.

[Антон]

Для начала покажите результаты проверок:
/bitrix/admin/site_checker.php?lang=ru
/bitrix/admin/perfmon_panel.php?lang=ru
/bitrix/admin/perfmon_db_server.php?lang=ru
/bitrix/admin/perfmon_index_list.php?lang=ru
/bitrix/admin/perfmon_index_complete.php?lang=ru
/bitrix/admin/perfmon_hit_list.php?lang=ru
/bitrix/admin/perfmon_php.php?lang=ru
/bitrix/admin/phpinfo.php
Также для товаров и ТП укажите как храните свойства

значения свойств хранятся:	в общей таблице или в раздельной

И надеюсь, что вы используете innodb

Покажите все скриншоты по ссылкам выше - скажу что поправить.

[shurshur]

У меня был случай, сайт на битриксе начал дико лагать. Поиски привели к тому, что проблему создавала каруселька на главной, в ротации которой были уже удалённые файлы. Так как файл не находился, вместо него показывался 404.php, который грузил ядро битрикса и отдавал контент довольно медленно. У сайта хватало пассивных посетителей с крутящейся каруселькой, чтобы создавать из-за этого бессмысленную нагрузку.

Я наскоро решил это, завернув 404 по расширениям типа .png .jpg .gif в 404fast.php, который битриксовое ядро не грузил. Конечно, правильнее было бы нормально класть статику в каталог, в котором не используется 404.php вообще, но там за годы существования файла такй бардак в файлах был, что решать его мне совсем не хотелось...

Даже вот так бывает, буквально на пустом месте...

[Виктор Рябов]

Антон, спасибо за комментарий. Использую его в качестве отправной точки куда копать. Сейчас пытаюсь понять и исправить то, на что жалуется битрикс.

Answer 1

[ThunderCat]

если оставить 90 тыс позиций - нагрузка на процессор падает больше чем втрое.

Есть мысль что большое количество запросов происходит минуя индексы, которые возможно вообще отсутствуют. Первое что приходит на ум - залогировать все запросы, выбрать типовые и прогнать их ручками через explain. Заодно и посмотреть что там в плане памяти жрется.
Так же стоит посмотреть движок таблиц, может там какой-нить майисам или вообще свой особый, бывало такое.
Ну и возможно у вас где-то вызовы запросов вообще без лимитов, это вполне может сожрать и проц и память подчистую.

нагрузка: 10-40 обращений в минуту.

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

Comments

[Виктор Рябов]

95% запросов выполняется за 0.0001 - 0.001 секунды. (на каждый запрос)

некоторое исключение - поиск. он сильно хитро вымудрено устроен из коробки. и в случае поиска выражения отсутствующего в бд иногда может выдавать дополнительно лишних 1000 запросов занимающих в сумме несколько секунд.

[ThunderCat]

1)

95% запросов выполняется за 0.0001 - 0.001 секунды. (на каждый запрос)

Это вполне может быть результатом работы 6 ядер, а не правильно построенных индексов. Хотя и маловероятно. Опять же, выбрать ВСЮ таблицу занимает НИЧЕГО по времени, но ДОФИГА по памяти, возможно где-то все таки нет лимитов.

некоторое исключение - поиск.

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

Вообще с таким я встречался только в нескольких случаях, но там всегда нагрузку вызывали именно масса запросов, порядка 100 в секунду... тут же все странно... Возможно особенность кода, но так как мускуль причина тормозов - смотреть все равно надо запросы, и потом уже думать как фиксить код.

Answer 2

[electroid]

Нужно проверить что все компоненты на страницах сайта корректно кешируются, проверить страницы компонента каталог и другие страницы. Это можно посмотреть через отладку в верхнем меню на странице сайта.
Также можно потестировать производительность в панели производительности в админке (покажет какие страницы создают нагрузку).
К сожалению без кеширования никакая оптимизация не поможет решить проблему производительности и cpu. Система тянет много тяжелых запросов.