Слишком много подключения к БД ошибка во время обновления кэша

[krisp]

Другая ночь мне пришлось бодрствовать вскоре после 4 утра, где форум вдруг упал на 20 мин, как:


Ошибка базы данных в VBulletin:

mysqli_real_connect () [<a href='function.mysqli-real-connect'> function.mysqli реального подключения </>]: (08004/1040): Слишком много соединений
/ VAR / WWW / виртуальных доменов / ... / httpdocs / входит / class_core.php на линии 1138

MySQL ошибка:
Код ошибки:
Запрос Дата: вторнику, 15 Декабрь 2009 @ 4:28:00 AM
Ошибка Дата: вторник, 15 декабря 2009 @ 4:28:00 AM
Автор сценария: http://.../
Регистрация:
IP-адрес:
Имя пользователя:
Имя класса: vB_Database_MySQLi
MySQL версии:
-->

Теперь, я никогда не испытывал этого раньше, и мне интересно, если это было совпадением, что это было вокруг обновления VB кэша запланированных задач.

Я проверил сегодня утром, и все было нормально, так что это не повторить сегодня.

Сервер, казалось, не следует подчеркнуть, так как я был еще один форум на одном сервере без vbet, что работал нормально во время простоя из моих vbet форуме.

Глядя на serverlog, там же, похоже, некоторые бот деятельности, но не намного активности пользователей. Ботов, казалось, получить ОК 200 - но обычные пользователи получили dberror. Также странно записей в лог-файл на сервер, кажется, не хронологическом порядке ...

Немного puzzele ... возможно, вы можете сказать мне, если включает / class_core.php на линии 1138 участвует в обновлении кэша? Или, возможно, некоторые из вас знает, как устранить эту?

[vBET]

vBET не создает новые соединения - она может восстановить соединение, но это сделано только в случае фактической теряется (в случае, если перевод приходит слишком поздно, от Google). И это соединение осуществляется на $ VBulletin-> DB-> подключить так VBulletin сделаны все необходимые очистки в конце.

Так что в этот момент мы считаем, что проблема находится где-то еще.

class_core.php не наш файл, и он не использует непосредственно vBET кэш - но если этот файл отвечает за выполнение запланированной задачи, то она также будет выполнять кэш поляне.

[vBET]

И еще один момент. Если вы пишете о очистка кэша vBET, то, пожалуйста, черт, сколько у вас данных в кэше. Если это действительно большие суммы, то пожалуйста, измените ваш кэш очистки стратегии.
vBET не создает дополнительных соединений, но если очистка занимает слишком много времени, то другие клиенты ждут и новые соединения создаются VB для новых клиентов, которые плохо ждать. Именно поэтому мы добавим несколько стратегию очистки. Для действительно большого количества данных, пожалуйста, используйте последнюю стратегию.

Пожалуйста, обратите внимание, что этот вопрос будет сведено к минимуму в 3.3.0, так как мы разделят кэш таблиц для каждого языка, поэтому индексы будут 52 раз меньше и очистка будет гораздо быстрее - удаление данных быстро, но обновление больших индексов не требуется. Так что в этот момент пожалуйста, рассмотреть использование других стратегий очистки, которые лучше подходят для больших индексов:)

[krisp]

Случилось снова с 04-05 - все домены вниз слишком много подключений. Я думаю, вы правы. Форум занят очистки кэша и поисковых роботов являются подделка одного запроса в секунду. Я мог видеть serverload был чрезвычайно высок. Сейчас это очень низкий снова. vbet дБ около 1,1 Гб

После перехода на «Удалить кэш данных один раз для кэша TTL интервал".

Звук очень хороший, действительно 330 решает эту проблему!