Постоянно растет таблица cache_form, что делать?

Аватар пользователя smirnov_da smirnov_da 18 апреля 2012 в 9:20

На разрабатываемом проекте стала расти таблица cache_form, причем с геометрической прогрессией - до 1,5 GB один раз заняла. Варианты решения так и не нашел. Подскажите, что делать с ней?

Комментарии

Аватар пользователя Chyvakoff Chyvakoff 18 апреля 2012 в 9:35

очистить.
Ну и разобраться после использования какой формы растет эта таблица.

Аватар пользователя Softovick Softovick 18 апреля 2012 в 11:00

Не побороть, это давняя и стабильная проблема в Drupal 6.
Причем чисткой кеша (стандартной) оно тоже не чистится. Либо маленький модуль с хуком очистки кеша hook_flush_caches, либо модуль, по hook_cron очищать таблицу (чревато).

Аватар пользователя Softovick Softovick 18 апреля 2012 в 11:35

Shok211 wrote:
Писал патч для ядра... 2 строчки

Ну собственно очистка в хуке тоже две строчки. Только хак ядра - не тру путь.

Аватар пользователя Shok211 Shok211 18 апреля 2012 в 11:38

6 вряд ли будет обновляться так часто. Да и побыстрее немного будет... просто не кешировать форму

Аватар пользователя Shok211 Shok211 18 апреля 2012 в 11:47
<?php

# /includes/form.inc

/* 121 строчка */ 

| if ($cacheable && $form['#cache'] === 1)

?>

использовать <?php  $form['#cache']    = FALSE;  ?>

Аватар пользователя petrovnn petrovnn 9 августа 2012 в 16:18

Подпишусь. У меня сильно растет эта таблица на проектах с коммерцем. На сайтах с голосованиями (я правда использую rate) аномального роста таблицы не замечено. Возможно у Rate нет этой проблемы в отличие от vote up/down.

Оптимизация таблицы в myAdmin помогает уменьшить размер, занимаемый таблицей на диске (на патруле не так много места), но это все-же борьба со следствием. Ищу решение чтобы устранить именно причину - большую таблицу. Я так понимаю что когда человек ложит товары в корзину (неважно покупает или нет) - каждое его действие пишется в эту таблицу и она просто разбухает на глазах, особенно если есть посещалка.

Попробую написать хук hook_flush_caches для очистки этой таблицы и добавить на него ссылку из админки. А очистка хуком (или кроном) этой таблицы не повлияет на корзины людей которые положили товары в корзину, но еще не оформили? Не случится так, что положил сегодня товар, завтра вернулся купить - а корзина пустая?

Аватар пользователя petrovnn petrovnn 9 августа 2012 в 16:27

Только что провел эксперимент - зашел под анонимом, положил товар в корзину, очистил таблицу cache_form, опять зашел - в корзине все осталось.

Значит действительно нужно придумать какое-то автоматизированное средство для очистки этой таблицы.

"Softovick" wrote:
hook_cron очищать таблицу (чревато)

Но вот не могу понять - почему кроном чистить эту таблицу чревато?

Аватар пользователя Softovick Softovick 9 августа 2012 в 17:12

petrovnn wrote:

Но вот не могу понять - почему кроном чистить эту таблицу чревато?

При некоторых обстоятельствах можно нарушить работу сайта.

Аватар пользователя Anonym_tsk Anonym_tsk 9 августа 2012 в 19:28

На одном проекте под D6 с последним обновлением ядра проблема ушла сама собой.
На другом проекте пришлось использовать APC и половину таблиц кэша переложить на него.

Аватар пользователя sergera-sakh sergera-sakh 5 сентября 2012 в 9:10

"Softovick" wrote:
При некоторых обстоятельствах можно нарушить работу сайта.

не подскажите, почему? Я месяц назад как-раз описывал свое решение этой проблемы: "добавьте в конец cron.php следующую строку:
db_query("DELETE FROM cache_form where 'expire' < UNIX_TIMESTAMP();");"
не очень понимаю, что может пойти не так, если удаляются только те записи, которые само ядро помечает на удаление.

Аватар пользователя Anonym_tsk Anonym_tsk 5 сентября 2012 в 10:16

sergera-sakh wrote:
"Softovick" wrote:
При некоторых обстоятельствах можно нарушить работу сайта.

не подскажите, почему? Я месяц назад как-раз описывал свое решение этой проблемы: "добавьте в конец cron.php следующую строку:
db_query("DELETE FROM cache_form where 'expire' < UNIX_TIMESTAMP();");"
не очень понимаю, что может пойти не так, если удаляются только те записи, которые само ядро помечает на удаление.

Да ничего не случится. Можно даже всю таблицу очистить, ничего не сломается.

Аватар пользователя bumble bumble 3 марта 2013 в 20:09

Всем советую смотреть сюда! http://www.drupal.ru/node/81591

В особенности вот на этот комментарий.
P.S. безграничная благодарность и хвала автору оного за великодушие и нежлобность перед форумчанами!

Аватар пользователя Happensit Happensit 18 ноября 2013 в 15:30

Альтернативный вариант

<?php

function clearcacheform_cron() {
   
cache_clear_all('*''cache'TRUE);
   
cache_clear_all('*''cache_form'TRUE);
}

?>
Аватар пользователя bebeka bebeka 22 ноября 2013 в 22:18

Есть модуль - https://drupal.org/project/optimizedb который чистит таблицу "cache_form". Модуль также умеет:

- оптимизировать таблицы
- чинить таблицы
- проверять таблицы на ошибки
- выводит в админке размер каждой таблицы

Аватар пользователя artemx artemx 13 марта 2015 в 12:15

Всем, привет!
На разработанном проекте, в один день 2 марта резко начала расти таблица "cache_form" и у сервера возросла нагрузка на ЦП и БД, что продолжается по сей день.
Скорость роста кеша таблицы 3 метра в сек. примерно за час вырастает до 1,5 ГБ. за сутки до 30 ГБ.
Рост постоянный, нагрузка на сервер так же постоянная - повышенная.

Для очистки таблицы установил модуль optimizedb, очистка по запуску крона в 1 час. Но это только частично решило проблему. Нагрузка осталась, кеш все равно растет.

Журнал ничего особенного не пишет.

По статистики запросов - посещаемость до 2 марта и после не изменилась 30 чел/сутки.

Сайт: интернет магазин на drupal 7 + ubercart + uc-ajax-cart. Есть несколько 3-и формы модуля webforms 4.4.
Фильтры 5 шт на views.

Кто знает, в чем проблема?
Как найти формы, которые забивают кеш?
Одно из значений таблицы form_form---5fBDlZ7dvSnedqKVL6CCA7Wpi7gu2CiijK5cKS10o

Аватар пользователя artemx artemx 14 марта 2015 в 12:19

Спасибо, Василий, однако модуль optimizedb уже установлен, он только позволяет очистить таблицу по запуску крона, что не решает причины постоянного роста таблицы и высокой нагрузки на ЦП сервера.