PDA

View Full Version: Opgelost te veel aansluitingen db fout tijdens cache-update



krisp
17-12-09, 01:17
De andere nacht heb ik toevallig wakker zijn even na vier in de ochtend, waar het forum plotseling naar beneden was voor zo'n 20 min:


Database error in vBulletin:

mysqli_real_connect () [<a href='function.mysqli-real-connect'> function.mysqli-real-connect </ a>]: (08004/1040): Te veel verbindingen
/ Var / www / vhosts / ... / httpdocs / includes / class_core.php on line 1138

MySQL Error:
Foutnummer:
Aanvraag Datum: Dinsdag de 15e december 2009 @ 04:28:00
Fout Datum: dinsdag de 15 december 2009 @ 04:28:00
Script: http://.../
Referrer:
IP-adres:
Gebruikersnaam:
ClassName: vB_Database_MySQLi
MySQL versie:
-->

Nu, ik heb nooit meegemaakt dit nog, en ik ben benieuwd, als het een toeval, dat dit rond de vb cache update in geplande taken.

Ik keek deze morgen en alles was ok, dus het duurde niet herhalen vandaag.

De server bleek niet te worden benadrukt, want ik had een ander forum op dezelfde server zonder vbet, dat was prima lopen tijdens de downtime van mijn vbet forum.

Kijkend naar de serverlog, deed lijken er wat bot activiteit, maar niet veel activiteiten van gebruikers. De bots leek OK 200 te krijgen - maar gewone gebruikers kregen dberror. Ook vreemd de records in de server logfile lijkt niet te zijn chronologisch ...

Een beetje een puzzele ... misschien kunt u mij vertellen of includes / class_core.php on line 1138 betrokken is bij het updaten van de cache? Of misschien sommige van jullie hebben een idee hoe dit oplossen?

vBET
17-12-09, 01:31
vBET creëert geen nieuwe verbindingen - het kan verbinding te herstellen, maar dit is slechts indien de werkelijke een verloren (in het geval als vertalingen te laat komt van Google). En deze verbinding wordt gemaakt door $ vBulletin-> db-> zo aansluiten vBulletin alle benodigde opruimen aan het eind.

Dus op dit moment denken we dat het probleem ergens anders.

class_core.php is niet ons bestand en het maakt geen gebruik van direct vBET cache - maar als dit bestand is verantwoordelijk voor de uitvoering van de geplande taak, dan zal het ook uitvoeren cache clearing.

vBET
17-12-09, 01:54
Nog een ding. Als u schrijft over vBET cache clearing, dan kunt u heck hoeveel data je hebt in cache. Als het echt groot bedrag, dan kunt u veranderen je cache clearing strategie.
vBET creëert geen extra verbindingen, maar als clearing duurt te lang, dan andere klanten wachten en nieuwe verbindingen worden gemaakt door VB voor nieuwe klanten, die ziek te wachten. dit is waarom voegen we een aantal clearing strategie. Voor echt grote hoeveelheid gegevens, gebruik dan vorig strategie.

Houdt u er rekening mee dat dit probleem wordt geminimaliseerd in 3.3.0, omdat we zullen cache tabellen split voor elke taal, zodat je indexen zullen worden 52 keer kleiner en clearing zal veel sneller - wissen van gegevens snel is, maar het bijwerken van grote indexen niet nodig. Dus gelieve op dit moment te overwegen het gebruik van andere clearing strategie, die beter zijn voor grote indexen:)

krisp
17-12-09, 05:22
Gebeurde weer 04-05 - alle domeinen beneden met teveel verbindingen. Ik denk dat je gelijk hebt. Forum is bezig met het wissen van het cachegeheugen en zoek bots zijn geknoei met een aanvraag per seconde. Ik kon zien dat serverload was extreem hoog. Nu is het weer erg laag. vbet db ca. 1,1 GB

Ik heb de overstap naar "een keer Verwijder alle gegevens in de cache voor cache TTL interval".

Klinkt erg goed inderdaad 330 lost dit probleem!

Automatic Translations (Powered by Google, Microsoft®, Yandex, SDL Language Cloud, IBM Watson and Apertium):
AfrikaansAlbanianArabicBelarusianBulgarianCatalanChineseCroatianCzechDanishDutchEnglishEstonianFilipinoFinnishFrenchGalicianGermanGreekHaitian CreoleHebrewHindiHungarianIcelandicIndonesianIrishItalianJapaneseKoreanLatvianLithuanianMacedonianMalayMalteseNorwegianPersianPolishPortugueseRomanianRussianSerbianSlovakSlovenianSpanishSwahiliSwedishTaiwaneseThaiTurkishUkrainianVietnameseWelshYiddish
Translated to other languages thanks to vBET Translator 4.10.1