БД весит 2 ГБ, а кешь под 20 ГБ. Это нормально и как бороться?

6 февраля 2023 в 12:24
Аватар пользователя VasyOK VasyOK 0 21

Приветствую специалистов в по big data, и базам данным Smile

Есть сайт с 120 тыс статей. Периодически пропадает место на сервере. Хостинг не предлагает докупить место, а предлагает лишь переехать на другой сервер, что уже несколько больше по деньгам чем 2 чебурека.
Размер БД сайта 2.3 ГБ. Но вот таблицы кеширования иногда неприлично выростают.

+-------------------------------------------------+-----------+
| Table                                           | Size (MB) |
+-------------------------------------------------+-----------+
| cache_page                                      |  11808.78 |
| cache_render                                    |   4111.88 |
| cache_dynamic_page_cache                        |   1770.48 |
| search_index                                    |   1283.00 |
| cache_data                                      |   1110.88 |
| node_revision__body                             |    896.55 |
| node__body                                      |    894.55 |

Насколько это нормально и как бороться.
Слышал решение, что выполняется команда очистки кеша раз в сутки, это приемлимо?

Комментарии

В Drupal 8/9/10 нет очистки кэша. Есть cache rebuild, то есть перестройка заново. Соответственно размер кэша ты не уменьшишь этим действием

6 февраля 2023 в 12:47

Есть же кнопка в admin/config/development/performance Очистка кеша. Нажимаю - таблицы уходят. Тоже самое через drush cr. Значит уменьшаю... Или как?

6 февраля 2023 в 13:39

Зачем в редис..Оперативная память нынче дорогая. Нужно настроить файловый кеш. Пускай на диске лежит.

https://www.drupal.org/project/filecache

Приветствую специалистов в по big data, и базам данным

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

6 февраля 2023 в 13:08

Зачем в редис..Оперативная память нынче дорогая. Нужно настроить файловый кеш. Пускай на диске лежит.

Затем, например, что будет ограничен размер и будет лишнее вымываться. Часто нет смысла хранить огромный кеш всего, что обходят иногда боты... В общем, случаи бывают очень разные, и нет одного хорошего рецепта кеширования.

7 февраля 2023 в 18:44

ivnish wrote: В Drupal 8/9/10 нет очистки кэша.

Точно? А как же кнопка Clear all caches на странице /admin/config/development/performance ?

ivnish wrote: Есть cache rebuild, то есть перестройка заново

Да ладно? То есть drush cr заново перегенерит все вьюхи со всеми возможными сочетаниями значений всех параметров? Это ж он месяц будет крутиться. Сомневаюсь я.

6 февраля 2023 в 13:18

marassa wrote: А как же кнопка Clear all caches

Ну по крайней мере я смотрел размер таблиц кэша в phpmyadmin и после сброса кэша размер таблиц не был равен 0, как ожидалось, а был примерно таким же как и до сброса кэша Unknw

6 февраля 2023 в 13:29

А ты смотри не мегабайты в таблицах, а строки. Есть в InnoDB такой прикол, что если таблица разрослась, то сколько её не чисти, она всегда будет занимать места по максимуму, пока не пересоздашь таблицу заново.

Чаще всего кэш пухнет из-за того, что крон не запускается. Если крон запускать, то он будет удалять протухшие записи из кэша.

6 февраля 2023 в 16:34

ivnish wrote: я смотрел размер таблиц кэша в phpmyadmin и после сброса кэша размер таблиц не был равен 0, как ожидалось, а был примерно таким же как и до сброса кэша

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

6 февраля 2023 в 13:38

Это хранилище вне базы данных твоего сайта. Но так же в оперативной памяти.

А ещё можно кэш как файлы положить. Там выше модуль скидывали

7 февраля 2023 в 14:46

Ок, пробую filecache.

По информации со страницы модуля добавляю в settings.php
$settings['cache']['default'] = 'cache.backend.file_system';
и получаю
The website encountered an unexpected error. Please try again later.

drush ws выдает:

In Container.php line 157:                                                                          
You have requested a non-existent service "cache.backend.file_system".

