22 января 2009 в 15:07
Ситуация такая, что база данных разрослась до 200 метров, хотя реально я предполагаю, она даожна быть как минимум раз в 10 меньше. Это почему так?????????????
Пошерстил форум, узнал что это может быть из-за кеша, но вроде как чистить его бесполезно, потому что он и так разрастается опять до определеннго размера. Еще наверное различные логи место занимают. Интересно как много???
Объясните плиз кто-нибудь механизм разрастания базы данных и возможно ли настроить движок так, чтобы она не разрасталась сверх ей положенного?
Комментарии
Попробуй почистить таблицы с префиксом cache_ (это может привести к снижению производительности) и таблицу watchdog (это Друпальский лог).
Таблицы с поисковым индексом могут много места занимать, если много материала на сайте и включен модуль поиска.
Ну, да... размер таблицы
_cache_form
193 МB !!!!!!!!!!
Другие кеши, поисковые и _watchdog по божески по 2-3 мегабайта
Я очень надеюсь, что это тотальное мегакеширование можно как-то отключить, потому что в противном случае мне придется отказаться от друпала. Черт с ней с нагрузкой на сервер - нет такой посещаемости, чтобы над этим задумываться. А вот размер базы у дешевых хостингов, которые я способен оплачивать, имеет очень большое значение.
Помогите, плиз, хелп... как с этим справиться????? Это как удар ножом в спину со стороны друпала. Только только к нему приноравливаться начал
крон регулярно выполняется?
настройкой крона вот как раз второй час занимаюсь... но чтобы твердо сказать, что он работает, наверное несколько дней на тесты понадобиться...
Знаете, поставил этот модуль http://drupal.org/project/cache_disable
почистил эту злосчастную таблицу, проверил в настройках сайта что кеш отключен, минимальное время жизни кеша стоит 1 час.
Захожу в пхпмайадмин, обновляю разом показатели БД и каждый раз в этой таблице прибавляются новые килобайты. А ВЕДЬ Я НИЧЕГО НЕ ДЕЛАЮ!!!!
Заблочил все, что мог, ну неужели же эту чуму никак невозможно остановить ;(
ЭЭ не нервничайте так, уважаемый, килобайт килобайту рознь, поставьте модуль poormanscron кажется так, настройте на запуск крона каждый час - этот процесс кроме всего прочего прочищает системные записи, если у вас включено в модулях database logging, он записывает всякие системные события в базу.
Похоже что это баг друпала - ряд таблиц кэша не очишаются от устаревших записей http://drupal.org/node/226728
Вариант решения - чистить эту табличку по крону следуюдей командой:
ну, вроде перевожу дух... поставил poormanscron с запуском через час и вот сейчас вечером проверил, там где раньше было 193 мегабайта, стало всего 2
Это значит крон запускает очистку кеша? Интересно которую... ту которая находится в дистрибутиве друпала по умолчанию или cache_disable вдруг заработал?
Кстати, а почему poormanscron называется кроном для бедных, чем он хуже настоящего?
Запуск крона это обязательное условие для работы друпала, игнорировать его не стоит. Это уже не первый вопрос, возникающий по этой теме. Наверное надо добавить в FAQ, если еще нет.
Ну нет, медленно, но верно но размер таблицы продолжает расти.
То есть я как-то не ощущаю, что она очищается, хотя крон судя по отчетам друпала исправно перезапускается каждый час. Ну как же так, движок рекламируется как наиболее приспосабливаемый и функциональный, а на деле мало того, что намучаешься с настройкой, так еще и на более менее посещаемый и обновляемый сайт, похоже гигабайт базы данных надо. Неужели так трудно было сделать фишечку с реальным отключением кеша ((
Ответ есть на этой странице - я выпросила отрывок из книги Друпал 6 ПроДевелопмент, как раз про то, как можно уменьшить кэш.
У вас проблема, как я понимаю, что крон не чистит "каждый час", но каждый час чистит то, что старше такого-то отрезка времени. Вот можно настроить отрезок времени, чтобы чистилось быстрее
http://drupal.ru/node/23294, комментарий где-то 10-11
Geldora, ответ я так понимаю это тот, который на английском вперемешку со спецефичискими понятиями друпала? Я бы еще может попробовал в этих иероглифах разобраться, но при чем тут выделенная мне память?
Всё что мне нужно - это вырубить этот чертов кеш либо, сделать так чтобы его таблицы по истечению какого-то срока реально очищались. На данный момент, несмотря ни на какие вспомогательные модули этого не происходит! Что делать, я не знаю... начинаю подумывать о wordpress. Надеюсь он окажется более продуманным, чем сей продукт, хотя блин два проекта уже на друпале стоят
Похоже тема опять замнётся... до тех пор пока опять кто-нибудь не откроет для себя эту мину замедленного действия
И знаете что, похоже это модуль опросов жрет базу!
И лично я считаю, что это бага. И достаточно экстремальная! На сайте был один опрос. И при посещаемости 10 человек в день, таблица cache_form росла примерно по полтора метра в день. Отключил модуль полностью (только его), прошло два дня, таблица больше не выросла ни на килобайт...
Конкретизирую, глючит не сам модуль, а его блок... когда его включаешь. Кто нибудь может подсказать хоть куда рыть (какие файлы смотреть)?
По-моему есть два варианта:
1. У блока последнего опроса есть своя собственная таблица кеширования, с кторой он и не справляется
2. cache_form - это когда друпал кеширует какие-то элементы главной страницы сайта и натыкаясь на блок вывода опроса, что-то постоянно перезаписывает
Прошу помощи хотя бы в указании направления действия, а именно откуда поступают данные в таблицу cache_form
Уж на это на форуме официальной русской поддержки drupal я могу рассчитывать?
Присоединяюсь к kompas. Я тоже подозреваю блок опроса. Странно ещё то, что некоторые таблицы я не могу очистить (empty) через PHPMyAdmin, включительно со злополучной таблицей cache_form.
Вперет, там нет кеширования, главная админки грузится ~2мин — удачи!
По теме:
На странице производительность все кеширование отключено? Какой друпал, какие модули стоят (работают)?
Вас, видимо, хостер правами обделил.
Присоединяюсь. Действительно на сайтах на которых включен модуль опроса poll таблица cache_form разрастается до неимоверных размеров. Вплоть до того что хостер заблокировал доступ к хостингу в связи с превышением лимита дискового пространства. Спасибо, kompas!
Приступаю тоже к поиску решения.