mySQL error: max_user_connections

[ungifted]

Имеем форум 1.3 модификация от Игорька. Обьём базы около 150 Мб. Обычно на форуме одновременно около 100 человек. Периодически в результате зависания коннектов форум валится и выдаёт:

mySQL error: User [username] has already more than 'max_user_connections' active connections

mySQL error code:

 

В связи с чем возникает вопрос:

С каким максимальным объёмом нормально работает движок форума?

 

Оптимизация помогает на день-два, после чего начинаются подобные же проблеммы. По тарифу у провайдера на форум количество выделенных процессов - 96.

 

Если кто сталкивался буду признателен за совет.

[ImUgh]

Имеем форум 1.3 модификация от Игорька. Обьём базы около 150 Мб. Обычно на форуме одновременно около 100 человек. Периодически в результате зависания коннектов форум валится и выдаёт:

mySQL error: User [username] has already more than 'max_user_connections' active connections

mySQL error code:

 

В связи с чем возникает вопрос:

С каким максимальным объёмом нормально работает движок форума?

 

Оптимизация помогает на день-два, после чего начинаются подобные же проблеммы. По тарифу у провайдера на форум количество выделенных процессов - 96.

 

Если кто сталкивался буду признателен за совет.

<{POST_SNAPBACK}>

Вопрос не в том, сколько дежит движок, а в хостере.

Очевидно, что он не справляется.

И вопрос не в количестве процессов, а в количестве допустимых одновременных коннектов к БД от одного акка на хостинге.

И, на сколько я понимаю, оптимизаци БД тут вообще не должна помочь - от этого число одновременных коннектов не может измениться.

 

Или менять хостера, или как-то договаривться с текущим.

[ungifted]

Сорри за дезинформацию по поводу процессов - имелось в виду именно число коннектов.

Вообще события развивались следущим образом:

В определённый момент (дня 3-4) начались периодические ошибки эскуэль про максимум коннектов, скрипты настройки форума не менялись.

Пров божится что всё в порядке и что некий коннект зависает и тормозит все остальные обращения к данной таблице. По поводу оптимизации - насколько я понимаю (если не понимаю - поправьте пжлста ) - если у меня битый индекс, форум при попытке обратиться к таблице может вызвать зависание этого самого коннекта. Все остальные будут ждать и находиться в состоянии locked, а мускуэль будет выделять ресурсы пока не достигнет отведённого ему максимума. Возможно всё происходит немного по другому, но то что зависшие коннекты есть - это больше похоже на правду. В связи с этим и вопросы - нормально ли движок форума работает с таблицей весом 150 Мб? 100 одновременных коннектов это мало для форума испытывающего подобную нагрузку? В общем хотелось бы просто определиться с направлением где искать.

[Dekker]

Косяки IBF. Версии форума 1.2++ (до 2.x)

 

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

[ImUgh]

Dekker

тогда уж лучше сюда

Чт за бред в структуре таблицы ibf_voters?

тут коллекция побогаче

[Vic'er]

Имеем форум 1.3 модификация от Игорька. Обьём базы около 150 Мб. Обычно на форуме одновременно около 100 человек. Периодически в результате зависания коннектов форум валится и выдаёт:

mySQL error: User [username] has already more than 'max_user_connections' active connections

mySQL error code:

 

В связи с чем возникает вопрос:

С каким максимальным объёмом нормально работает движок форума?

 

Оптимизация помогает на день-два, после чего начинаются подобные же проблеммы. По тарифу у провайдера на форум количество выделенных процессов - 96.

 

Если кто сталкивался буду признателен за совет.

<{POST_SNAPBACK}>

 

Посмотри здесь еще - Topic Hints для IPB v1.3 - тоже сталкивался с этим. Очень существенная нагрузка возмникает при обработке таблицы постом - нужно выискивать все существующие запросы (особенно те, где происходит LEFT JOIN этой таблицы) и пытаться оптимизировать именно их.

[NvG]

O F F T O P I C :

Посмотри здесь еще - Topic Hints для IPB v1.3 - тоже сталкивался с этим. Очень существенная нагрузка возмникает при обработке таблицы постом - нужно выискивать все существующие запросы (особенно те, где происходит LEFT JOIN этой таблицы) и пытаться оптимизировать именно их.

А лцчше всего вообще без лефт джойнов, а подгружать отдельно

 

Moderators: пост можно удалить

[ungifted]

Посмотри здесь еще - Topic Hints для IPB v1.3 - тоже сталкивался с этим. Очень существенная нагрузка возмникает при обработке таблицы постом - нужно выискивать все существующие запросы (особенно те, где происходит LEFT JOIN этой таблицы) и пытаться оптимизировать именно  их.

<{POST_SNAPBACK}>

 

Мода такого не ставил - но картина (по процессам) - очень похожая...

Ситуация прояснилась слегка - было замечено что проблему вызывает следующий запрос:

SELECT COUNT(DISTINCT(t.tid)) as tcnt,

COUNT(DISTINCT(p.pid)) as pcnt FROM ibf_posts p,

ibf_topics t

 

Насколько я понимаю это запрос на выборку статистики из таблиц постов и топиков. Процесс иногда пробивается но чаще виснет и лочит всё остальное - все последующие процессы находятся в состоянии locked (или как вариант waiting for table).

 

В связи с этим вопрос - как гарантированно отключить фичи делающие вышеозначенный запрос чтобы гарантированно удостовериться что дело именно в нём. Достаточно ли отключить велком панель в skin_boards.php?

Убрал велком панель из портала - вроде всё встало на свои места. Может что-то не так в этом запросе? Но по логике неверно сформированный запрос вызывал бы просто ошибку, а этот иногда (редко но всё же...) заканчивался успешно.

Вот ссылка на буржуйский ресурс - ситуация практически аналогичная: первый запрос sending data, остальные locked: http://forums.ipbhelpers.com/lofiversion/i....php/t4572.html