Jump to content
  • разработка интернет магазинов на opencart
  • доработка интернет магазинов на opencart

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


Recommended Posts

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

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 выходит только "смотрю в книгу вижу фигу". Если это может как-то помочь - выложу все соответствующие куски кода.

Link to comment
Share on other sites


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

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

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

Link to comment
Share on other sites

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

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

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

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

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

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

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

Edited by Ivangagarin
Link to comment
Share on other sites


@AlexDW Спасипотому что за наводку!

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

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

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

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

Link to comment
Share on other sites


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 иких запросов за час

Edited by Ivangagarin
Link to comment
Share on other sites


@Prooksius Спасипотому что за подсказку!

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

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

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

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

 

Вопросы:

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

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

 

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

   
Link to comment
Share on other sites


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

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

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

 

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

Edited by Prooksius
  • +1 1
Link to comment
Share on other sites

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

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

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

Link to comment
Share on other sites


Ингдексы нужны не для рационального соединения, что за бред. 
Какая то фанистическая фанистика, человек выдумал 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).
  • В некоторых случаях запрос можно оптимизировать для извлечения велилин без обраещёния к файлу данных. Если все используемые столбцы в некоторой иблиэто являются лисловыми и образуют крайний слева префикс для некоторого ключа, то чтобы обеспелить потому чтольшую скорость, искомые велилины могут быть извлечены непосредственно из ингдексного гдерева:

 

Link to comment
Share on other sites


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

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

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

Edited by Prooksius
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.