База данных Drupal 7 бесконечно растет. Решено

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

Аватар пользователя MainVisor MainVisor 30 мая 2011 в 15:34

Добрый день!

База данных Drupal 7 бесконечно растет. Проект только создан, материалов нет, установленных модулей 10-15 штук, обычно.
Уже более 124Мб, ограничение на хостинге 100Мб на данном начальном тарифе, но даже если перейти на другой тариф, то база продолжит расти. Увеличиваются таблицы d7_cache_. Получается что растет кэш 86,5 Мб, как его удалить или запретить?
В настройках-производительность-удалить кэш, не влияет на размер таблиц.

12K     d7_actions.frm
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

Комментарии

Аватар пользователя Softovick Softovick 30 мая 2011 в 15:45

Cron выполняется? Сколько в настройках производительности указано время жизни кеша, максимальное и минимальное?

Аватар пользователя MainVisor MainVisor 30 мая 2011 в 16:59

Softovick wrote:
Cron выполняется? Сколько в настройках производительности указано время жизни кеша, максимальное и минимальное?

Выполняется раз в сутки:

/usr/bin/php /home/userNNN-NNN/www/mywebsite.com/cron.php

Минимальное время жизни кэша: Нет
Максимальное время: Нет
Кэширование блоков: выключено
Кэшировать страницы для анонимных пользователей:выключено
Объединение и сжатие файлов CSS: нет
Объединение файлов JavaScript: нет

Уже пару недель так и всёравно растет (было 70Мб, теперь 124Мб).

Аватар пользователя Dimaseo Dimaseo 30 мая 2011 в 16:48

Для запуска крона в семерке нужно передавать cron_key, который можно посмотреть в отчете о состоянии.
У Вас крон не работал.

Аватар пользователя MainVisor MainVisor 30 мая 2011 в 16:59

Dimaseo wrote:
Для запуска крона в семерке нужно передавать cron_key, который можно посмотреть в отчете о состоянии.
У Вас крон не работал.

Крон также ежедневно запускал вручную,

пока ничего не изменилось

Аватар пользователя MainVisor MainVisor 30 мая 2011 в 19:11

Softovick wrote:
А если установить максимальное время жизни, сутки например для кеша?

Не меняется, 1 день ставил на мин и макс, галочки везде, чистил кэш и обновлял до D 7.2

Всего размещено 1 из 999 возможных, использовано 100.00 из 100.00Мб и 22.56Мб за дополнительную плату.

Аватар пользователя Dimaseo Dimaseo 30 мая 2011 в 20:44

А phpmyadmin что кажет про таблицы? по скольку записей? Может все ферментировано? Дайте скрин таблиц. Вот не знаю есть-ли в mysql такое понятие как shrink..

Аватар пользователя MainVisor MainVisor 30 мая 2011 в 21:04

Dimaseo wrote:
А phpmyadmin что кажет про таблицы? по скольку записей? Может все ферментировано? Дайте скрин таблиц. Вот не знаю есть-ли в mysql такое понятие как shrink..

Размер базы данных phpmyadmin показывает меньше 30 Мб

Аватар пользователя Dimaseo Dimaseo 30 мая 2011 в 22:41

Угу как и предполагал..
Почитайте как сделать shrink.
В частности это

«Движок InnoDB не поддерживает уменьшение размеров файлов БД — это принципиальное ограничение. Единственный способ уменьшить размер БД — сделать дамп, переинициализировать хранилище, восстановить из дампа. Увы, это действительно так. »

Это значит, что если нагадили в таблицу на 30 мб то, даже после удаления записей из таблицы, файл будет весить 30 мб.

Аватар пользователя MainVisor MainVisor 30 мая 2011 в 23:06

Dimaseo wrote:
Угу как и предполагал..
Почитайте как сделать shrink.
В частности это

«Движок InnoDB не поддерживает уменьшение размеров файлов БД — это принципиальное ограничение. Единственный способ уменьшить размер БД — сделать дамп, переинициализировать хранилище, восстановить из дампа. Увы, это действительно так. »

