Ошибка по 'max_user_connections', ложится сайт

[Ivangagarin]

Прошу помощи с постоянно возникающей ошибкой:

Warning: mysqli::__construct(): (42000/1226): User 'hobbyho1_data' has exceeded the 'max_user_connections' resource (current value: 30) in /home/hobbyho1/public_html/system/library/db/mysqli.php on line 7Warning: DB\MySQLi::__construct(): Couldn't fetch mysqli in /home/hobbyho1/public_html/system/library/db/mysqli.php on line 10Warning: DB\MySQLi::__construct(): Couldn't fetch mysqli in /home/hobbyho1/public_html/system/library/db/mysqli.php on line 10
Fatal error: Uncaught Exception: Error: <br />Error No: in /home/hobbyho1/public_html/system/library/db/mysqli.php:10 Stack trace: #0 /home/hobbyho1/public_html/system/library/db.php(31): DB\MySQLi->__construct('localhost', 'hobbyho1_data', 'PW*cfdEH}L0#', 'hobbyho1_data', '3306') #1 /home/hobbyho1/public_html/system/framework.php(80): DB->__construct('mysqli', 'localhost', 'hobbyho1_data', 'PW*cfdEH}L0#', 'hobbyho1_data', '3306') #2 /home/hobbyho1/public_html/system/startup.php(104): require_once('/home/hobbyho1/...') #3 /home/hobbyho1/public_html/index.php(19): start('catalog') #4 {main} thrown in /home/hobbyho1/public_html/system/library/db/mysqli.php on line 10

На сайте 760 товаров, и совсем мало посетителей. Насколько я понимаю, (current value: 30) должно хватить очень на долго и проблема не в этом.

Смотрел все указанные строки в указанных в ошибке файлах, но с моим знанием php выходит только "смотрю в книгу вижу фигу". Если это может как-то помочь - выложу все соответствующие куски кода.

[Prooksius]

6 минут назад, Shureg сказал:

Ну и лимит в 30 - это маловато.

смотрю табличку, там и 5 есть))  Это тогда бы многие сайты ложились на таких хостингах.
Не, мне кажется, что-то с самим сайтом, где-то ошибка.

[esculapra]

9 минут назад, Shureg сказал:

сколько ботов по сайт шарится

В хостингпанели можно посмотреть визиты

[Ivangagarin]

34 минуты назад, Shureg сказал:

Проблема именно в этом. Неизвестно, сколько там у вас соединений модули и тема открывает, сколько ботов по сайт шарится.
Ну и лимит в 30 - это маловато.
Сравните, тут табличка есть

Согласен, 30 - маловато, имею в виду, что на первый год как минимум должно хватить, и переход на другой хостинг, даже с max_user_connections 300 решит проблему только временно. Так как уже максимальный скачок перегрузки вижу 360%. А сайт существует пол года и совсем не раскручен.

26 минут назад, Prooksius сказал:

Не, мне кажется, что-то с самим сайтом, где-то ошибка.

100%, или какие-то запросы к БД зацикливаются, или висят открытыми, или ещё фиг знает что. Тут мои знания заканчиваются.

Именно в этом и прошу помочь, как найти, какие именно запросы и как это пофиксить.

Змінено 26 лютого 2021 користувачем Ivangagarin

[AlexDW]

https://www.ukraine.com.ua/wiki/hosting/mysql/issues/max-user-connections/

[Ivangagarin]

@AlexDW Спасибо за наводку!

Пробую определить медленные запросы в БД, но получаю ответ:

#1227 - В доступе отказано. Вам нужны привилегии SUPER для этой операции

У меня виртуальный виртуальный хостинг, так что права мне дадут вряд ли.

Договариваюсь со службой поддержки, чтобы включили лог.

[Ivangagarin]

SELECT COUNT(DISTINCT p.product_id) AS total FROM oc_category_path cp LEFT JOIN oc_product_to_category p2c ON (cp.category_id = p2c.category_id) LEFT JOIN oc_product p ON (p2c.product_id = p.product_id) LEFT JOIN oc_product_description pd ON (p.product_id = pd.product_id) LEFT JOIN oc_product_to_store p2s ON (p.product_id = p2s.product_id) WHERE pd.language_id = '8' AND p.status = '1' AND p.date_available <= NOW() AND p2s.store_id = '0' AND cp.path_id = '371';

 

Доходит до  # Query_time: 8.295446

Насчитал 2485 таких запросов за час

Змінено 26 лютого 2021 користувачем Ivangagarin

[Prooksius]

 

[Ivangagarin]

@Prooksius Спасибо за подсказку!

