На разрабатываемом проекте стала расти таблица cache_form, причем с геометрической прогрессией - до 1,5 GB один раз заняла. Варианты решения так и не нашел. Подскажите, что делать с ней?
Не побороть, это давняя и стабильная проблема в Drupal 6.
Причем чисткой кеша (стандартной) оно тоже не чистится. Либо маленький модуль с хуком очистки кеша hook_flush_caches, либо модуль, по hook_cron очищать таблицу (чревато).
Подпишусь. У меня сильно растет эта таблица на проектах с коммерцем. На сайтах с голосованиями (я правда использую rate) аномального роста таблицы не замечено. Возможно у Rate нет этой проблемы в отличие от vote up/down.
Оптимизация таблицы в myAdmin помогает уменьшить размер, занимаемый таблицей на диске (на патруле не так много места), но это все-же борьба со следствием. Ищу решение чтобы устранить именно причину - большую таблицу. Я так понимаю что когда человек ложит товары в корзину (неважно покупает или нет) - каждое его действие пишется в эту таблицу и она просто разбухает на глазах, особенно если есть посещалка.
Попробую написать хук hook_flush_caches для очистки этой таблицы и добавить на него ссылку из админки. А очистка хуком (или кроном) этой таблицы не повлияет на корзины людей которые положили товары в корзину, но еще не оформили? Не случится так, что положил сегодня товар, завтра вернулся купить - а корзина пустая?
На одном проекте под D6 с последним обновлением ядра проблема ушла сама собой.
На другом проекте пришлось использовать APC и половину таблиц кэша переложить на него.
При некоторых обстоятельствах можно нарушить работу сайта.
не подскажите, почему? Я месяц назад как-раз описывал свое решение этой проблемы: "добавьте в конец cron.php следующую строку: db_query("DELETE FROM cache_form where 'expire' < UNIX_TIMESTAMP();");"
не очень понимаю, что может пойти не так, если удаляются только те записи, которые само ядро помечает на удаление.
При некоторых обстоятельствах можно нарушить работу сайта.
не подскажите, почему? Я месяц назад как-раз описывал свое решение этой проблемы: "добавьте в конец cron.php следующую строку: db_query("DELETE FROM cache_form where 'expire' < UNIX_TIMESTAMP();");"
не очень понимаю, что может пойти не так, если удаляются только те записи, которые само ядро помечает на удаление.
Да ничего не случится. Можно даже всю таблицу очистить, ничего не сломается.
Всем, привет!
На разработанном проекте, в один день 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
Спасибо, Василий, однако модуль optimizedb уже установлен, он только позволяет очистить таблицу по запуску крона, что не решает причины постоянного роста таблицы и высокой нагрузки на ЦП сервера.
Комментарии
очистить.
Ну и разобраться после использования какой формы растет эта таблица.
Растет на голосовалке - Vote Up/Down, а почему не могу понять...
В модуль поставить фикс чтоб форма не кешировалась
А лучше form_alert
Не побороть, это давняя и стабильная проблема в Drupal 6.
Причем чисткой кеша (стандартной) оно тоже не чистится. Либо маленький модуль с хуком очистки кеша hook_flush_caches, либо модуль, по hook_cron очищать таблицу (чревато).
Писал патч для ядра... 2 строчки
Ну собственно очистка в хуке тоже две строчки. Только хак ядра - не тру путь.
6 вряд ли будет обновляться так часто. Да и побыстрее немного будет... просто не кешировать форму
<?php # /includes/form.inc
/* 121 строчка */
| if ($cacheable && $form['#cache'] === 1) ?>использовать
<?php $form['#cache'] = FALSE; ?>
Подпишусь. У меня сильно растет эта таблица на проектах с коммерцем. На сайтах с голосованиями (я правда использую rate) аномального роста таблицы не замечено. Возможно у Rate нет этой проблемы в отличие от vote up/down.
Оптимизация таблицы в myAdmin помогает уменьшить размер, занимаемый таблицей на диске (на патруле не так много места), но это все-же борьба со следствием. Ищу решение чтобы устранить именно причину - большую таблицу. Я так понимаю что когда человек ложит товары в корзину (неважно покупает или нет) - каждое его действие пишется в эту таблицу и она просто разбухает на глазах, особенно если есть посещалка.
Попробую написать хук hook_flush_caches для очистки этой таблицы и добавить на него ссылку из админки. А очистка хуком (или кроном) этой таблицы не повлияет на корзины людей которые положили товары в корзину, но еще не оформили? Не случится так, что положил сегодня товар, завтра вернулся купить - а корзина пустая?
Кстати такой подсказали модулек: http://drupal.org/project/db_maintenance/ надо попробовать
Только что провел эксперимент - зашел под анонимом, положил товар в корзину, очистил таблицу cache_form, опять зашел - в корзине все осталось.
Значит действительно нужно придумать какое-то автоматизированное средство для очистки этой таблицы.
Но вот не могу понять - почему кроном чистить эту таблицу чревато?
При некоторых обстоятельствах можно нарушить работу сайта.
На одном проекте под D6 с последним обновлением ядра проблема ушла сама собой.
На другом проекте пришлось использовать APC и половину таблиц кэша переложить на него.
не подскажите, почему? Я месяц назад как-раз описывал свое решение этой проблемы: "добавьте в конец cron.php следующую строку:
db_query("DELETE FROM cache_form where 'expire' < UNIX_TIMESTAMP();");
"не очень понимаю, что может пойти не так, если удаляются только те записи, которые само ядро помечает на удаление.
Да ничего не случится. Можно даже всю таблицу очистить, ничего не сломается.
Всем советую смотреть сюда! http://www.drupal.ru/node/81591
В особенности вот на этот комментарий.
P.S. безграничная благодарность и хвала автору оного за великодушие и нежлобность перед форумчанами!
Альтернативный вариант
<?php function clearcacheform_cron() {
cache_clear_all('*', 'cache', TRUE);
cache_clear_all('*', 'cache_form', TRUE);
} ?>
Есть модуль - https://drupal.org/project/optimizedb который чистит таблицу "cache_form". Модуль также умеет:
- оптимизировать таблицы
- чинить таблицы
- проверять таблицы на ошибки
- выводит в админке размер каждой таблицы
Всем, привет!
Всем, привет!
На разработанном проекте, в один день 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
https://www.drupal.org/project/optimizedb
Спасибо, Василий, однако модуль optimizedb уже установлен, он только позволяет очистить таблицу по запуску крона, что не решает причины постоянного роста таблицы и высокой нагрузки на ЦП сервера.