Это значит, что если нагадили в таблицу на 30 мб то, даже после удаления записей из таблицы, файл будет весить 30 мб.

Был удивлен когда при переносе на новую площадку хостинга бд стала всего 30 мб, но это же проблема каждую неделю делать бэкап, удалять и восстанавливать, есть решение???

А что будет через несколько месяцев???

Аватар пользователя MainVisor MainVisor 30 мая 2011 в 23:33

neochief wrote:
"MainVisor" wrote:
А что будет через несколько месяцев???

Купите нормальный хостинг без ограничений по базе.

Ну будет размер базы упираться в общий размер 2-3 Гб. Через 1 год будет > 1.2 Гб только одного кэша, если не больше.

За месяц база данных увеличилась почти на 100 Мб, это при мизерной посещаемости!

Аватар пользователя Dimaseo Dimaseo 30 мая 2011 в 23:44

Нет, не будет.
Поясню:
записали 100 строк по мегабайту в таблицу - 100мб
отработал крон убило кеш - файл так и остался 100мб, но на это место будет записана другая инфа.
т.е. записали 30 строк по метру - все равно файл 100 мб, а не 130...

Меняйте хостинг.

Аватар пользователя MainVisor MainVisor 30 мая 2011 в 23:56

Dimaseo wrote:
Нет, не будет.
Поясню:
записали 100 строк по мегабайту в таблицу - 100мб
отработал крон убило кеш - файл так и остался 100мб, но на это место будет записана другая инфа.
т.е. записали 30 строк по метру - все равно файл 100 мб, а не 130...

Меняйте хостинг.

Не совсем понял, а почему у меня кэш постоянно растет? Именно самих файлов базы данных mysql
Разве на новом хостинге не будет так расти?

Или кэш не постоянно растет а до определенного значения? Если так, то может просто сменить тариф на дорогой с ограничем по базе 600 Мб на том же хостинге?

Аватар пользователя Dimaseo Dimaseo 31 мая 2011 в 0:25

"MainVisor" wrote:

Или кэш не постоянно растет а до определенного значения? Если так, то может просто сменить тариф на дорогой с ограничем по базе 600 Мб на том же хостинге?

до опред. значения
600 мб вполне хватит для среднего сайта.
P.S. если будет много нод не включайте модуль поиска - дох. отожрет..

Просто интересно, а сколько там стоит тариф с 600 мб под базы?

Аватар пользователя MainVisor MainVisor 31 мая 2011 в 0:37

Dimaseo wrote:
"MainVisor" wrote:

Или кэш не постоянно растет а до определенного значения? Если так, то может просто сменить тариф на дорогой с ограничем по базе 600 Мб на том же хостинге?

до опред. значения
600 мб вполне хватит для среднего сайта.
P.S. если будет много нод не включайте модуль поиска - дох. отожрет..

Просто интересно, а сколько там стоит тариф с 600 мб под базы?


200 рублей в месяц - IHC, буду менять хостинг

Спасибо за помощь, а то непонимал то ли баг D7, то ли хостинг кривой

Аватар пользователя VLAD.V VLAD.V 25 октября 2011 в 19:51

Из всего вышенаписаного сделаю вывод решения данного вопроса. Как я понял это все из за мусора в БД, база растягивается, но уменьшиться физически не может. Уменьшить ее можно сделав бекап, потом удалить БД, создать новую и из бекапа импортировать таблицы.
Или вообще ничего не делать, на место мусора записывается свежая инфа, и если ее не много, она не будет дальше растягивать БД.

Есть еще другой вариант, можно задать другой тип таблиц, вместо InnoDB сделать MyISAM. Как по умолчанию сделать MyISAM, я спросил тут http://www.drupal.ru/node/70475

Аватар пользователя mak-vardugin mak-vardugin 25 октября 2011 в 21:49

"VLAD.V" wrote:
Из всего вышенаписаного сделаю вывод решения данного вопроса.