Что я не так делаю?

7 февраля 2023 в 18:27

Снова возвращаюсь к этому вопросу. Скажите: а насколько разумно очищать кеш на сайте каждый запуск крона?
А процесс очистки кеша он разве сам не происходит?
Поставил модуль ultimate_cron
Он выдает:
Cleanup (caches, batch, flood, temp-files, etc.) - Every 15 мин.

Я не понимаю зачем накапливать кеш, если каждые 15 минут его удалять.

13 мая 2023 в 13:23

Так мы немного уйдем в оффтоп. Увы не все хостинги предлагают гибкие тарифные планы. Конечно если будет сильно жать придется переходить на более мощный сервер. Но мне интересно:
120 тыс нод
2 ГБ БД
Которая с кешем разрастается до 50 ГБ и больше
Это нормально вообще? Или ну его нафиг этот Друпал, эти views и этого разработчика сайтов?

13 мая 2023 в 14:06

вопрос в последнем абзаце поставлен правильно. но надо сначала побороться за действующий сайт.
1. что я бы сделал это оптимизировал таблицы. и посмотрел насколько уменьшится БД. это делается либо
в пхпмайадмин либо
из командной строки:

You can USE mysqlcheck TO do this at the command line.
One DATABASE:
mysqlcheck -o <db_schema_name>
ALL DATABASES:
mysqlcheck -o --all-databases

либо самостоятельно через sql https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html
2. можно совсем отключить кэшь в друпале 9.5 или уменьшить время жизни. но это увеличит нагрузку на процессор.
3. если хостинг старый то надо переехать на ssd хостинг. redis ускоряет выдачу потомучто базу держит в оперативной памяти и по другому с ней работает. надо смотреть сколько оперативной памяти вам выделяется. желательно иметь столько сколько весит вся БД.
4. когда ничего не помогает то надо почитать документацию). https://dev.mysql.com/doc/refman/8.0/en/optimization.html
5. на этом сайте публиковалась статья успешной оптимизации БД. заплатить им чтобы все работало. деньги окупятся если не покупать новый хостинг. https://drupal.ru/node/145454
6. проверьте производительность сайта в хроме и безжалостно удалите все что устарело и мешает развиваться. новую версию можно переписать на js чтоб работала на стороне клиента.
7. почитайте про решения для высоконагруженных систем. какие приемы и системы используются. попробуйте внедрить хотябы часть из них.

на моем сайте БД 500Мб, 2000 страниц. 1,7гига файлов. хватает обычного хостинга за 3700р.

13 мая 2023 в 15:59

Проблема в том, что если крон не запускать, то устаревшие записи кэша остаются в базе. И наверняка под очисткой кэша по крону имеется в виду удаление устаревших записей, которые всё равно не используются, и висят мёртвым грузом.

13 мая 2023 в 19:22

Спасибо. Твой ответ достаточно лаконичный. Ок, примем что по умолчанию крон очищает устаревшие записи кеша.

14 мая 2023 в 12:21

Стоит еще проверить, в каком контексте кешируются страницы

Например, /catalog/something и /catalog/something-else - это совершенно разное содержимое страниц, и каждое должно лежать в кеше отдельно.

Далее - /catalog/something и /catalog/something?page=2 - это тоже разное содержимое, /catalog/something?page=2&items_per_page=10 и /catalog/something?page=2&items_per_page=20 тоже разное содержимое, т.е. get-параметры в url тоже играют роль.

Но - /catalog/something?page=2&items_per_page=10 и /catalog/something?items_per_page=10&page=2 это одно и то же содержимое, просто get-параметры перечислены в другом порядке.
Если кеш контекст формируется просто из строки url без ее разбора - то вот уже кеш и начал задваиваться.

Затем - в url могут встречаться utm-метки в виде /catalog/something?utm_source=xxxxx, причем у каждого пользователя эти utm-метки будут уникальные, именно так это и задумано, и получится, что для каждого пользователя создается свой экземпляр кеша для одной и той же страницы.

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

14 мая 2023 в 8:49