Убрал показ количества товаров в категории, сайт стал работать намного быстрее.

Добавил индекс к oc_category_path, стало ещё лучше, даже PageSpeed Insights показал улучшение.

Если чесно - без понятия, что даёт этот индекс, в mqsql я вообще не понимаю, но эффект на лицо.

Посмотрю через время по дашборду, но по сравнению с тем, что было, сайт заработал явно быстрее.

 

Вопросы:

-Если я просто отключил показ количества товара в категории через админку, надо ли делать правки в коде как тут:

Или отключения в админке достаточно и лучше уже не будет?

 

-Таблица oc_session у меня  пока 6,5Мб при 700 товаров. Может не чистить её и не ставить удалятор сессий, а пока-что понаблюдать? А если будет рости - уже принимать меры, что посоветуете?

[Prooksius]

7 часов назад, Ivangagarin сказал:

Если чесно - без понятия, что даёт этот индекс

Если по-простому... MySQL при формировании ответа на SQL запрос соединяет таблицы и вот способ соединения имеет значение. Можно соединять рационально, чтобы оно было быстро, а можно - простым перебором всех значений (full scan) и это будет долго, если записей много.
Индексы нужны, чтобы рациональных способов соединения таблиц было больше.

 

P.S. Изменил: Индексы, в частности, нужны, чтобы рациональных способов соединения таблиц было больше.

Змінено 27 лютого 2021 користувачем Prooksius

[Shureg]

47 минут назад, Prooksius сказал:

Индексы нужны, чтобы рациональных способов соединения таблиц было больше.

Какая удивительная интертрепация 
Вы полагаете, если никакие таблицы не джойнятся, индексы ваще не нужны ?

[Prooksius]

нужны, конечно) Ну я чтобы не растекаться мыслью по опенкарту...

[Yoda]

Индексы нужны не для рационального соединения, что за бред. 
Какая то фантастическая фантастика, человек выдумал mysql...

 

Идем в официальный мануал и читаем:

 

Индексы применяются для быстрого поиска строк с указанным значением одного столбца. Без индекса чтение таблицы осуществляется по всей таблице начиная с первой записи, пока не будут найдены соответствующие строки. Чем больше таблица, тем больше накладные расходы. Если же таблица содержит индекс по рассматриваемым столбцам, то MySQL может быстро определить позицию для поиска в середине файла данных без просмотра всех данных. Для таблицы, содержащей 1000 строк, это будет как минимум в 100 раз быстрее по сравнению с последовательным перебором всех записей. Однако в случае, когда необходим доступ почти ко всем 1000 строкам, быстрее будет последовательное чтение, так как при этом не требуется операций поиска по диску.

Все индексы MySQL (PRIMARY, UNIQUE, и INDEX) хранятся в виде B-деревьев. Строки автоматически сжимаются с удалением пробелов в префиксах и оконечных пробелов (see section 6.5.7 Синтаксис оператора CREATE INDEX).

Индексы используются для того, чтобы:

• Быстро найти строки, соответствующие выражению WHERE.
• Извлечь строки из других таблиц при выполнении объединений.
• Найти величины MAX() или MIN() для заданного индексированного столбца. Эта операция оптимизируется препроцессором, который проверяет, не используете ли вы WHERE key_part_4 = константа, по всем частям составного ключа < N. В этом случае MySQL сделает один просмотр ключа и заменит выражение константой MIN(). Если все выражения заменяются константой, запрос моментально вернет результат:

  SELECT MIN(key_part2),MAX(key_part2) FROM table_name where key_part1=10
  

• Производить сортировку или группирование в таблице, если эти операции делаются на крайнем слева префиксе используемого ключа (например ORDER BY key_part_1,key_part_2). Если за всеми частями ключа следует DESC, то данный ключ читается в обратном порядке (see section 5.2.7 Как MySQL оптимизирует ORDER BY).
• В некоторых случаях запрос можно оптимизировать для извлечения величин без обращения к файлу данных. Если все используемые столбцы в некоторой таблице являются числовыми и образуют крайний слева префикс для некоторого ключа, то чтобы обеспечить большую скорость, искомые величины могут быть извлечены непосредственно из индексного дерева:

 

[Prooksius]

6 часов назад, Yoda сказал:

Идем в официальный мануал и читаем:

Это все  понятно и правильно, согласен.
Но разве индексы не используются в операции JOIN нескольких таблиц БД в соответствии с заданным SQL-запросом, заданной в нем сортировки, других условий?
Казуистикой занимаемся, мне кажется...

Змінено 27 лютого 2021 користувачем Prooksius