Добрый день!
База данных Drupal 7 бесконечно растет. Проект только создан, материалов нет, установленных модулей 10-15 штук, обычно.
Уже более 124Мб, ограничение на хостинге 100Мб на данном начальном тарифе, но даже если перейти на другой тариф, то база продолжит расти. Увеличиваются таблицы d7_cache_. Получается что растет кэш 86,5 Мб, как его удалить или запретить?
В настройках-производительность-удалить кэш, не влияет на размер таблиц.
100K d7_actions.ibd
12K d7_authmap.frm
116K d7_authmap.ibd
12K d7_batch.frm
116K d7_batch.ibd
12K d7_block_custom.frm
116K d7_block_custom.ibd
12K d7_blocked_ips.frm
116K d7_blocked_ips.ibd
12K d7_block.frm
148K d7_block.ibd
12K d7_block_node_type.frm
116K d7_block_node_type.ibd
12K d7_block_role.frm
116K d7_block_role.ibd
12K d7_book.frm
132K d7_book.ibd
12K d7_cache_block.frm
116K d7_cache_block.ibd
12K d7_cache_bootstrap.frm
9.1M d7_cache_bootstrap.ibd
12K d7_cache_field.frm
9.1M d7_cache_field.ibd
12K d7_cache_filter.frm
116K d7_cache_filter.ibd
12K d7_cache_form.frm
22M d7_cache_form.ibd
12K d7_cache.frm
11M d7_cache.ibd
12K d7_cache_image.frm
116K d7_cache_image.ibd
12K d7_cache_menu.frm
14M d7_cache_menu.ibd
12K d7_cache_page.frm
9.1M d7_cache_page.ibd
12K d7_cache_path.frm
4.1M d7_cache_path.ibd
12K d7_cache_token.frm
420K d7_cache_token.ibd
12K d7_cache_update.frm
468K d7_cache_update.ibd
12K d7_cache_views_data.frm
116K d7_cache_views_data.ibd
12K d7_cache_views.frm
8.1M d7_cache_views.ibd
12K d7_captcha_points.frm
100K d7_captcha_points.ibd
12K d7_captcha_sessions.frm
276K d7_captcha_sessions.ibd
12K d7_comment.frm
180K d7_comment.ibd
12K d7_contact.frm
132K d7_contact.ibd
12K d7_ctools_css_cache.frm
100K d7_ctools_css_cache.ibd
12K d7_ctools_object_cache.frm
308K d7_ctools_object_cache.ibd
12K d7_date_format_locale.frm
100K d7_date_format_locale.ibd
12K d7_date_formats.frm
116K d7_date_formats.ibd
12K d7_date_format_type.frm
116K d7_date_format_type.ibd
12K d7_field_config.frm
228K d7_field_config.ibd
12K d7_field_config_instance.frm
196K d7_field_config_instance.ibd
12K d7_field_data_body.frm
356K d7_field_data_body.ibd
12K d7_field_data_comment_body.frm
292K d7_field_data_comment_body.ibd
12K d7_field_data_field_ev_contact.frm
212K d7_field_data_field_ev_contact.ibd
12K d7_field_data_field_ev_datetime.frm
196K d7_field_data_field_ev_datetime.ibd
12K d7_field_data_field_ev_place.frm
212K d7_field_data_field_ev_place.ibd
12K d7_field_data_field_image.frm
212K d7_field_data_field_image.ibd
16K d7_field_data_field_sas.frm
212K d7_field_data_field_sas.ibd
12K d7_field_data_field_tags.frm
212K d7_field_data_field_tags.ibd
12K d7_field_data_file.frm
212K d7_field_data_file.ibd
12K d7_field_data_group_audience.frm
212K d7_field_data_group_audience.ibd
12K d7_field_data_group_group.frm
212K d7_field_data_group_group.ibd
12K d7_field_data_media_gallery_media.frm
212K d7_field_data_media_gallery_media.ibd
12K d7_field_data_og_views.frm
212K d7_field_data_og_views.ibd
12K d7_field_data_taxonomy_forums.frm
212K d7_field_data_taxonomy_forums.ibd
12K d7_field_revision_body.frm
548K d7_field_revision_body.ibd
12K d7_field_revision_comment_body.frm
292K d7_field_revision_comment_body.ibd
12K d7_field_revision_field_ev_contact.frm
212K d7_field_revision_field_ev_contact.ibd
12K d7_field_revision_field_ev_datetime.frm
196K d7_field_revision_field_ev_datetime.ibd
12K d7_field_revision_field_ev_place.frm
212K d7_field_revision_field_ev_place.ibd
12K d7_field_revision_field_image.frm
212K d7_field_revision_field_image.ibd
16K d7_field_revision_field_sas.frm
212K d7_field_revision_field_sas.ibd
12K d7_field_revision_field_tags.frm
212K d7_field_revision_field_tags.ibd
12K d7_field_revision_file.frm
212K d7_field_revision_file.ibd
12K d7_field_revision_group_audience.frm
212K d7_field_revision_group_audience.ibd
12K d7_field_revision_group_group.frm
212K d7_field_revision_group_group.ibd
12K d7_field_revision_media_gallery_media.frm
212K d7_field_revision_media_gallery_media.ibd
12K d7_field_revision_og_views.frm
212K d7_field_revision_og_views.ibd
12K d7_field_revision_taxonomy_forums.frm
212K d7_field_revision_taxonomy_forums.ibd
12K d7_file_managed.frm
164K d7_file_managed.ibd
12K d7_file_usage.frm
148K d7_file_usage.ibd
12K d7_filter_format.frm
132K d7_filter_format.ibd
12K d7_filter.frm
116K d7_filter.ibd
12K d7_flood.frm
132K d7_flood.ibd
12K d7_forum.frm
132K d7_forum.ibd
12K d7_forum_index.frm
116K d7_forum_index.ibd
12K d7_history.frm
116K d7_history.ibd
12K d7_image_effects.frm
132K d7_image_effects.ibd
12K d7_image_styles.frm
116K d7_image_styles.ibd
12K d7_languages.frm
116K d7_languages.ibd
12K d7_locales_source.frm
9.1M d7_locales_source.ibd
12K d7_locales_target.frm
9.1M d7_locales_target.ibd
12K d7_menu_custom.frm
100K d7_menu_custom.ibd
16K d7_menu_links.frm
372K d7_menu_links.ibd
20K d7_menu_router.frm
628K d7_menu_router.ibd
12K d7_node_access.frm
100K d7_node_access.ibd
12K d7_node_comment_statistics.frm
148K d7_node_comment_statistics.ibd
12K d7_node.frm
260K d7_node.ibd
12K d7_node_revision.frm
132K d7_node_revision.ibd
16K d7_node_type.frm
100K d7_node_type.ibd
12K d7_og.frm
100K d7_og.ibd
12K d7_og_role.frm
100K d7_og_role.ibd
12K d7_og_role_permission.frm
116K d7_og_role_permission.ibd
12K d7_og_users_roles.frm
116K d7_og_users_roles.ibd
12K d7_pm_disable.frm
100K d7_pm_disable.ibd
12K d7_pm_index.frm
148K d7_pm_index.ibd
12K d7_pm_message.frm
100K d7_pm_message.ibd
12K d7_poll_choice.frm
116K d7_poll_choice.ibd
12K d7_poll.frm
100K d7_poll.ibd
12K d7_poll_vote.frm
148K d7_poll_vote.ibd
12K d7_profile_field.frm
132K d7_profile_field.ibd
12K d7_profile.frm
116K d7_profile.ibd
12K d7_profile_type.frm
116K d7_profile_type.ibd
12K d7_profile_value.frm
116K d7_profile_value.ibd
12K d7_queue.frm
260K d7_queue.ibd
12K d7_rdf_mapping.frm
100K d7_rdf_mapping.ibd
12K d7_registry_file.frm
196K d7_registry_file.ibd
12K d7_registry.frm
308K d7_registry.ibd
12K d7_role.frm
132K d7_role.ibd
12K d7_role_permission.frm
116K d7_role_permission.ibd
12K d7_search_dataset.frm
196K d7_search_dataset.ibd
12K d7_search_index.frm
500K d7_search_index.ibd
12K d7_search_node_links.frm
116K d7_search_node_links.ibd
12K d7_search_total.frm
244K d7_search_total.ibd
12K d7_semaphore.frm
132K d7_semaphore.ibd
12K d7_sequences.frm
100K d7_sequences.ibd
12K d7_sessions.frm
148K d7_sessions.ibd
12K d7_system.frm
324K d7_system.ibd
12K d7_taxonomy_index.frm
132K d7_taxonomy_index.ibd
12K d7_taxonomy_term_data.frm
148K d7_taxonomy_term_data.ibd
12K d7_taxonomy_term_hierarchy.frm
116K d7_taxonomy_term_hierarchy.ibd
12K d7_taxonomy_vocabulary.frm
132K d7_taxonomy_vocabulary.ibd
12K d7_url_alias.frm
132K d7_url_alias.ibd
16K d7_users.frm
164K d7_users.ibd
12K d7_users_roles.frm
116K d7_users_roles.ibd
12K d7_variable.frm
180K d7_variable.ibd
12K d7_views_display.frm
212K d7_views_display.ibd
12K d7_views_view.frm
116K d7_views_view.ibd
12K d7_watchdog.frm
740K d7_watchdog.ibd
12K d7_wysiwyg.frm
100K d7_wysiwyg.ibd
12K d7_wysiwyg_user.frm
132K d7_wysiwyg_user.ibd
4.0K db.opt
124M total
Комментарии
Cron выполняется? Сколько в настройках производительности указано время жизни кеша, максимальное и минимальное?
.
Выполняется раз в сутки:
/usr/bin/php /home/userNNN-NNN/www/mywebsite.com/cron.php
Минимальное время жизни кэша: Нет
Максимальное время: Нет
Кэширование блоков: выключено
Кэшировать страницы для анонимных пользователей:выключено
Объединение и сжатие файлов CSS: нет
Объединение файлов JavaScript: нет
Уже пару недель так и всёравно растет (было 70Мб, теперь 124Мб).
.
Для запуска крона в семерке нужно передавать cron_key, который можно посмотреть в отчете о состоянии.
У Вас крон не работал.
.
Крон также ежедневно запускал вручную,
пока ничего не изменилось
А если установить максимальное время жизни, сутки например для кеша?
Не меняется, 1 день ставил на мин и макс, галочки везде, чистил кэш и обновлял до D 7.2
Всего размещено 1 из 999 возможных, использовано 100.00 из 100.00Мб и 22.56Мб за дополнительную плату.
А phpmyadmin что кажет про таблицы? по скольку записей? Может все ферментировано? Дайте скрин таблиц. Вот не знаю есть-ли в mysql такое понятие как shrink..
Размер базы данных phpmyadmin показывает меньше 30 Мб
Вот скрин phpmyadmin
Угу как и предполагал..
Почитайте как сделать shrink.
В частности это
«Движок InnoDB не поддерживает уменьшение размеров файлов БД — это принципиальное ограничение. Единственный способ уменьшить размер БД — сделать дамп, переинициализировать хранилище, восстановить из дампа. Увы, это действительно так. »
Это значит, что если нагадили в таблицу на 30 мб то, даже после удаления записей из таблицы, файл будет весить 30 мб.
Был удивлен когда при переносе на новую площадку хостинга бд стала всего 30 мб, но это же проблема каждую неделю делать бэкап, удалять и восстанавливать, есть решение???
А что будет через несколько месяцев???
Купите нормальный хостинг без ограничений по базе.
Ну будет размер базы упираться в общий размер 2-3 Гб. Через 1 год будет > 1.2 Гб только одного кэша, если не больше.
За месяц база данных увеличилась почти на 100 Мб, это при мизерной посещаемости!
Нет, не будет.
Поясню:
записали 100 строк по мегабайту в таблицу - 100мб
отработал крон убило кеш - файл так и остался 100мб, но на это место будет записана другая инфа.
т.е. записали 30 строк по метру - все равно файл 100 мб, а не 130...
Меняйте хостинг.
Не совсем понял, а почему у меня кэш постоянно растет? Именно самих файлов базы данных mysql
Разве на новом хостинге не будет так расти?
Или кэш не постоянно растет а до определенного значения? Если так, то может просто сменить тариф на дорогой с ограничем по базе 600 Мб на том же хостинге?
до опред. значения
600 мб вполне хватит для среднего сайта.
P.S. если будет много нод не включайте модуль поиска - дох. отожрет..
Просто интересно, а сколько там стоит тариф с 600 мб под базы?
200 рублей в месяц - IHC, буду менять хостинг
Спасибо за помощь, а то непонимал то ли баг D7, то ли хостинг кривой
Из всего вышенаписаного сделаю вывод решения данного вопроса. Как я понял это все из за мусора в БД, база растягивается, но уменьшиться физически не может. Уменьшить ее можно сделав бекап, потом удалить БД, создать новую и из бекапа импортировать таблицы.
Или вообще ничего не делать, на место мусора записывается свежая инфа, и если ее не много, она не будет дальше растягивать БД.
Есть еще другой вариант, можно задать другой тип таблиц, вместо InnoDB сделать MyISAM. Как по умолчанию сделать MyISAM, я спросил тут http://www.drupal.ru/node/70475
нефиг браться за тов чем не разбирваешься, без особой надобности.
Это не предьява, а деперсонализированный результат размышлений.
читать про оптимизацию таблиц у MyISAM и InnoDB, узнать из этой же статьи что у InnoDB нет оптимизации и что делать в данном случае.
Сделать выводы
Движок InnoDB, я угадал? Все лечится довольно элегантно: ставится модуль DB Maintenance (вроде так называется), и по крону он делает OPTIMIZE TABLE всем таблицам, что некисло жмет размер таблиц. Для сравнения, на среднего размера сайте таблица watchdog под InnoDB за два дня разрастается на 12 гигов, после OPTIMIZE TABLE остается 50 метров.
Ага, а потом в одно веселое утро просыпаемся и видим, что база порушена без возможности восстановления, а последний бекап делался в прошлом году. Сильно не рекомендую этот модуль. К тому же там делается не просто OPTIMIZE TABLE - это не работает в большинстве случаев на InnoDB.
У меня стоит этот модуль, тупо поставил на оптимизацию все таблицы и работает пока нормально.
Всмысле? optimize table стандартная фишка же
курим маны, узнаем, что есть разные движки с разницыми подходами.
optimize table для MyISAM != optimize table для InnoDB
А почему собственно - решено? Что хоть за решение? Слезать с ИХЦ?
Таже проблема с IHC.ru
я решил проще, перевел все таблицы из формата INNODB в MYISAM. Самым безхитростным способом:
1. Скачал дамп БД
2. Открыл в текстовом редакторе (пр. Notepad++)
3. Сделал "Поиск и замена" строки ENGINE=InnoDB на ENGINE=MYISAM
4. Теперь ihc.ru видит что БД весит на 180мб, а лишь 12мб
Конечно поменять хостинг не проблема, но я уже проплатил за год и не хотелось пока мучаться с возвратом средств
Здравствуйте, спасибо сделал как Вы написали.
Да действительно БД уменьшилась в 8 раз, по скорости быстрее
1)скажите это как нибудь в дальнейшем может ухудшить работу сайта?
2)у меня опять возникла проблема, БД занимала 145 а через сутки 205, при этом объявлений не добавилось, а только обновлялись, при этом сами и хаотично, это я так понимаю неправильно что то прописано в обновлении.
Сайт www.autoprof.biz
Буду благодарен за помощь
Подскажите а если на сайте есть Krumo version 0.2.1a | http://krumo.sourceforge.net это не вирус? потому что авант время от времени видит его как вирус
Всем советую смотреть сюда! http://www.drupal.ru/node/81591
В особенности вот на этот комментарий.
P.S. безграничная благодарность и хвала автору оного за великодушие и нежлобность перед форумчанами!
Как правило дует файлы кэша. Их не сложно преиодически очищать даже вручную.
У меня есть один сайт еще на старом двигуне 5.х Проблема была(?) очень схожа. За сутки БД разрасталась вдвое и это при посещении 200 активных юзеров в день. На VPS от reg.ru с 512Мб. Сайт падал при попытке отработать CRON. Он и сейчас тормозит довольно сильно в момент работы хрона но вот размер БД впервые за день остался на прежнем уровне 58 Мб. Полистав drupal.ru нашел несколько советов и вот мои настройки:
- Жизнь кэша страниц 1час
- Модуль Session Expire Очистка сессий для анонимов 1 день, 2 дня для всех пользователей. Это неплохая защита от ботов и прочей шушары которая без конца атакует сайт на предмет ХЗ чего ))
- Модуль Cache Cleaner Чистим таблицы кэша каждый час. Правда не все таблицы cache_* чистит но основные cache_menu, cache_page и т.д. чистит.
- Модуль DB Maintenance Оптимизирует не все таблицы, а только те которые быстро фрагментируются
Чтобы немного "расклинить" процессы оптимизации и чистки перевел оптимизируемые и чистящиеся таблицы из MyISAM в InnoDB (есть сомнения на этот счет но "белый экран" реально пропал) База хоть и долго думает во время работы CRON но процессы завершает.
Вот как-то так. Но все равно БД тупит.