сървър, който попада

[Valdo]

тъй като аз съм инсталирал на преводача имам друг проблем: всеки път, когато съм част от планираната операция за почистване на Daily 0:10, аз спад на сървъра. Снощи дори в застой в продължение на 8 часа, така че сега трябваше да забраните това, за да се избегне това да се случи отново. Как мога да поправя? Благодаря

[vBET]

Има ли все още се случва, когато сте изключили планирана задача "Автоматични Enterprise Преводач (Cache TTL)". Колко големи са вашите кеш маси? При падането на сървър се случва да имате някакви грешки в лог файлове? Знаете ли, се опитват да използват vBET параметър "Кеш клиринг timelap"? Какво клиринг стратегия използвате в момента?

[Valdo]

Ако не се лъжа има няколко маси кеш, по един за всеки език. Общият брой на всички база данни архиви, които направих на 2 март е 877 MB. Ако направим едно средно на кеш маси, ще бъде 5 MB всеки, като се започне от максимум 14 MB на китайски и японски, в продължение на минимум 2 MB за тайландски. В скрипт, който премахва старите преводи листа на 3.30. Разглеждайки възможностите старите преводи vbet трябва да се отстраняват всеки 15 дни, опциите са определени като вас ви поставят в инсталацията. Ако искаш да кажеш с параметър timelap, стратегия кеш клиринг, това заличаване е настроен на нормални.

[vBET]

Ти не отговори на най-важната информация - дали той все още се срива, когато планирана задача е забранено? Първо ние трябва да се определи прави vBET е истинският проблем тук.

При нормални изтриване старите кеш се заличава дневно. Ако искате най-бързият начин за заличаване - използвайте последната стратегия - това ще премахне целия кеш веднъж на 15 дни. Тя работи незабавно и се използват практически 0 ресурсите на сървъра. Но вие трябва да попълните отново целия кеш, а не само на стария.

Знаете ли, се опитаха да използват опция "Cache клиринг timelap"?

[Valdo]

сървъра разби отново тази вечер: Аз увреждания почистване на 0:10, но падна в 3:30, когато той напусна BB Enterprise Преводач (Cache TTL)

[Valdo]

Погледнах, стойността на който се отнасят е 1. За да бъдем точни, е следната:

Cache клиринг timelap
Колко секунди да се чака между клиринг на кеш маси. Задайте 0, за да деактивирате. Моля, обърнете внимание, че има над 150 vBET кеш маси, за да изчистите настройката на тази твърде висока стойност, може да предизвика тази клирингова, който започва през нощта ще продължи, дори в дневните часове. Моля, не го определя по-високи, че вашия MySQL връзка чака без използването на (MySQL настройка: wait_timeout) - в противен случай това ще предизвика "MySQL сървър е отишло далеч грешка" и няма да бъде завършен клиринг.

[vBET]

сървъра разби отново тази вечер: Аз увреждания почистване на 0:10, но падна в 3:30, когато той напусна BB Enterprise Преводач (Cache TTL)

Съжаляваме - аз не се получи едно нещо - имате клиринг два пъти на ден? Моля, деактивирайте задача клиринг и кажете на вашия сървър ще се срине, когато клиринг е забранена (без значение, при която часа - да го изключите напълно). Ако сървърът не ще се срине, когато кеш клиринг е забранено, то това означава, че vBET е виновен. Ако все още crasches после нещо друго причинява това.

Ако vBET е виновен, тогава имате няколко възможности да го настройвам:
- Комплект-голяма стойност на "Кеш клиринг timelap" - това ще даде време и повече процесора за други теми между клиринг всеки кеш маса. Предлагам да направим това на първо място
- Задайте по-ниско "Cache на Time To Live (TTL)" - тогава таблици ви ще бъде по-малък, така клиринг ще бъде по-малко скъпо.
- Играйте с "стратегия за клиринг на Cache" - последният ще реши проблема ви в 100% - той е проектиран за много голям кеш и ще изчисти дори огромен кеш веднага, защото той просто премахва цялата кеш маси и тя създава отново. Но това изчиства целия кеш веднъж на Cache период TTL, така че кеш трябва да бъдат попълнени от началото. Това е последното нещо, което съветват да се използват, така че ако нищо друго не работи тази воля в 100%. Тя се добавя само за такива ситуации:)

[Valdo]

Опитахме първото решение имате предложи създаването на стойност до 3. Домакин каза, че е налице намаляване на товара, но върви напред през деня се увеличава. Намаляване на продължителността, в дни, на кеш паметта, проблемът може да бъде решен? Сървърът е под товар, или чрез изчистване на кеш паметта на преводите все още не са записани в кеш?

[vBET]

OK така че следващите стъпки, които могат да ви помогнат:
1. Увеличаване кеш TTL - по-малко данни ще се изчиства всеки път,
2. Промяна на стратегията на клиринг: "Бързо изтриване на местните с оптимизиране на таблици" - моля, имайте предвид, че тази опция може да бъде най-тежко, ако кеша си не е достатъчно голям. За голям кеш, е по-добре, че нормално.
3. ЕКСПЕРИМЕНТАЛНО: можете да изберете "Quick местните заличаване с оптимизиране на таблици" и редактирате файла / включва / vbenterprisetranslator_functions.php от коментар 3 реда код, който включва оптимизиране локалната таблица. С тази модификация ще премахне само стари данни в много бърз начин, но индекси не ще се възстанови и ще расте, така че ще трябва да изпълни, коментира заявка ръчно веднъж известно време. Ако той ще работи за вас, тогава можем да го приложи като един от подкрепено стратегия - където е бързо почистване без индекси възстановяване и възстановяване на себе си могат да бъдат направени от друга задача да работи, т.е. една седмица. Така че, ако ни каже, че работи за вас, ние ще го добавите специално за вас:)