Занадта шмат падлучэння да БД памылка падчас абнаўлення кэша

[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 @ 04: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 вырашае гэтую праблему!