server die valt

[Valdo]

sinds ik de installatie van de vertaler heb ik een ander probleem: als ik ben een deel van de geplande werking van het schoonmaken van de Daily 00:10, heb ik laten vallen van de server. Gisteravond heb ik zelfs tot stilstand gekomen voor acht uur, dus nu moest ik dit uit te schakelen om te vermijden dat weer gebeurt.
Hoe kan ik dit oplossen?
Grazie

[vBET]

Doet het nog steeds gebeurt er als je een handicap geplande taak 'vB Enterprise Translator (Cache TTL) ". Hoe groot zijn uw cache tabellen? Bij de server vallen gebeurt heb je eventuele fouten in log files? Heb je geprobeerd om vBET parameter "Cache clearing timelap" te gebruiken? Wat clearing strategie gebruikt u nu?

[Valdo]

Als ik me niet vergis zijn er verschillende cache tafels, een voor elke taal. Het totaal van alle de database back-ups die ik heb gemaakt op 2 maart was 877 mb. Als we een gemiddelde van cache tabellen te maken, worden 5 mb elk, variërend van een maximum van 14 mb van de Chinese en Japanse, voor een minimum van 2 MB voor de Thaise. Het script dat de oude vertalingen verwijdert vertrekt om 3.30. Als we kijken naar de opties vbet oude vertalingen moeten worden verwijderd om de 15 dagen, zijn de opties in te stellen als je je zet bij de installatie.
Als je bedoelt met timelap parameter, cache clearing-strategie, is deze schrapping ingesteld op Normaal.

[vBET]

Je hebt geen antwoord op de belangrijkste informatie - is het nog steeds crasht als geplande taak is uitgeschakeld? Moeten we eerst doet vBET is hier werkelijk om gaat vast te stellen.

In de normale verwijdering oude cache wordt dagelijks verwijderd. Als u wilt snelste manier verwijderen - gebruik laatste strategie - deze zal verwijderen hele cache een keer per 15 dagen. Het werkt onmiddellijk en het gebruik nagenoeg 0 server resources. Maar je moet heel cache opnieuw te vullen, en niet alleen oude.

Heeft u geprobeerd om "Cache clearing timelap" optie gebruiken?

[Valdo]

de server crashte vanavond weer: Ik heb met een handicap het schoonmaken van 0:10, maar viel op 3:30 toen hij vertrok BB Enterprise Translator (Cache TTL)

[Valdo]

Ik keek, is de waarde waarnaar u verwijst ingesteld op 1. Om precies te zijn, is dit:

Cache clearing timelap
Hoeveel seconden moet wachten tussen clearing-cache tabellen. Stel 0 uit te schakelen. Houdt u er rekening mee dat vBET heeft meer dan 150 cache tabellen om duidelijk - het instellen van deze waarde te hoog is kan dat clearing die begint 's nachts veroorzaken zal gaan, zelfs in de dag uren. Ook kunt u niet instellen hoger dat uw MySQL verbinding zit te wachten zonder het gebruik (mysql instelling: wait_timeout) toe - anders zal veroorzaken en clearing zal niet klaar zijn 'MySQL server weg is fout gegaan'.

[vBET]

de server crashte vanavond weer: Ik heb met een handicap het schoonmaken van 0:10, maar viel op 3:30 toen hij vertrok BB Enterprise Translator (Cache TTL)

Sorry - Ik snap het niet een ding - je hebt twee keer per clearing een dag? Schakel clearing taak en vertel heeft uw server zal crashen als clearing is uitgeschakeld (maakt niet uit op welk uur - volledig uitschakelen). Als de server niet crasht wanneer cache clearing is uitgeschakeld dan betekent dit dat vBET schuldig is. Als crasches toen nog iets anders veroorzaakt dit.

Als vBET schuldig is dan heb je verschillende opties om te tune up:
- Moet groter zijn waarde op "Cache clearing timelap" - dit geeft de tijd en meer CPU voor de andere onderwerpen die tussen clearing-cache per tafel. Ik stel voor om dit te doen in de eerste plaats
- Stel een lagere "Cache Time To Live (TTL)" - dan is uw tafels zullen kleiner zijn, zodat clearing zal minder duur zijn.
- Speel met "Cache clearing-strategie" - de laatste zal je probleem op te lossen in 100% - het is ontworpen voor zeer grote cache en zal zelfs enorme cache meteen duidelijk, omdat het gewoon verwijdert hele cache tafels en zorgt voor het weer. Maar het hele cache eens wist per Cache TTL periode, zodat cache moeten worden ingevuld vanaf het begin. Dit is laatste wat ik adviseren om te gebruiken, dus als niets anders werkt dit zal in 100%. Het wordt toegevoegd alleen voor dergelijke situaties

[Valdo]

We hebben geprobeerd de eerste oplossing die u hebt voorgesteld, waarin de waarde op 3. De gastheer zei dat er een afname van de belasting, maar de toekomst in de dag wordt verhoogd. Het verminderen van de duur, in dagen, de cache, zou het probleem worden opgelost? De server is onder belasting, of door het opruimen van de cache van de vertalingen nog niet opgeslagen in de cache?

[vBET]

OK dus de volgende stappen die u kunnen helpen:
1. Verhoog de cache TTL - minder gegevens worden gewist wanneer u de
2. Verandering clearing strategie om: "Snel lokale verwijdering met optimaliseren van tabellen" - let op dat deze optie kan worden ergste als je cache is niet groot genoeg. Voor grote caches is het beter dat normaal.
3. EXPERIMENTEEL: U kunt kiezen voor "Quick lokale verwijdering met optimaliseren van tabellen" en bewerken van bestand / Includes / vbenterprisetranslator_functions.php door comment 3 regels code waaronder OPTIMALISEREN lokale tabel. Met deze wijziging zal het verwijderen alleen oude data in een zeer snelle manier, maar uw indexen worden niet weer op te bouwen en zal groeien, dus je zal moeten uitvoeren commentaar query's handmatig eens een tijdje. Of het zal voor u werken, dan kunnen we implementeren als een van de ondersteunde strategie - waar is snelle reiniging zonder indexen weer op te bouwen en te herbouwen zelf kan worden gedaan door andere taak uitvoeren dat wil zeggen een een week. Dus als u ons vertellen dat het werkt voor u zullen we het toevoegen speciaal voor jou