cache_hierarchical_select весит четверть всей базы - это нормально?
25 июля 2011 в 22:27
Сейчас заглянул в БД и обнаружил, что таблица cache_hierarchical_select весит 10 с хвостом Мб - а вся база при это - 40 Мб. Это после переезда. На старом хосте база весит 37 Мб, из которых cache_hierarchical_select - убийственные 26.
Это нормально, а то я как бы думал, что поисковый индекс первым покажет свой желудок? И что же будет, когда база разрастется до вменяемых величин порталов?
Установлен Hierarchical Select версия 6.x-3.7, используется примерно 5-6 вьюшек с ним самым раскрытым и, кроме элементов, где он сам включается (вложенность при правке термина таксономии и т.п.), я его больше никак не юзаю.
- Блог
- Войдите или зарегистрируйтесь, чтобы отправлять комментарии
Комментарии
upd: Теперь cache_hierarchical_select весит 350 Мб, а вся база при этом 370.
Может быть вообще можно как-то отключить кеширование hierarchical select? В настройках нигде не нашел, нашел только "Кэширование в базе данных HTML 5 на стороне клиента", но это, видимо, не то.
Версия 6.x-3.7
Drupalhosting.ru
Сейчас очистил таблицу, попробовал поиграться с exposed filters, которые сделаны с помощью HS - таблица на глазах тут же выросла до 10Мб. Причем весь этот мусор находится именно в
DATA(longblob).И еще, что странно, еще на одном сайте на этом же хостинге стоит HS той же версии и включены те же подмодули (все), с несколько большей посещалкой - там все нормально.
Есть такая бага у модуля, давно ипуццо
Иии? HS это ацкое кривоподелие
Имеется в виду hc.ru ?
У меня тоже на мастерхосте с этим было нормуль (зато с другим хреново).
С другой стороны, что может сделать хостер, учитывая, что у меня шаред?
И, таки отключить это кеширование получается никак?
Зашёл на д.о, собственно ишью вот http://drupal.org/node/920588
Закрыто оно не потому что исправлено, а из-за неактивности, так что проблема имеет место быть.
Нашел такой скрипт: _http://korjik.org.ua/ochistka-tablic-mysql-po-raspisaniyu/
Если его по крону запускать, скажем, каждый час, то ведь не шибко сильную нагрузку создаст?
И это... в php
нубдуб - вроде синтаксис правильный, ничего там не должно удалиться (нет команд типа "drop " )?[Удален случайный дубль поста ниже]
Нашел такую строчку в файле модуля hierarchical_select.module:
<?php// 6 hours cache life time for forms should be plenty.
define('HS_CACHE_LIFETIME_DEFAULT', 21600);
?>
Попробовал исправить 21600 на ноль - безрезультатно. Но чую, что решение где-то там.
подпишусь
Подпишитесь лучше на обноления самого модуля
Общался с хостером - единственный вариант - отключать модуль, т.к. он без кеша достаточно сильно грузит сервер.
Приведенный выше мной скрипт (точнее ссылка на него) также не рекомендуется устанавливать по этой же причине.
Кстати, установил его на семерку, так вообще ноль реакции.
Кто-то имел такой опыт?
На семёрке его автор собирался с нуля переписывать.
Вот вам принудительная очистка кеша
Огромное спасибо за модуль!
Все же пока не решаюсь применять такого рода скрипт, заменил HS на BEF - "спецэффекта" меньше, но практичность дороже.
Оригинально и в тему!
привет всем!
может быть, кто0нибудь нашел альтернативу данному модулю? очень пригодилось бы...
Самая ближайшая альтернатива - BEF.
А я использую старую версию, где этого кэша еще нема
Тут где-то писали, что от хостера еще зависит, и у меня на мастерхосте нема было. Это точно версия? Кто хостер?
И напишите, пожалуйста, какая именно версия - очень не хватает мне старого доброго ЭйчЭс.
У меня, скорее всего, dev версия. Ей, может быть, пол года или даже больше.
Вообще-то, свой кэш в HS - вещь нужная и правильная. И Вим Лирс его добавил в том числе по моей наводке ))))
Просто кэш должен очищаться. Я считаю, нужно давить на исправление этого бага
А дистрибутив сохранился? Или неправленные файлы модуля?
С нужностью кеша согласен, но его слишком много! А автоочистка никак не настраивается одной таблицы только интересно?
Модуль оказался годичной давности
Спасибо!
Поставил - отличается от текущего только содержимым двух файлоы (сравнил остальные по содержимому - одинаково) - упоминаний сабжевой таблицы в отличиях не обнаружил.
Поигрался с работой HS - таблица выросла до 1.2 Мб тут же.
Внимательно слежу до завтра, после чего отпишусь.
И все-таки можно ведь как-то включить по крону автоочистку таблицы?
вы что-то путаете...если бы в этой версии был кеш - он бы существовал в hook_schema() а я его вообще не наблюдаю
Кстати даже в последней версии с меню не работает и настройки никакой нет.
Дать доступ к FTP и базе?
Вот данные created: 1313012851
Нет уж, сами разбирайтесь..мне достаточно того, что я посмотрел в код
Дык а я пошутил, естественно!
Вы небось модуль криво установили. без удаления старого.
Поскольку это даунгрейд, нужно сначала модуль отключить, потом удалить через Друпал, потом удалить полностью файлы, потом залить мою версию.
Тоже как раз перед чтением Вашего сообщения об этом подумал.
Дубль 2: испытаю - отпишусь.
Че-та не понял - решил преустановить HS (отдаунгрейдить): отключил версию 3.7. на странице модулей, удалил модуль в админке, удалил файлы по FTP, и все равно на странице модулей отображается этот модуль и все его подмодули версии 3.7.
Попробовал закинуть файлы версии 3.3. - в админке все равно показывает 3.7. - нифига не понял, в чем дело.
Все кеши чистил (даже браузреный). После удаления проверял наличие таблиц модуля в БД - все удалилось.
RxB, уважаемый Мистер Проппер тоже не хочет работать с кешем: установил его, включил в админке, запустил крон - вес таблицы в базе остался тот же.
Шо ж за день сегодня такой невезучий!
Еще в таблице variable есть поле:
hierarchical_select_js_cache_systemсо значениемs:1:"1";Может, тут чего поменять, чтобы не кешировалось?
Upd: Изменил значение с
s:1:"1";наs:0:"";- вроде работает, только не знаю, чем мне это срезультирует, кроме большей нагрузки из-за отсутствия кеша.Есть ли какието-сдвиги в теме?
Внезапно что-то случилось, и все стало хорошо (хорошо - сказано двусмысленно: кеш не растет за счет того, что быстро чистится).
Поставил последнюю версию - за сутки вырос до 700mb и больше не рос. Какаято ерунда. Может надо чего на хостинге настроить?
Я не заморачивался:
function мой_модуль_cron() {
db_query("TRUNCATE {cache_hierarchical_select}");
}
Так проц будет грузить сильно без кеша то.
Ок. Если и проц не грузить и БД не зас$рать, есть компромисс:
1. по дефолту (у меня) модуль даёт 6 часов кешу на жизнь, т.е.
db_query("DELETE FROM {cache_hierarchical_select} WHERE expire < NOW() - 0");
2. нужно свой лайфтайм? велкам:
db_query("DELETE FROM {cache_hierarchical_select} WHERE created <= NOW() - сколько_хотим_хранить_кеш_в_секундах");
3. для знающих толк в извращениях )))
db_query("DELETE FROM {cache_hierarchical_select} WHERE ..... LIMIT 10, 1010"); и т.д. - можно загнуть sql как угодно ))
Ещё вопрос с какой периодичностью сайт крон гоняет - можно подстроится потоньше