1. Главная
  2. Блоги
  3. Блог Lavio

Как определить что именно (модуль или что-то еще) забивает таблицу cache_menu?

Главные вкладки

Аватар пользователя Lavio Lavio 13 февраля 2014 в 11:18

За день работы сайта таблица cache_menu может разрастись от 0кб до 1,5ГБ (обычно 700мб). Крон срабатывает автоматически каждые 2 часа. Даже если его запускать в ручную то он не чистит эту таблицу. Также если нажать кнопку "очистить кэш" в админке друпала то таблица полностью очищается общий объем БД в phpmyadmin приходит в норму, однако общий объем БД, который можно посмотреть в инфе профиля у хостинга, остается большим (хоть и меньше чем до очистки cache_menu), а уменьшается до вменяемого размера только после оптимизации таблиц. В техподдержке хостинга сказали что разница между тем что видно у них (общий объем БД) и тем что видно в phpmyadmin зависит от того что в phpmyadmin не учитывается объем технической составляющей БД, которая скрыта от пользователя и формируется для повышения быстродействия движка БД. Так вот, возникло подозрение что один из модулей туда складывает(в cache_menu) свои значения криво, не указывая их срок хранения (кстати если выставлять значение хранения кэша в настройках друпала или вовсе отключить его, то оно не меняет ситуацию), в следствии чего БД не чистится автоматом и цепляет к себе еще вагон собственного кэша в технической информации который убирается только через ручную оптимизацию таблиц после очистки cache_menu.

Заходить каждый вечер, чистить в ручную, затем оптимизировать таблицы как-то напрягает. Создать задачу в кроне на принудительную очистку данной таблицы тоже не по фен-шую (ну не должно быть столько мусора в кэше за такой короткий промежуток времени), и к тому же делать оптимизацию БД автоматически чревато потерей самой БД если в этот момент будет затруднена работа phpmyadmin.

Комментарии

Аватар пользователя Lavio Lavio 13 февраля 2014 в 18:33

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

Аватар пользователя sudo sudo 16 марта 2014 в 12:22

"DivaDii" wrote:
Решение есть вот тут:
http://www.drupal.ru/node/81591[/quote]
Не знаю, кто из этих решений срабатывает, но срабатывает.

Установил db_maintance и чуток поправил его код.

if (db_driver() == 'mysql') {
try {
/* db_query("OPTIMIZE TABLE {$table_name}")->execute();*/
db_query("TRUNCATE {$table_name}")->execute();
}
В настройках выбрал cache_menu,табличка стала очищаться ежечасно по крону.

"Lavio" wrote:
Хочется найти причину и источник дикого количества кэша, а не автоматизировать его удаление.

Хорошо, когда есть время играть игрушки. Но здесь задача практическая,поскольку ежедневно эта дурацкая табличка сжирала все 10 гигов дисковой квоты и переваливала за нее, а хостер, разумеется, предлагал переход на выделенный сервер... Ему пох, лишь бы платили побольше. Так что проще безболезненно убрать симптоматику и укладываться в 600 руб/месяц за хостинг, чем платить в 1,5 раза больше, чем за московскую квартиру.
"imarat" wrote:

Оптимизацию таблиц через db_maintance ? Его можно поставит на автоматическое срабатывание раз в день

Так что автору идеи - громадное спасибо! А мне спасибо за творческую ее реализацию Smile

Аватар пользователя sudo sudo 12 июня 2016 в 7:44

По вновь открывшимся обстоятельствам дела: похоже, что во всей этой катавасии виноват модуль Book. У меня была одна громадная подшивка - более 5 тыс. статей - как только я ее удалил, так сразу cache_menu стала на 3 порядка меньше и сайт перестал тормозить. Но модифицированный db_maintance все равно не отключаю.
Так что от подшивок надо избавляться, лучше пользоваться таксономией.