server che cade

[Valdo]

da quando mi hai installato il translator ho anche un altro problema: ogni volta che mi parte l'operazione pianificata di Pulizia Giornaliera alle 0:10, mi cade il server. Questa notte addirittura mi è andato in stallo per 8 ore, quindi ora ho dovuto disabilitare questa operazione per evitare che accada di nuovo.
Come posso risolvere?
Grazie

[vBET]

Non succede ancora quando è stato disattivato operazione pianificata "VB Enterprise Traduttrice (Cache TTL)". Quanto sono grandi le tabelle di cache? Quando caduta del server avviene avete eventuali errori nei file di log? Hai provato ad utilizzare vBET parametro "Cache timelap compensazione"? Quale strategia di compensazione stai usando in questo momento?

[Valdo]

Se non sbaglio ci sono diverse tabelle di cache, una per ogni lingua. Il totale del backup di tutto il database che ho fatto il 2 marzo era di 877 mb. Se dobbiamo fare una media delle tabelle di cache, saranno 5 mb l'una, si va da un massimo di 14 mb del cinese e giapponese, ad un minimo di 2 mb per il thailandese. Lo script che rimuove le traduzioni vecchie parte alle ore 3.30. Guardando le opzioni di vbet le traduzioni vecchie dovrebbero essere eliminate ogni 15 giorni, le opzioni sono impostate come le hai messe tu al momento ****'installazione.
Se intendi per parametro timelap, Cache clearing strategy, questa è impostata a Normal deletion.

[vBET]

Non hai risposto informazioni più importanti - non si blocca ancora, quando l'operazione pianificata è disabilitato? Per prima cosa dobbiamo determinare vBET non è vero problema qui.

La cancellazione della cache normale vecchio è cancellato tutti i giorni. Se volete modo più veloce di cancellazione - strategia ultimo uso - questo rimuoverà la cache tutto una volta per 15 giorni. Funziona subito e utilizzare praticamente 0 risorse del server. Ma bisogna riempire la cache di nuovo tutto, non solo quello vecchio.

Hai provato a usare "Cache di compensazione timelap" opzione?

[Valdo]

il server è caduto anche stanotte: ho disattivato la pulitura delle 0:10 ma è caduto alle 3:30 quando è partito vB Enterprise Translator (Cache TTL)

[Valdo]

ho dato un'occhiata, il valore al quale fai riferimento è impostato a 1. Per la precisione è questo:

Cache di compensazione timelap
Quanti secondi di attesa tra le tabelle di cache di compensazione. Impostare 0 per disabilitare. Si prega di notare che vBET ha più di 150 tavoli per cancellare la cache - impostare questo valore troppo alto può causare che la compensazione che parte di notte continuerà anche in ore al giorno. Inoltre si prega di non impostare più alto che la connessione MySQL è in attesa, senza l'utilizzo (impostazione mysql: wait_timeout) - altrimenti si farà 'server MySQL è andato via di errore' e di compensazione non sarà finito.

[vBET]

il server è caduto anche stanotte: ho disattivato la pulitura delle 0:10 ma è caduto alle 3:30 quando è partito vB Enterprise Translator (Cache TTL)

Ci dispiace - non ho ricevuto una cosa - avete radura due volte al giorno? Disattiva il compito di compensazione e dire il vostro server crash quando compensazione è disabilitato (non importa a che ora - disabilitare completamente). Se il server non vada in crash quando svuotare la cache è disabilitata allora significa che vBET è colpevole. Se crasches poi ancora un'altra cosa provoca questo.

Se vBET è colpevole allora si hanno diverse opzioni per sintonizzare in su:
- Set di grande valore su "Cache compensazione timelap" - questo darà il tempo e più CPU per altri thread tra radura ogni tabella cache. Suggerisco di farlo in primo luogo
- Impostare inferiore "Tempo della cache (TTL)" - poi le tabelle saranno più piccoli in modo di compensazione sarà meno costoso.
- Gioca con la "strategia di cache di compensazione" - l'ultimo risolverà il problema in 100% - è stato progettato per la cache di grandi dimensioni e consente di cancellare anche la cache enorme immediatamente, perché elimina solo le tabelle di cache tutto e crea di nuovo. Ma si cancella la cache tutto una volta per ogni periodo di cache TTL, per cui la cache devono essere compilati dall'inizio. Questa è l'ultima cosa vi consiglio di usare, quindi se non altro sta lavorando in questo sarà al 100%. Si aggiunge solo per situazioni di questo tipo

[Valdo]

Abbiamo provato la prima soluzione che hai proposto, impostando il valore a 3. L'hosting dice che c'è stato un calo del carico, ma andando avanti nella giornata è aumentato. Diminuendo la durata, in giorni, della cache, il problema si potrebbe risolvere? Il server è più sotto carico ripulendo la cache o facendo delle traduzioni non ancora salvate in cache?

[vBET]

OK così i prossimi passi che ti può aiutare:
1. Incremento della cache TTL - meno dati saranno cancellati ogni volta
2. Cambia strategia di compensazione a: "cancellazione rapida locale con tavoli ottimizzare" - si ricorda che questa opzione può essere peggiore se la cache non è abbastanza grande. Per cache grande è meglio che normale.
3. SPERIMENTALE: si può scegliere "Quick cancellazione locale con tavoli ottimizzare" e modifica il file / Includes / vbenterprisetranslator_functions.php dal commento 3 linee di codice che comprende OTTIMIZZARE LA TABELLA LOCALE. Con questa modifica verrà rimosso solo i vecchi dati in modo molto veloce, ma gli indici non sarà ricostruire e crescere, in modo da avere per eseguire query manualmente commentato una volta un po '. Se funzionerà per voi allora possiamo attuarla come una delle strategie sostenute - in cui è veloce pulizia senza indici ricostruire e ricostruirsi può essere fatto da compito in esecuzione cioè uno alla settimana. Quindi, se ci dicono che sta lavorando per voi lo aggiungeremo per voi