Túl sok kapcsolat db hiba a gyorsítótár frissítése

[krisp]

A másik este történt, hogy ébren egy kis 4-e után reggel, amikor a fórum hirtelen volt, le, mint 20 perc:


Adatbázis hiba vBulletin:

mysqli_real_connect () [<a href='function.mysqli-real-connect'> function.mysqli valós-connect </ a>]: (08004/1040): Túl sok kapcsolat
/ Var / www / vhostokat / ... / httpdocs / includes / class_core.php on line 1138

MySQL Hiba:
Hiba száma:
Kérés Dátum: kedd 15 december, 2009 @ 04:28:00
Hiba Dátum: kedd, december 15, 2009 @ 04:28:00
Script: http://.../
Referrer:
IP cím:
Felhasználónév:
Besorolása: vB_Database_MySQLi
MySQL verzió:
-->

Most soha nem tapasztalt ilyet, és én vagyok kíváncsi, ha ez véletlen egybeesés, hogy ez az egész vb cache frissítés ütemezett feladatok.

Megnéztem ma reggel, és minden rendben volt, így nem ismételjük meg ma.

A szerver úgy tűnt, hogy nem kell hangsúlyozni, mert volt egy másik fórumon ugyanazon a szerveren nélkül vBET, futó jó ideje alatt a leállás az én vBET fórum.

Ami a serverlog, ott nem úgy tűnik, hogy valami bot tevékenység, de nem sokkal a felhasználó tevékenységét. A bot úgy tűnt, hogy OK 200 -, de a normál felhasználók kapott dberror. Szintén furcsa a rekordokat a szerver logfile úgy tűnik, hogy nem lehet válogatni időrendben ...

Egy kicsit a puzzele ... talán meg tudja mondani nekem, ha includes / class_core.php on line 1138 részt vesz a frissítése a gyorsítótár? Vagy talán néhány van egy ötlete, hogyan háríthatja el ezt?

[vBET]

vBET nem teremt új kapcsolatokat - képes helyreállítani kapcsolatot, de ez csak ha a tényleges egyik elveszett (abban az esetben, ha a fordítás túl későn érkezik a Google-tól). És ez a kapcsolat által $ vBulletin-> db-> csatlakozik, így vBulletin tett minden szükséges elszámolási végén.

Tehát ebben a pillanatban úgy gondoljuk, hogy a probléma valahol máshol.

class_core.php nem a mi fájlt, és nem használja közvetlenül vBET cache - de ha ez a fájl teljesítéséért felelős ütemezett feladat, akkor is végrehajtja cache törlése.

[vBET]

Még egy dolog. Ha írt vBET cache tisztáson, akkor kérjük, fene, hogy hány adat van a cache. Ha ez nagyon nagy összeg, akkor kérjük, változtassa meg a cache-elszámolási stratégia.
vBET nem hoz létre újabb kapcsolat, de ha az elszámolási túl sokáig tart, akkor a többi ügyfél várja, és új kapcsolatokat hoznak létre a BB új ügyfelek, ami rossz várni. Ezért hozzá több elszámolási stratégia. Az igazán nagy mennyiségű adatot használja utolsó stratégia.

Kérjük, vegye figyelembe, hogy ezt a kérdést a lehető legkisebbre csökkentik 3.3.0 hiszen megosztja cache táblákat minden nyelv, így a mutatók is 52-szer kisebb és elszámolási sokkal gyorsabb lesz - elhagyja az adatok gyors, de frissítését nagy indexek nem szükséges. Tehát ebben a pillanatban kérjük, fontolja meg használat egyéb elszámolási stratégia, amely jobban a nagy indexek:)

[krisp]

Happend ismét 04-05 - minden területen le túl sok kapcsolat. Azt hiszem, igazad van. Fórum foglalt a gyorsítótár törlése és keresőrobotok a beavatkozással egy kérés másodpercenként. Láttam serverload rendkívül magas. Most nagyon alacsony újra. vBET db kb 1,1 GB

Én váltott "Delete all cache adatot egyszer cache TTL intervallum."

Hangok nagyon jó sőt 330 címet erre a problémára!