6 февраля 2023 в 12:24
Приветствую специалистов в по big data, и базам данным 
Есть сайт с 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 |
| 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 |
Насколько это нормально и как бороться.
Слышал решение, что выполняется команда очистки кеша раз в сутки, это приемлимо?
Комментарии
В твоем случае нужно положить кэш в redis. Это уменьшит вес БД (а это важно для бэкапа, например).
В Drupal 8/9/10 нет очистки кэша. Есть cache rebuild, то есть перестройка заново. Соответственно размер кэша ты не уменьшишь этим действием
Есть же кнопка в admin/config/development/performance Очистка кеша. Нажимаю - таблицы уходят. Тоже самое через drush cr. Значит уменьшаю... Или как?
Зачем в редис..Оперативная память нынче дорогая. Нужно настроить файловый кеш. Пускай на диске лежит.
https://www.drupal.org/project/filecache
Не...бигдата..- это когда на планете живет 9 миллиардов а тебе говорят..Умножь это число на квадриллион и посчитай пуговицы на каждом левом ботинке..
В итоге ты узнаешь сколько пуговиц будет на левом ботинке через миллиард лет на планете если население продолжит увеличиваться такими темпами
И насколько меньше файловый кеш, чем записи в БД?
Просто это может быть удобнее. Но это не быстрее, и не компактнее.
Затем, например, что будет ограничен размер и будет лишнее вымываться. Часто нет смысла хранить огромный кеш всего, что обходят иногда боты... В общем, случаи бывают очень разные, и нет одного хорошего рецепта кеширования.
Точно? А как же кнопка Clear all caches на странице /admin/config/development/performance ?
Да ладно? То есть drush cr заново перегенерит все вьюхи со всеми возможными сочетаниями значений всех параметров? Это ж он месяц будет крутиться. Сомневаюсь я.
Ну по крайней мере я смотрел размер таблиц кэша в phpmyadmin и после сброса кэша размер таблиц не был равен 0, как ожидалось, а был примерно таким же как и до сброса кэша
А ты смотри не мегабайты в таблицах, а строки. Есть в InnoDB такой прикол, что если таблица разрослась, то сколько её не чисти, она всегда будет занимать места по максимуму, пока не пересоздашь таблицу заново.
Чаще всего кэш пухнет из-за того, что крон не запускается. Если крон запускать, то он будет удалять протухшие записи из кэша.
У меня были другие результаты - размер таблиц падал практически до нуля, и бэкап, который перестал помещаться на диске, внезапно стал помещаться.
Хорошо, в 2-х словах: что такое redis? Это что: хранилище данных вне сервера рабочего сайта?
Это хранилище вне базы данных твоего сайта. Но так же в оперативной памяти.
А ещё можно кэш как файлы положить. Там выше модуль скидывали
Ок, пробую filecache.
По информации со страницы модуля добавляю в settings.php
$settings['cache']['default'] = 'cache.backend.file_system';и получаю
The website encountered an unexpected error. Please try again later.drush ws выдает:
You have requested a non-existent service "cache.backend.file_system".
Что я не так делаю?
Снова возвращаюсь к этому вопросу. Скажите: а насколько разумно очищать кеш на сайте каждый запуск крона?
А процесс очистки кеша он разве сам не происходит?
Поставил модуль ultimate_cron
Он выдает:
Cleanup (caches, batch, flood, temp-files, etc.) - Every 15 мин.
Я не понимаю зачем накапливать кеш, если каждые 15 минут его удалять.
стоимость 2 чебурека это сколько? Большому сайту нужны больше мощности.
Так мы немного уйдем в оффтоп. Увы не все хостинги предлагают гибкие тарифные планы. Конечно если будет сильно жать придется переходить на более мощный сервер. Но мне интересно:
120 тыс нод
2 ГБ БД
Которая с кешем разрастается до 50 ГБ и больше
Это нормально вообще? Или ну его нафиг этот Друпал, эти views и этого разработчика сайтов?
вопрос в последнем абзаце поставлен правильно. но надо сначала побороться за действующий сайт.
1. что я бы сделал это оптимизировал таблицы. и посмотрел насколько уменьшится БД. это делается либо
в пхпмайадмин либо
из командной строки:
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р.
Проблема в том, что если крон не запускать, то устаревшие записи кэша остаются в базе. И наверняка под очисткой кэша по крону имеется в виду удаление устаревших записей, которые всё равно не используются, и висят мёртвым грузом.
Спасибо. Твой ответ достаточно лаконичный. Ок, примем что по умолчанию крон очищает устаревшие записи кеша.
Стоит еще проверить, в каком контексте кешируются страницы
Например, /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-метки будут уникальные, именно так это и задумано, и получится, что для каждого пользователя создается свой экземпляр кеша для одной и той же страницы.
В общем, надо разбираться, в каком контексте кешируются страницы, это первая причина неконтролируемого роста кеша.