Переклади
Сервер, який падає
Чи має вона як і раніше відбувається, коли ви відключені запланованої завдання "В. Б. підприємство Перекладач (Cache TTL)". Наскільки великі ваші таблиці кеш? Коли сервер падіння відбувається у вас є будь-які помилки в лог-файли? Чи пробували ви використовувати vBET параметр "Cache очищення timelap"? Що очищення стратегії ви використовуєте зараз?
Ви не відповіли на найбільш важливої інформації - це все ще падає, коли завдання за розкладом відключений? Спочатку ми повинні визначити, чи дійсно vBET реальна проблема.
У нормальному видалення старих кешу видаляється щодня. Якщо ви хочете швидкий спосіб видалення - використання останньої стратегії - цей буде видалити весь кеш один раз в 15 днів. Вона працює негайного і використовувати практично 0 ресурсів сервера. Але ви повинні заповнити весь кеш знову, а не тільки старий.
А ви намагалися використовувати "Cache очищення timelap" варіант?
Кеш очищення timelap
Скільки секунд очікування між очищення таблиці кеша. Встановіть 0 для відключення. Зверніть увагу, що vBET має більше 150 кеш таблиці ясно - встановлювати це значення занадто високо, що може привести до очищення, яка починається в ніч буде продовжуватися навіть в денні години. Також не слід виставляти це значення, що ваш MySQL зв'язку чекає без використання (MySQL установка: wait_timeout) - в іншому випадку це призведе до 'MySQL сервер пішов помилка' і очищення не буде закінчена.
Вибачте - я не отримую одну річ - у вас є очищення двічі на день? Будь ласка, вимкніть завдання очищення і скажіть ваш сервер впаде під час розчищення вимкнено (не важливо, на яких годину - відключити його повністю). Якщо сервер не впаде, коли кеш очищення відключена, то це означає, що vBET винен. Якщо до цих пір crasches то щось ще причини цього.Повідомлення від Valdo
Якщо vBET винен то у вас є кілька варіантів, щоб вирішувати питання:
- Встановити більше значення на "очищення кешу timelap" - це дасть час і більше ресурсів процесора для інших потоків між очищення кешу кожен стіл. Я пропоную зробити це в першу чергу
- Встановити нижній "Cache Time To Live (TTL)" - тоді ваші таблиці буде менше, так що очищення буде дешевше.
- Грати з "Cache очищення стратегії" - останній вирішить вашу проблему на 100% - він розрахований на дуже великий кеш і будуть зрозумілі навіть величезний тайник відразу, тому що вона просто видаляє цілі таблиці кеша і створює його заново. Але вона очищає весь кеш один раз за період Кеш TTL, тому кеш повинні бути заповнені з самого початку. Це останнє, що я раджу використовувати, так що якщо нічого не працює це в 100%. Він додається просто для таких ситуацій
ОТЖЕ, наступні кроки, які можуть вам допомогти:
1. Збільшення кеш TTL - менше даних буде очищений щоразу
2. Зміна очищення стратегії: "Швидке видалення з місцевими оптимізувати таблиці" - будь ласка, зверніть увагу, що ця опція може бути гіршим, якщо кеш не є достатньо великим. Для великих кешей краще, щоб нормально.
3. ЕКСПЕРИМЕНТАЛЬНА: Ви можете вибрати "Швидке видалення з місцевими оптимізувати столи» і відредагувати файл / Входить / vbenterprisetranslator_functions.php на коментар 3 рядки коду, яка включає в себе OPTIMIZE локальну таблицю. За допомогою цієї модифікації буде видалити тільки старі дані в дуже швидкий спосіб, але ваші індекси не будуть перебудовувати і буде зростати, тому що вам доведеться виконати прокоментував запит вручну один раз в той час. Якщо він буде працювати для вас, то ми можемо реалізувати його як один з підтримуваних стратегії - де швидкого очищення без індексів відновити і перебудувати саме по собі може бути зроблено іншим завдання, яке виконується, тобто один тиждень. Так що якщо ви розповісти нам, що він працює для вас ми додамо його спеціально для Вас
Ваші права
Відповісти з цитуванням