serveur qui tombe

[Valdo]

Depuis que j'ai installé le traducteur, j'ai un autre problème: quand je suis partie de l'opération planifiée de nettoyage de l'0:10 Quotidien, je laisse tomber le serveur. La nuit dernière, j'ai même bloqué pendant 8 heures, alors maintenant je devais désactiver cette option pour éviter que ne se reproduise. Comment puis-je résoudre ce problème? Merci

[vBET]

Est-il arrive toujours quand vous avez désactivé tâche planifiée "vB Enterprise Translator (Cache TTL)". Quelle est la taille de vos tables de cache? Lorsque l'automne arrive le serveur avez-vous des erreurs dans les fichiers log? Avez-vous essayez d'utiliser vBET paramètre "Effacer le cache timelap"? Quelle stratégie de compensation utilisez-vous dès maintenant?

[Valdo]

Si je ne me trompe pas il ya des tables de cache de plusieurs, un pour chaque langue. Le total de toutes les sauvegardes de la base que j'ai faites sur Mars 2 était 877 mb. Si nous faisons une moyenne de tables de cache, sera de 5 Mo chacun, allant d'un maximum de 14 Mo de chinois et japonais, pour un minimum de 2 Mo pour le thaï. Le script qui supprime les anciennes traductions laisse à 3,30. En regardant les options traductions vBET anciens doivent être enlevés tous les 15 jours, les options sont définies comme vous vous mettre à l'installation. Si vous voulez dire par le paramètre timelap, la stratégie de cache de compensation, cette suppression est réglé sur Normal.

[vBET]

Vous n'avez pas répondu informations les plus importantes - il se bloque ne reste lorsque la tâche planifiée est désactivé? Nous devons d'abord déterminer ne vBET est vraie question ici.

Dans suppression normale ancien cache est supprimé quotidienne. Si vous voulez moyen le plus rapide de la suppression - stratégie de la dernière utilisation - celui-ci va supprimer le cache toute une fois par 15 jours. Il fonctionne immédiatement et utiliser pratiquement 0 ressources du serveur. Mais vous devez remplir le cache entier encore, pas seulement une vieille.

Avez-vous essayé d'utiliser "Cache compensation timelap" option?

[Valdo]

le serveur a planté à nouveau ce soir: j'ai désactivé le nettoyage de 00h10, mais est tombé à 3:30 quand il a quitté BB Enterprise Translator (Cache TTL)

[Valdo]

J'ai regardé, la valeur à laquelle vous vous référez est mis à 1. Pour être précis, est la suivante:

Cache compensation timelap
Combien de secondes à attendre entre les tables de cache de compensation. Set 0 pour désactiver. S'il vous plaît noter que vBET a plus de 150 tables de cache pour effacer - Régler cette valeur trop élevée peut causer que la compensation qui commence à la nuit se poursuivra, même en heures par jour. Aussi s'il vous plaît ne mettez plus élevé que votre connexion MySQL est en attente, sans utilisation (réglage de mysql: wait_timeout) - sinon il fera "serveur MySQL est parti d'erreur et de compensation ne sera pas terminé.

[vBET]

le serveur a planté à nouveau ce soir: j'ai désactivé le nettoyage de 00h10, mais est tombé à 3:30 quand il a quitté BB Enterprise Translator (Cache TTL)

Désolé - je ne comprends pas une chose - vous avez de compensation deux fois par jour? S'il vous plaît désactiver la tâche de compensation et de dire que votre serveur crash quand la compensation est désactivé (pas de question à quelle heure - le désactiver complètement). Si le serveur ne sera pas crash lors de vider la mémoire cache est désactivée, cela signifie que vBET est coupable. Si crasches toujours, alors, quelque chose d'autre cause cela.

Si vBET est coupable, alors vous avez plusieurs options pour la tune up:
- Mis en valeur plus grande à «Cache compensation timelap" - cela vous donnera le temps et plus de CPU pour les autres threads entre chaque table de compensation de cache. Je suggère de le faire en premier lieu
- Mettre en bas "Time To Live Cache (TTL)" - alors vos tables seront plus petits afin de compensation sera moins cher.
- Jouez avec «la stratégie de compensation Cache" - le dernier permettra de résoudre votre problème dans 100% - il est conçu pour le cache très grande et claire, même énorme cache immédiatement, car il supprime simplement les tables de cache tout et il crée à nouveau. Mais il efface le cache toute une fois par Cache TTL période, de sorte de cache doivent être remplis depuis le début. Ceci est la dernière chose que je conseille d'utiliser, si rien d'autre travaille ce sera à 100%. Il est ajouté juste pour de telles situations:)

[Valdo]

Nous avons essayé la première solution que vous avez proposée, fixant la valeur à 3. L'hôte a déclaré qu'il y avait une diminution de la charge, mais aller de l'avant dans la journée est augmenté. Diminuer la durée, en jours, le cache, le problème pourrait être résolu? Le serveur est sous charge, ou par l'effacement du cache des traductions ne sont pas encore enregistrées dans le cache?

[vBET]

OK pour les prochaines étapes qui peuvent vous aider:
1. Augmenter le cache TTL - moins les données seront effacées à chaque fois
2. Changement de stratégie de compensation à: "la suppression rapide des tables locales d'optimiser" - s'il vous plaît noter que cette option peut être pire si votre cache n'est pas assez grande. Pour les caches grande il vaut mieux que la normale.
3. EXPERIMENTAL: vous pouvez choisir "Quick suppression locale avec des tables d'optimiser" et éditer le fichier / includes / vbenterprisetranslator_functions.php par le commentaire de 3 lignes de code qui inclut OPTIMIZE TABLE LOCALE. Avec cette modification, elle n'éliminera que les anciennes données de manière très rapide, mais vos index ne seront pas reconstruire et se développer, de sorte que vous aurez à exécuter la requête a commenté manuellement une fois un certain temps. Si elle va travailler pour vous alors nous pouvons le mettre en œuvre comme l'une des stratégie appuyée - où est un nettoyage rapide et sans index à reconstruire et à reconstruire lui-même peut être fait par d'autres tâches en cours d'exécution à savoir un par semaine. Donc, si vous nous dites que c'est de travailler pour vous, nous l'ajouterons pour vous:)