нефиг браться за тов чем не разбирваешься, без особой надобности.

Это не предьява, а деперсонализированный результат размышлений.

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 25 октября 2011 в 22:01

"VLAD.V" wrote:
много бла бла бла

читать про оптимизацию таблиц у MyISAM и InnoDB, узнать из этой же статьи что у InnoDB нет оптимизации и что делать в данном случае.
Сделать выводы

Аватар пользователя lastuser lastuser 14 июня 2012 в 0:18

Движок InnoDB, я угадал? Все лечится довольно элегантно: ставится модуль DB Maintenance (вроде так называется), и по крону он делает OPTIMIZE TABLE всем таблицам, что некисло жмет размер таблиц. Для сравнения, на среднего размера сайте таблица watchdog под InnoDB за два дня разрастается на 12 гигов, после OPTIMIZE TABLE остается 50 метров.

Аватар пользователя Softovick Softovick 14 июня 2012 в 9:00

lastuser wrote:
Движок InnoDB, я угадал? Все лечится довольно элегантно: ставится модуль DB Maintenance (вроде так называется), и по крону он делает OPTIMIZE TABLE всем таблицам, что некисло жмет размер таблиц. Для сравнения, на среднего размера сайте таблица watchdog под InnoDB за два дня разрастается на 12 гигов, после OPTIMIZE TABLE остается 50 метров.

Ага, а потом в одно веселое утро просыпаемся и видим, что база порушена без возможности восстановления, а последний бекап делался в прошлом году. Сильно не рекомендую этот модуль. К тому же там делается не просто OPTIMIZE TABLE - это не работает в большинстве случаев на InnoDB.

Аватар пользователя Sirega Sirega 14 июня 2012 в 19:35

"Softovick" wrote:
Ага, а потом в одно веселое утро просыпаемся и видим, что база порушена без возможности восстановления

У меня стоит этот модуль, тупо поставил на оптимизацию все таблицы и работает пока нормально.

Аватар пользователя MainVisor MainVisor 16 июня 2012 в 23:21

"Softovick" wrote:
К тому же там делается не просто OPTIMIZE TABLE - это не работает в большинстве случаев на InnoDB.

Всмысле? optimize table стандартная фишка же

Аватар пользователя sendel sendel 10 ноября 2015 в 11:48

Таже проблема с IHC.ru

я решил проще, перевел все таблицы из формата INNODB в MYISAM. Самым безхитростным способом:

1. Скачал дамп БД
2. Открыл в текстовом редакторе (пр. Notepad++)
3. Сделал "Поиск и замена" строки ENGINE=InnoDB на ENGINE=MYISAM
4. Теперь ihc.ru видит что БД весит на 180мб, а лишь 12мб

Конечно поменять хостинг не проблема, но я уже проплатил за год и не хотелось пока мучаться с возвратом средств

Аватар пользователя AutoProf AutoProf 24 декабря 2012 в 13:08

"sendel" wrote:

Здравствуйте, спасибо сделал как Вы написали.
Да действительно БД уменьшилась в 8 раз, по скорости быстрее
1)скажите это как нибудь в дальнейшем может ухудшить работу сайта?
2)у меня опять возникла проблема, БД занимала 145 а через сутки 205, при этом объявлений не добавилось, а только обновлялись, при этом сами и хаотично, это я так понимаю неправильно что то прописано в обновлении.
Сайт www.autoprof.biz
Буду благодарен за помощь

Аватар пользователя bumble bumble 3 марта 2013 в 20:08

Всем советую смотреть сюда! http://www.drupal.ru/node/81591

В особенности вот на этот комментарий.
P.S. безграничная благодарность и хвала автору оного за великодушие и нежлобность перед форумчанами!

Аватар пользователя Urfin Urfin 20 марта 2013 в 12:07

У меня есть один сайт еще на старом двигуне 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 но процессы завершает.
Вот как-то так. Но все равно БД тупит.