servidor que cai

[Valdo]

desde que eu tenho instalado o tradutor eu tenho outro problema: sempre que eu sou parte da operação planejada de limpeza da 00:10 Diariamente, eu deixar cair o servidor. Na noite passada eu mesmo parado por oito horas, então agora eu tive que desativar isso para evitar que aconteça novamente.
Como posso corrigir?
Obrigado

[vBET]

Será que ela ainda acontece quando você desativou tarefa agendada "vB Empresa Tradutor (Cache TTL)". Quão grande são as suas tabelas de cache? Ao cair do servidor acontece você tem quaisquer erros nos arquivos de log? Você tentar usar vBET parâmetro "Cache clearing timelap"? Qual a estratégia de compensação você está usando agora?

[Valdo]

Se não me engano existem várias tabelas de cache, um para cada idioma. O total de todos os backups de banco de dados que eu fiz em 2 de março foi 877 mb. Se fizermos uma média de tabelas cache, será de 5 mb cada, que vão desde um máximo de 14 mb de chineses e japoneses, por um mínimo de 2 MB para o tailandês. O script que remove as traduções antigas sai às 3.30. Olhando para as traduções opções vbet antigos podem ser removidos a cada 15 dias, as opções são definidas como você colocá-lo na instalação.
Se você quer dizer com parâmetro timelap estratégia de compensação, cache, esta eliminação é definido como Normal.

[vBET]

Você não respondeu informações mais importantes - ele ainda trava quando tarefa agendada é deficiente? Primeiro, precisamos determinar se vBET é verdadeira questão aqui.

Na exclusão normais de cache antigo é deletado é diária. Se você quiser maneira mais rápida de exclusão - estratégia último uso - este irá remover cache de toda uma vez por 15 dias. Ele funciona imediata e uso praticamente 0 recursos do servidor. Mas você tem que preencher de cache inteiro novamente, não apenas um velho.

Você tentou usar "Cache clearing timelap" opção?

[Valdo]

o servidor caiu outra vez esta noite: eu desativei a limpeza das 0:10 às 3:30, mas caiu quando ele saiu da empresa BB Translator (Cache TTL)

[Valdo]

Eu olhei, o valor a que se refere é definida como 1. Para ser preciso, é esta:

Limpeza de cache timelap
Quantos segundos de espera entre as tabelas de cache de compensação. Set 0 para desabilitar. Por favor note que vBET tem mais de 150 tabelas de cache para limpar - definir esse valor muito alto pode causar que o desmatamento, que começa à noite continuará, mesmo em horas por dia. Também por favor, não configure isso mais que sua conexão MySQL está esperando, sem uso (mysql configuração: wait_timeout) - caso contrário, fará com que "servidor MySQL foi embora de erro 'e clearing não será concluída.

[vBET]

o servidor caiu outra vez esta noite: eu desativei a limpeza das 0:10 às 3:30, mas caiu quando ele saiu da empresa BB Translator (Cache TTL)

Desculpe - eu não entendo uma coisa - você tem desmatamento duas vezes por dia? Desative tarefa de compensação e dizer que o seu servidor irá falhar quando clearing está desativada (não importa em que hora - desativá-lo completamente). Se o servidor não vai falhar quando limpar o cache é desativado, então isso significa que vBET é culpado. Se ainda crasches então algo mais faz isso.

Se vBET é culpado, então você tem várias opções para sintonizar-se:
- Conjunto de maior valor para "Cache timelap clearing" - isto dará tempo e mais CPU para outros segmentos entre clearing cada tabela cache. Sugiro fazer isso em primeiro lugar
- Conjunto "Time Cache To Live (TTL)" inferiores - então suas tabelas serão menores para limpeza será menos caro.
- Jogue com "estratégia de limpar o cache" - o último vai resolver o seu problema em 100% - ele é projetado para o cache muito grande e clara, mesmo cache enorme imediatamente, porque ele só remove as tabelas de cache todo e cria-lo novamente. Mas ele limpa todo cache de uma vez por período de Cache TTL, de modo de cache têm de ser preenchidos desde o início. Esta é última coisa que eu aconselho a usar, por isso, se nada mais está trabalhando isso em 100%. Ele é adicionado apenas para tais situações

[Valdo]

Nós tentamos a primeira solução que propôs, definindo o valor para 3. O anfitrião disse que houve uma diminuição da carga, mas daqui para frente no dia é aumentada. Diminuindo a duração, em dias, o cache, o problema poderia ser resolvido? O servidor está sob carga, ou limpando o cache das traduções ainda não salvas no cache?

[vBET]

OK para os próximos passos que podem ajudá-lo:
1. Aumento de cache TTL - menos dados serão apagados a cada vez
2. Mudança de estratégia de compensação para: "exclusão rápida locais com mesas otimizar" - por favor, note que esta opção pode ser pior se o seu cache não é suficientemente grande. Para caches grandes é melhor que normal.
3. EXPERIMENTAL: você pode escolher "eliminação rápida locais com mesas otimizar" e editar o arquivo / Includes / vbenterprisetranslator_functions.php pelo comentário de 3 linhas de código que inclui OPTIMIZE TABLE LOCAL. Com essa modificação ele irá remover somente os dados de idade de maneira muito rápida, mas seus índices não será reconstruir e vai crescer, assim você terá de executar comentou consulta manualmente de vez em quando. Se ele vai trabalhar para você, então podemos implementá-lo como um de estratégia apoiada - em que é rápido de limpeza sem índices reconstruir e reconstruir-se pode ser feita por outra tarefa em execução ou seja, um por semana. Então, se você nos dizer que está funcionando para você, vamos adicioná-lo especialmente para você