gormod o gamgymeriadau db gysylltiadau yn ystod cache diweddaru

[krisp]

Y noson arall yr wyf yn digwydd bod yn effro ychydig ar ôl 4 yn y bore, lle y fforwm yn sydyn i lawr at ei debyg 20 munud:


Gwall Cronfa Ddata yn vBulletin:

mysqli_real_connect () [<a href='function.mysqli-real-connect'> function.mysqli-go-gysylltu </ a>]: (08004/1040): Mae gormod o gysylltiadau
/ Var / www / vhosts / ... / httpdocs / cynnwys / class_core.php ar-lein 1138

Gwall MySQL:
Rhif Gwall:
Dyddiad Cais: Dydd Mawrth 15 Rhagfyr, 2009 @ 04:28:00
Gwall Dyddiad: Dydd Mawrth 15 Rhagfyr, 2009 @ 04:28:00
Sgript: http://.../
Cyfeiriwr:
Cyfeiriad IP:
Enw defnyddiwr:
Classname: vB_Database_MySQLi
Fersiwn MySQL:
-->

Yn awr erioed, yr wyf yn profi hyn o'r blaen, ac yr wyf yn meddwl, os oedd yn gyd-ddigwyddiad, mai hwn oedd o amgylch y diweddariad cache VB mewn tasgau a drefnwyd.

Rwy'n wirio y bore yma ac roedd popeth yn iawn, felly nid oedd yn ailadrodd heddiw.

Mae'r gweinydd yn ymddangos beidio â bod yn straen, gan fy mod wedi fforwm arall ar yr un gweinyddwr heb vbet, a oedd yn rhedeg iawn yn ystod yr amser di-fynd o fy fforwm vbet.

O edrych ar y serverlog, mae oedd yn ymddangos bod rhywfaint o weithgarwch bot, ond mae gweithgarwch defnyddwyr dim llawer. Mae'r bots yn ymddangos i gael iawn 200 - ond defnyddwyr arferol cael dberror. Hefyd yn rhyfeddol y cofnodion yn y logfile gweinydd ymddangos nad i'w didoli gronolegol ...

Mae dipyn o puzzele ... efallai y gallwch chi ddweud wrtha i os yn cynnwys / class_core.php ar-lein 1138 yn ymwneud â diweddaru'r cache? Neu efallai bod rhai ohonoch chi syniad sut i ddatrys hyn?

[vBET]

Nid yw vBET yn creu cysylltiadau newydd - gall reestablish cysylltiad ond mae hyn yn cael ei wneud dim ond os yw un gwirioneddol ar goll (yn achos os cyfieithiadau dod yn rhy hwyr gan Google). Ac y cyswllt hwn yn cael ei wneud gan $ vBulletin-> db-> gysylltu er mwyn gwneud yr holl vBulletin clirio'r angenrheidiol ar y diwedd.

Felly, ar hyn o bryd rydym yn credu bod y mater yn rhywle arall.

Nid yw ein class_core.php ffeil ac nid yw'n defnyddio storfa dros dro yn uniongyrchol vBET - ond os y ffeil yn gyfrifol am gyflawni tasg a drefnwyd, yna bydd hefyd yn gweithredu clirio storfa.

[vBET]

Un peth arall. Os ydych yn ysgrifennu am glirio cache vBET, yna cysylltwch Heck faint o ddata sydd gennych yn y cache. Os yw'n swm mawr iawn, yna newid eich cache strategaeth clirio.
Nid yw vBET yn creu cysylltiadau ychwanegol, ond os clirio cymryd gormod o amser, yna cleientiaid eraill yn aros a chysylltiadau newydd yn cael eu creu gan VB ar gyfer cleientiaid newydd, a oedd yn aros yn sâl. dyma pam rydym yn ychwanegu nifer o strategaeth clirio. Ar gyfer nifer fawr iawn o ddata defnyddiwch strategaeth diwethaf.

Sylwer y bydd y mater hwn ei leihau yn 3.3.0 gan y byddwn yn rhannu tablau cache ar gyfer pob iaith, felly bydd eich mynegeion yn 52 gwaith yn llai a bydd yn clirio yn llawer cyflymach - dileu data yn gyflym, ond diweddaru mynegeion mawr nid oes angen. Felly, ar hyn o bryd os gwelwch yn dda yn ystyried y defnydd o strategaeth clirio eraill, sy'n well ar gyfer mynegeion mawr:)

[krisp]

Happend eto 04-05 - pob parth i lawr gyda chysylltiadau gormod. Rwy'n credu eich bod yn iawn. Fforwm yn brysur yn clirio storfa dros dro a botiau chwilio yn ymyrryd â un cais yr eiliad. Roeddwn i'n gallu gweld serverload yn uchel dros ben. Nawr, mae'n isel iawn unwaith eto. vbet db tua 1.1 Prydain Fawr

Rwyf wedi newid i "Dileu holl ddata cache unwaith ar gyfer cyfnod cache TTL".

Mae'n swnio'n dda iawn yn wir 330 ymdrin â'r broblem!