poslužitelj koji pada

[Valdo]

jer sam instalirao prevoditelj imam još jedan problem: svaki put kad sam dio planirane operacije čišćenja Dnevni 0:10 sam kap poslužitelju. Sinoć sam čak i zastao za 8 sati, pa sad sam morao isključiti tu kako bi se izbjeglo da se ponove. Kako mogu popraviti? Hvala

[vBET]

Da li to još uvijek događa kada osobe s invaliditetom rasporedu zadatak "VB Enterprise Prevoditelj (Cache TTL)." Koliki su predmemorije tablice? Kada se dogodi pad poslužitelja imate bilo kakve pogreške u log datotekama? Jeste li pokušati iskoristiti vBET parametar "timelap Cache obračuna"? Što čišćenje strategije koristite upravo sada?

[Valdo]

Ako nisam u zabludi postoji nekoliko predmemorija stolova, po jedan za svaki jezik. Ukupno sve baze podataka sigurnosne kopije koje sam napravio 2. ožujka bio je 877 MB. Ako napravimo prosjeku cache tablica, će biti 5 mb svaki, od maksimalno 14 MB kineske i japanske, za najmanje 2 MB za tajlandski. Skriptu koja uklanja stari prijevodi ostavlja na 3,30. Gledajući opcije vbet starim prijevodima treba ukloniti svakih 15 dana, opcije su postavili kao što ste stavili na instalaciju. Ako misliš timelap parametar, čišćenje cache memorije strategija, to brisanje je postavljen na Normal.

[vBET]

Niste odgovorili najvažnije informacije - to još uvijek ruši kada je zakazano zadatak je invalid? Prvo moramo utvrditi ne vBET je pravi problem ovdje.

U normalnim brisanje starih cache memorije se briše dnevno. Ako želite najbrži način o brisanju - koristiti posljednja strategija - ovaj će ukloniti cijeli cache memorije jednom po 15 dana. Radi neposrednog i koristiti praktički 0 poslužitelj resursa. Ali morate ispuniti cijeli predmemorije opet, ne samo stari.

Jeste li pokušali koristiti "Cache čišćenje timelap" opciju?

[Valdo]

poslužitelj srušio opet večeras: Ja onemogućen čišćenje 0:10, ali je pao u 3:30 kada je napustio BB Enterprise Prevoditelj (Cache TTL)

[Valdo]

Gledam, vrijednost na koju se odnose je postavljena na 1. Da budemo precizniji, je ovo:

Cache čišćenje timelap
Koliko sekundi čekati između brisanje predmemorije tablica. Postavite 0 do onemogućiti. Imajte na umu da vBET ima više od 150 cachea tablice jasno - postavljanje ove vrijednosti previsoka može izazvati da se kliring koja počinje u noći će se nastaviti čak i na dan sati. Također Vas molimo da ne postaviti više da MySQL je veza na čekanju bez korištenja (MySQL postavka: wait_timeout) - inače to će izazvati 'MySQL poslužitelj je otišao dalje pogreške' i čišćenje neće biti završen.

[vBET]

poslužitelj srušio opet večeras: Ja onemogućen čišćenje 0:10, ali je pao u 3:30 kada je napustio BB Enterprise Prevoditelj (Cache TTL)

Žao nam je - ja ne bi jednu stvar - imate kliring dva puta na dan? Onemogućite čišćenje zadatak i recite ne Vaš server će srušiti kada čišćenje je onemogućen (bez obzira u kojoj sat - to onemogućiti potpuno). Ako poslužitelj ne pada kada predmemorija čistini je onemogućen onda to znači da vBET je kriv. Ako još crasches onda se nešto drugo uzrokuje to.

Ako vBET je kriv onda imate nekoliko opcija da ga podesiti:
- Postaviti veći vrijednost na "Cache čišćenje timelap" - to će vam dati vremena i više CPU za druge teme između brisanje predmemorije svakog stola. Predlažem da to učinite na prvom mjestu
- Postavite donji "Cache Time to live (TTL)" - onda tablicama će biti manji, tako kliring će biti manje skupo.
- Igrajte se s "strategija Cache obračuna" - posljednja će riješiti vaš problem u 100% - to je dizajniran za vrlo velike predmemorije i da će jasno čak i veliki cache memorije odmah, jer se samo uklanja cijeli cache memorije tablice i stvara opet. Ali, to briše cijeli cache memorije jednom Cache TTL razdoblju, tako da predmemorija moraju biti popunjena od početka. To je posljednja stvar koju sam savjetovati koristiti, pa ako ništa drugo radi to će u 100%. To je dodan samo za takve situacije:)

[Valdo]

Pokušali smo prvi rješenje koje su predložili, postavljanje vrijednosti do 3. Domaćin je rekao da je smanjenje opterećenja, ali ide naprijed u dan se povećava. Smanjenje trajanja, u danima, cache, problem bi mogao biti riješen? Poslužitelj je pod opterećenjem, ili brisanje predmemorije prijevoda još nisu spremljene u cache?

[vBET]

U redu, tako sljedeći koraci koje vam mogu pomoći:
1. Povećanje predmemorija TTL - manje će podaci biti izbrisani svaki put
2. Promijeni kliring strategija: "Brzi lokalne brisanje s optimizirati tablice" - imajte na umu da ova opcija može biti najgore ako cache nije dovoljno velika. Za velike zalihe da je bolje da se normalno.
3. EKSPERIMENTALNI: možete odabrati "Brzi lokalne brisanje s optimizirati tablice" i urediti datoteku / includes / vbenterprisetranslator_functions.php za komentar 3 linije koda koji uključuje OPTIMIZIRATI LOKALNIH TABLICA. Uz ovu izmjenu da će ukloniti samo stare podatke u vrlo brz način, ali indeksi neće obnoviti i da će rasti, tako da ćete morati izvršiti komentirao upita ručno jednom neko vrijeme. Ako će raditi za vas onda možemo provesti kao jedan od podržanih strategije - gdje je brzo čišćenje bez indeksa obnoviti i ponovno izgraditi sama može biti drugi zadatak trčanje tj. jedan tjedan. Dakle, ako ste nam reći da je to radi za vas ćemo ga dodati posebno za vas:)