server pe care se încadrează

[Valdo]

când n-am instalat traducător am o altă problemă: ori de câte ori eu fac parte din operaţiunea planificată de curăţare zilnică de 0:10, am picătură server. Aseară am chiar au stagnat timp de 8 ore, asa ca acum am avut pentru a dezactiva pentru a evita acest lucru sa se intample din nou. Cum pot rezolva? Mulţumiri

[vBET]

Are încă se întâmplă atunci când aţi dezactivat programat de activitate "vB Enterprise Traducator (Cache TTL)". Cât de mari sunt tabele cache? Atunci când intră serverul se întâmplă nu aveţi orice erori în fişierele jurnal? Aţi încercat să utilizaţi vBET parametrul "golirea memoriei cache timelap"? Ce strategie de compensare sunt utilizaţi chiar acum?

[Valdo]

Dacă nu mă înşel, există mai multe mese cache, câte unul pentru fiecare limbă. Totală a tuturor backup de date pe care am făcut pe 2 martie a fost 877 mb. Dacă facem o medie de tabele cache, va fi de 5 mb fiecare, variind de la un maxim de 14 MB de chinezi si japonezi, pentru un minim de 2 MB pentru Thai. Script care elimina traducerile vechi de frunze la 3.30. Privind la optiunile traducerile vechi vBET ar trebui eliminat la fiecare 15 zile, toate opţiunile sunt stabilite în timp ce ai pus la instalare. Dacă vrei să spui de parametru timelap, cache strategie de compensare, această eliminare este setat la Normal.

[vBET]

Tu nu au răspuns cele mai importante informaţii - nu este încă blochează atunci când sarcina planificată este dezactivat? În primul rând avem nevoie pentru a determina nu vBET este adevarata problema aici.

În text eliminat normale cache vechi se elimină zilnic. Dacă doriţi cel mai rapid mod de text eliminat - strategia de la ultima utilizare - aceasta va elimina cache-ul întreg, o dată pe 15 zile. Acesta acţionează imediat şi de a folosi resursele serverului, practic, zero. Dar trebuie să umple cache-ul intreg, din nou, nu doar cel vechi.

Aţi încercat să utilizaţi "Cache de compensare timelap" opţiune?

[Valdo]

serverul prăbuşit din nou in seara asta: am dezactivat curăţarea 0:10 la 3:30, dar a scăzut când a părăsit BB Enterprise Traducator (Cache TTL)

[Valdo]

M-am uitat, valoarea la care vă referiţi este setat la 1. Pentru a fi precis, este aceasta:

Cache de compensare timelap
Câte secunde să aştepte între tabele ştergerea memoriei cache. Setaţi 0 pentru a dezactiva. Vă rugăm să reţineţi faptul că vBET are peste 150 de mese pentru a şterge memoria cache - setarea această valoare prea mare poate cauza că serviciile de compensare, care începe pe timp de noapte va continua chiar şi în orele de zi. De asemenea, vă rugăm să nu o setati mai mare ca conexiunea MySQL este în aşteptare, fără utilizarea (setare mysql: wait_timeout) - în caz contrar aceasta va provoca "server MySQL a dispărut de eroare" şi de compensare nu va fi terminat.

[vBET]

serverul prăbuşit din nou in seara asta: am dezactivat curăţarea 0:10 la 3:30, dar a scăzut când a părăsit BB Enterprise Traducator (Cache TTL)

Ne pare rău - Eu nu primesc un singur lucru - ai de compensare de două ori pe zi? Va rugam sa dezactivati sarcină de compensare şi spune server-ul dvs. nu se va prăbuşi atunci când este dezactivată de compensare (indiferent la care oră - dezactivaţi-l complet). Dacă server-ul nu se va prăbuşi atunci când golirea memoriei cache este dezactivat atunci înseamnă că vBET este vinovat. Dacă încă crasches apoi altceva cauzeaza acest lucru.

Dacă este vinovat, atunci vBET aveţi mai multe opţiuni pentru a ton de sus:
- Seta valoare mai mare la "Cache de compensare timelap" - acest lucru va da mai mult timp şi CPU pentru alte fire de compensare între fiecare tabel cache. Vă sugerez să faceţi acest lucru în primul rând
- Set inferior "Time To Live Cache (TTL)" -, atunci tabele vor fi mai mici astfel de compensare va fi mai puţin costisitoare.
- Joaca-te cu "strategia de compensare Cache" - ultima va rezolva problema dvs. în proporţie de 100% - este conceput pentru cache-ul foarte mare şi se va şterge memoria cache, chiar uriaşe imediat, deoarece indeparteaza doar tabele întregi cache si creeaza-l din nou. Dar şterge memoria cache, o dată pe întreaga perioadă Cache TTL, astfel cache-ul trebuie să fie umplut de la început. Acesta este ultimul lucru pe care am sfătui să utilizaţi, aşa că dacă nimic altceva nu este de lucru, acest lucru va fi, în proporţie de 100%. Se adaugă doar pentru astfel de situaţii:)

[Valdo]

Am încercat prima soluţie aţi propus, setând valoarea la 3. Gazdă a spus că a existat o scădere a sarcinii, dar merge mai departe în a doua zi este crescut. Reducerea duratei, în zile, cache-ul, problema ar putea fi rezolvată? Server este sub sarcină, sau prin golirea memoriei cache a traducerilor încă nu s-au salvat în memoria cache?

[vBET]

OK deci urmatorii pasi care te pot ajuta:
1. Creşterea cache TTL - mai puţine date vor fi şterse de fiecare dată
2. Schimbarea strategiei de compensare pentru: "text eliminat rapid locale cu tabele optimizarea" - vă rugăm să reţineţi că această opţiune poate fi mai rău în cazul în care cache-ul nu este destul de mare. Pentru cache mare este mai bine ca normală.
3. Avertisment: puteţi alege "Quick text eliminat locale cu tabele optimiza" şi editaţi fişierul / include / vbenterprisetranslator_functions.php de comentariul 3 linii de cod care include TABLE OPTIMIZAREA LOCAL. Cu această modificare va şterge numai datele vechi într-un mod foarte rapid, dar indexurile dvs. nu va fi reconstrui şi va creşte, aşa că va trebui să execute comentat interogare de manual, o dată pe timp. În cazul în care va lucra pentru tine, atunci putem să-l pună în aplicare ca fiind unul dintre strategii susţinute - în cazul în care este rapid de curăţare, fără a reconstrui indexurile şi reconstrui în sine pot fi făcute de către altă sarcină de exemplu: o data pe saptamana. Deci, dacă ne spuneţi că este de lucru pentru tine ne vom adăuga în special pentru tine:)