Размер таблицы кэша увеличился до 10+ ГБ в прошлом месяце, и я временно исправил ее, обрезав. В прошлый раз, когда я проверял, это было около 1 ГБ. Так что через пару месяцев он снова достигнет 10 ГБ. Как с этим бороться?
Обратите внимание, что я отключил все задания cron на этом сайте. Если это причина, какой 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 вы упомянули, что, несмотря на настройку cron и их регулярный запуск, ваша таблица cache_form быстро растет.
Одним из решений этой проблемы является более частое использование cron. Сказать каждые шесть часов или меньше? Если вы не можете позволить себе это сделать, читайте дальше.
Альтернативное решение:
mymodule_cron() {
cache_clear_all(NULL, 'cache_form');
}Установите Elysia Cron, и теперь вы можете запускать функцию cron вашего модуля отдельно. Вы можете сохранять частоту запуска модуля Elysia cron каждые шесть часов. Так что ваш 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, либо уменьшать значение $ expire до более низкого значения, если вы хотите очищать записи 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/
Из моего поста в блоге вы можете добавить настройки очереди и cron, а затем использовать что-то вроде 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 предоставляет хорошую дополнительную информацию.