serveris, kas ietilpst

[Valdo]

jo es uzinstalēju tulkotājs Man ir cita problēma: kad es esmu daļa no plānotās darbības tīrīšanas Daily 00:10, es piliens serveri. Pēdējā nakts Es pat apstājušās uz 8 stundām, tāpēc tagad man bija atslēgt šo lai izvairītos, ka atkārtošanos. Kā es varu salabot? Paldies

[vBET]

Vai tā joprojām notiek, ja jūs invalīdiem paredzēts uzdevums "vB Enterprise Translator (Cache TTL)". Cik liela ir jūsu cache tabulas? Kad serveris kritums notiek, jums ir kādas kļūdas, log failus? Vai jūs mēģināt izmantot vBET parametru "Cache klīringa timelap"? Kādas norēķinu stratēģiju, jūs lietojat tiesības tagad?

[Valdo]

Ja es nemaldos ir vairāki cache tabulas, vienu katrai valodai. Visu datu bāzē backups kopā, ka es 2.martā bija 877 mb. Ja mēs veiksim vidēji cache tabulas, būs 5 mb katrs, sākot no ne vairāk kā 14 MB ķīniešu un japāņu valodā, vismaz uz 2 MB taju. Skriptu, kas noņem veco tulkojumi lapām 3,30. Aplūkojot iespējas vbet vecā tulkojumi jāizņem ik pēc 15 dienām, varianti, kā jūs nodot jums uzstādīšana. Ja jūs saprotat ar timelap parametrs, cache klīringa stratēģiju, ar šo dzēšana ir iestatīts uz Normāls.

[vBET]

Jums nav atbildēt uz vissvarīgāko informāciju - vai tas joprojām atteici, kad paredzēts uzdevums ir invalīds? Vispirms mums ir nepieciešams, lai noteiktu, tas vBET ir īstais jautājums šeit.

Parastos dzēšanu vecs cache svītro dienā. Ja vēlaties, ātrākais veids, dzēšana - lietošana pēdējā stratēģija - tas viens būs noņemt visu cache reizi 15 dienās. Tas darbojas nekavējoties un izmantot praktiski 0 servera resursus. Bet jums ir aizpildīt visu cache atkal, ne tikai veco.

Vai esat mēģinājuši to izmantot "Cache mijieskaita timelap" variantu?

[Valdo]

serveris crashed atkal šovakar: Es invalīdu tīrīšana 00:10, bet nokrita pie 3:30, kad viņš atstājis BB Enterprise Translator (Cache TTL)

[Valdo]

Es paskatījos, vērtība, kas jūs uz ir iestatīts uz 1. Lai būtu precīzs, tas ir:

Cache klīringa timelap
Cik sekundes jāgaida starp kešatmiņas tabulām. Set 0 atspējot. Lūdzu, ņemiet vērā, ka vBET ir vairāk nekā 150 cache tabulas skaidrs - nosakot šo vērtību pārāk augsta, var izraisīt, ka klīringa kas sākas naktī, turpināsies pat stundas dienā. Tāpat, lūdzu, nav tā būtu augstāka, ka jūsu MySQL savienojums gaida bez pielietojumam (mysql iestatījums: wait_timeout) - citādi tas radīs 'MySQL serveris ir pazudis kļūda ", un mijieskaita netiks pabeigts.

[vBET]

serveris crashed atkal šovakar: Es invalīdu tīrīšana 00:10, bet nokrita pie 3:30, kad viņš atstājis BB Enterprise Translator (Cache TTL)

Sorry - man nav get viena lieta - ja Jums ir ieskaita divas reizes dienā? Lūdzu, deaktivizējiet klīringa uzdevums, un pateikt vai jūsu serveris crash, kad klīringa ir invalīdi (vienalga, kurā stundā - atspējot pilnībā). Ja serveris nav crash, kad cache ieskaita ir izslēgts, tad tas nozīmē, ka vBET ir vainīgs. Ja vēl crasches tad vēl kaut ko izraisa šo.

Ja vBET ir vainīgs, tad jums ir vairākas iespējas, lai klausītos to uz augšu:
- Noteikt lielāku vērtību "Cache klīringa timelap" - tas dos laika un vairāk CPU citi pavedieni starp mijieskaita katra cache tabulas. Es iesaku to darīt pirmajā vietā
- Noteikt zemākus "Cache Time To Live (TTL)" - tad jūsu tabulās būs mazāka, tāpēc mijieskaita būs lētāks.
- Spēlē ar "Cache klīringa stratēģija" - pēdējais būs atrisināt jūsu problēmu 100% - tas ir paredzēts ļoti liels cache, un būs skaidrs pat lielu cache nekavējoties, jo tā tikai novērš visu cache tabulas un to rada no jauna. Bet tas izdzēš visu cache reizi Cache TTL laiku, lai cache ir jāaizpilda no jauna. Šī ir pēdējā lieta, ko es ieteikt izmantot, tāpēc, ja nekas cits darbojas tas būs 100%. Tas ir pievienots tikai šādās situācijās:)

[Valdo]

Mēs mēģinājām pirmo risinājumu, kuru Jūs piedāvājāt, nosakot vērtību 3. Uzņēmēja sacīja, ka pastāv slodzes samazināšanās, bet iet uz priekšu diena ir palielinājies. Samazinot ilgumu dienās, cache, problēmu varētu atrisināt? Serveris ir noslogots, vai kešatmiņas tulkojumu vēl nav saglabāti cache?

[vBET]

Labi, lai nākamie soļi, kas var palīdzēt Jums:
1. Palielināt cache TTL - mazāk dati tiks nodzēsts
2. Izmaiņas klīringa stratēģiju: "Quick vietējās svītrots ar optimizētu galdi" - lūdzu, ņemiet vērā, ka minētā izvēle var būt vissliktākais, ja jūsu cache nav tik liels. Lieliem kešatmiņas ir labāk, ka normāls.
3. EKSPERIMENTĀLS: jūs varat izvēlēties "Quick vietējo svītrots ar optimizētu galdi" un rediģēt failu / includes / vbenterprisetranslator_functions.php ko pirms 3 rindiņas kodu, kas ietver optimizētu LOCAL TABLE. Ar šo grozījumu tas noņems tikai veciem datiem ļoti ātru veidu, bet jūsu rādītāji nebūs atjaunot un pieaugs, tāpēc jums nāksies izpildīt komentārus vaicājumu manuāli reizi brītiņa. Ja tas darbosies, lai jūs, tad mēs varam īstenot to kā vienu no atbalsta stratēģiju - kur ir ātra tīrīšana bez indeksi atjaunot un atjaunot sevi var veikt citus uzdevumus, darbības ti, vienu nedēļu. Tātad, ja jūs mums saka, ka tas strādā priekš jums, mēs pievienosim tieši jums:)