Розмір таблиці кешу збільшився до 10+ ГБ минулого місяця, і я її тимчасово виправив, обрізаючи. Востаннє я перевіряв, що це близько 1 ГБ. Тож через пару місяців він знову потрапить на 10 Гб. Як це слід вирішувати?
Зауважте, що на цьому веб-сайті я відключив усі завдання Cron. Якщо це причина, який крон потрібно включити?
Відповіді:
{cache_form}Стіл трохи смішно, і веде себе в дещо іншій манері , ніж інші таблиці кеша.
Якщо ви подивитесь, drupal_flush_all_caches()ви побачите, що {cache_form}це не очищено. Це захищає незавершені форми, які не працюють.
Ця system_cron()функція забезпечує подрібнення старих даних {cache_form}разом з іншими таблицями кешу.
Ви дійсно повинні запускати cron на всіх сайтах Drupal. Якщо ваш {cache_form}стіл вишуканий, то я ставлюся на ваш {watchdog}і {session}таблиці теж є. Багато інших модулів ведуть діяльність з ведення господарства як частину власних hook_cron()функцій.
Ви також можете поцікавитись чергою проблеми. Виникла помилка {cache_form}, і ви можете зіткнутися з одним.
Правило великого пальця: Cron слід регулярно запускати для обслуговування вашого веб-сайту.
Ви згадали у своєму коментарі до MPD, що, незважаючи на налаштування крона та запуск їх регулярно, ваша таблиця cache_form швидко зростає.
Одне з варіантів цього - частіше запускати свій крон. Скажіть кожні шість годин чи менше? Якщо ви не можете дозволити собі це, читайте далі.
Альтернативне рішення:
mymodule_cron() {
cache_clear_all(NULL, 'cache_form');
}Встановіть Elysia Cron і тепер ви можете запускати функцію cron свого модуля окремо. Ви можете зберігати частоту крона Elysia для себе, щоб він працював кожні шість годин. Так що ваш cache_formстіл обрізають кожні шість годин.
Під час цього процесу обрізки записи, які не старші 6 годин, не будуть видалені. Причина полягає в тому, що якщо всі записи видалено, то будь-які форми, які подаються під час видалення записів, можуть вести себе дивно.
Подивіться на код https://api.drupal.org/api/drupal/includes!form.inc/function/form_set_cache/7
function form_set_cache($form_build_id, $form, $form_state) {
// 6 hours cache life time for forms should be plenty.
$expire = 21600;Як зазначається в коментарі, вони вважають, що його повинно бути багато, і у вашому випадку це стає занадто багато для вас. Таким чином, фокус полягає в тому, щоб чистити таблицю cache_form частіше і зменшити значення $ закінчується до нижчого значення, якщо ви хочете очистити записи cache_form частіше, ніж значення за замовчуванням 6 шість годин, тоді вам потрібно змінити TTL записи cache_form.
Ви можете зробити це, встановивши cacheboject і потім реалізуючи, в hook_cacheobject_presaveмежах якого ви можете змінити TTL, може становити 2 або 3 години.
mymodule_cacheobject_presave()($object, $cid, $bin) {
// Extend the expiry period for prototype forms used in ajax enabled forms.
$cache_ttl = 1 ; // Change it to any number of hours
if ($bin == 'cache_form') {
$object->expire = REQUEST_TIME + $cache_ttl * 3600;
}
}Недоліком цього підходу є те, якщо форми не надсилаються протягом 2 годин (значення RTL, яке ви встановили), дані форми можуть бути втрачені, і у вас можуть виникнути певні проблеми, що втратили чинність.
Як вирішення цієї проблеми я створив модуль https://www.drupal.org/project/session_cache_form
Коли у мене виникли проблеми з продуктивністю на веб-сайті, на якому я працював, я зіткнувся з цим після того, як виправив кешування. Ви можете прочитати статтю тут: https://thinktandem.io/blog/2017/11/22/debugging-with-new-relic-blazemeter-strace-more/
З мого допису в блозі ви можете додати чергу та налаштування кронів, а потім використати щось на зразок Elysia Cron, щоб все добре працювало разом:
/**
* Implements hook_cron_queue_info()
*/
function THE MODULE_cron_queue_info() {
// Set up the worker queue.
$queues['THE MODULE_queue'] = array(
'worker callback' => 'THE MODULE_queue_process',
'time' => 600,
);
return $queues;
}
/**
* Implements hook_cron()
*/
function THE MODULE_cron() {
// Load up our worker queue.
$queue = DrupalQueue::get('THE MODULE_queue');
// Set up the query for expired results.
$sql = "SELECT cid FROM {cache_form} WHERE expire < :time";
$query = db_query($sql, array(':time' => REQUEST_TIME));
$results = $query->fetchAll(PDO::FETCH_ASSOC);
// Split this into chunks for safety and speed.
$chunks = array_chunk($results, 5000);
foreach ($chunks as $chunk) {
// Add the chunk to the queue worker.
$queue->createItem($chunk);
}
}
/**
* Worker callback defined in hook_cron_queue_info().
*
* @param array $data
* The array of cids we want to delete.
*/
function THE MODULE_queue_process($data) {
db_delete('cache_form')
->condition('cid', $data, 'IN')
->execute();
}Це дозволить вам спочатку обрізати стіл до розумного розміру, а потім підтримувати його.
Короткий огляд зі сторінки проекту:
Безпечно видаліть обмежену кількість елементів із таблиці cache_form.
Як тільки модуль встановлений, спершу обріжте cache_form: запустіть, drush safe-cache-form-clearпоки розмір таблиці не залишиться послідовним, вказуючи на те, що ви видалили всі записи, старші ніж на 6 годин.
Потім він продовжить працювати на cron.
Це модуль, задокументований для цієї мети компанією Acquia для своїх передплатників. Сторінка документації Acquia надає хорошу додаткову інформацію.