strežnik, ki sodi

[Valdo]

saj sem nameščen prevajalec imam še en problem: ko sem del načrtovane operacije čiščenja Daily 0:10, sem padec strežnika. Sinoči sem celo zastala za 8 ur, tako da zdaj sem moral onemogočiti to, da se prepreči, da bi več ponovile. Kako lahko to popravimo? Thanks

[vBET]

Ali se še vedno zgodi, ko ste onemogočena načrtovano nalogo "vB Enterprise Translator (Cache TTL)". Kako velike so vaše predpomnilnika tabele? Ko se strežnik padec se zgodi, ali imate kakršne koli napake v log datoteke? Ali ste poskušali uporabiti vBET parameter "Cache obračun timelap"? Kateri obračun strategije uporabljate zdaj?

[Valdo]

Če se ne motim obstaja več tabel predpomnilnika, po enega za vsak jezik. Seštevek vseh varnostno kopiranje baze podatkov, da sem se 2. marca je bilo 877 MB. Če naredimo povprečno cache tabel, bo 5 mb vsak, ki segajo od največ 14 MB kitajski in japonski, za najmanj 2 MB za tajske. Skripta, ki odstrani stari prevodi listi na 3,30. Če pogledamo na možnosti stare prevode vBET je treba odstraniti, vsakih 15 dni, so možnosti, kot si si dal na namestitev. Če mislite s parameter timelap, cache strategija kliring, je to črtanje nastavljen na Normal.

[vBET]

Niste odgovorili najpomembnejše informacije - še vedno ne zruši, ko je onemogočen načrtovano opravilo? Najprej moramo ugotoviti, ne vBET je resnično vprašanje tukaj.

V normalnih izbris je stara cache črta na dan. Če želite, najhitrejši način za izbris - uporaba zadnje strategije - bo ta odstranili celoten predpomnilnik enkrat na 15 dni. Deluje takojšnjo in praktično uporabo 0 strežnika virov. Ampak morate izpolniti celotno cache znova, ne le starega.

Ali ste poskušali uporabiti "Cache obračun timelap" možnost?

[Valdo]

strežnik strmoglavilo še enkrat nocoj: Onemogočil sem čiščenje 0:10 pa se je zmanjšala na 3:30, ko je zapustil BB Enterprise Translator (Cache TTL)

[Valdo]

Sem pogledal, je vrednost, na katere se sklicujete nastavljena na 1. Če smo natančni, je to:

Cache obračun timelap
Koliko sekund počakati obračun med tabelami predpomnilnika. Set 0 onemogočiti. Prosimo, upoštevajte, da vBET ima več kot 150 cache tabel, ki jasno - nastavitev ta vrednost previsoka lahko povzroči, da je obračun, ki se začne ponoči se bo še naprej v dan urah. Prav tako prosim, ne so vrednosti, da je vaš MySQL povezavo čaka brez uporabe (mysql nastavitev: wait_timeout) - sicer bo to povzročilo "je MySQL server odšel napake" in obračun ne bo končal.

[vBET]

strežnik strmoglavilo še enkrat nocoj: Onemogočil sem čiščenje 0:10 pa se je zmanjšala na 3:30, ko je zapustil BB Enterprise Translator (Cache TTL)

Oprostite - ne dobim eno stvar - ste dvakrat obračun na dan? Prosimo izključite obračun naloge, in povedal, ali vaša server bo crash, ko je onemogočen kliring (ne glede na to, na kateri uri - jo onemogočite v celoti). Če strežnik ne bo crash, ko je onemogočen predpomnilnik obračun potem to pomeni, da vBET je kriv. Če še vedno crasches potem nekaj drugega povzroči to.

Če vBET je kriv potem imate več možnosti, da ga intonirati:
- Nastavite večji vrednost "Cache obračun timelap" - bo to čas in več CPU za druge teme, med klirinških vsak cache mizo. Predlagam, da to storijo na prvem mestu
- Nastavite nižjo "Cache Time To Live (TTL)" - potem bo vaše mize manjša, tako da bo obračun bo cenejši.
- Igrajte se z "strategijo Cache obračun" - zadnja bo rešil vašo težavo v 100% - to je zasnovana za zelo velike predpomnilnika in bo jasno tudi ogromno cache takoj, saj je samo odstrani celotno tabel predpomnilnik in ga ustvarja še enkrat. Ampak to počisti predpomnilnik celo enkrat v obdobju Cache TTL, tako da cache je treba napolniti od začetka. To je zadnja stvar, ki sem svetoval za uporabo, tako da, če nič drugega, je to delo bo v 100%. Treba je dodati, prav za takšne situacije:)

[Valdo]

Poskušali smo prvo rešitev, ki ste jih predlagal, ki določa vrednost na 3. Gostitelj je dejal, da je prišlo do zmanjšanja bremena, ampak gredo naprej v dan večje. Zmanjševanje trajanje, v dnevih, cache bi lahko, problem je treba rešiti? Strežnik je pod obremenitvijo, ali tako, da počistite predpomnilnik prevodov še niso shranjene v predpomnilnik?

[vBET]

OK, tako naslednji koraki, ki vam lahko pomagajo:
1. Povečanje predpomnilnika TTL - manj podatkov bo očiščeno vsakič
2. Sprememba strategije za obračun: "Quick lokalni izbris z optimizacijo mize" - upoštevajte, da se lahko ta možnost najslabše, če vaš cache ni dovolj velika. Za velike caches je bolje, da normalno.
3. EKSPERIMENTALNI: izbirate lahko "Quick lokalnih izbris z optimizacijo mize" in uredite datoteko / includes / vbenterprisetranslator_functions.php jih comment 3 vrstic kode, ki vključuje OPTIMIZE LOCAL TABLE. S to spremembo bo odpravil samo stare podatke na zelo hiter način, vendar vaši indeksov ne bodo obnovili in bo rasla, tako da boste morali izvesti poizvedbe komentiral ročno enkrat nekaj časa. Če se bo delo za vas, potem ga lahko izvaja kot eden od podprtih strategije -, kjer je hitro čiščenje brez indeksov obnovili in ponovno se jih lahko opravijo druge naloge, ki teče tj. en teden. Torej, če ste nam povedali, da je to delo za vas, bomo dodali še posebej za vas:)