Стратегии экономии памяти и очистки кэша для больших сайтов?

На одном из моих сайтов Drupal 7 есть тысячи полей, множество типов контента, более 25 просмотров и сотни (скоро будут тысячи) типов профилей. Из-за этого я использую основной патч, который лучше кэширует информацию о поле сущности (http://drupal.org/node/1040790 ), и версия представлений -dev, которая лучше кэширует представления по отображению (вместо того, чтобы иметь одну ОГРОМНУЮ строку кэша представлений со всеми данными представлений в ней).

Это помогло большинству страниц на сайте загружаться с Использовалось 20-30 МБ оперативной памяти, а не 160 МБ+ (вместо того, чтобы извлекать строки таблицы cache_* для полей и представлений, размер которых составлял 10 МБ+, исправления помогают сохранять данные cache_* намного эффективнее).

Это создает проблему, однако, в том, что перестройка кэша занимает очень много времени. Обычно больше минуты или двух. И в течение этого времени Drupal просто не будет загружать никаких страниц (поскольку кэши, из которых он пытается читать, еще не созданы, другие запросы должны подождать).

Во время циклы с низким трафиком, это не имеет большого значения; сотне или около того пользователей просто придется подождать минуту, прежде чем страница загрузится. Но во время циклов с высоким трафиком сервер Apache начинает сходить с ума при загрузке процессора 40+, и память быстро заполняется, потому что все рабочие потоки сидят в ожидании и исчерпывают свою память, вызывая замену. Это своего рода смертельная спираль. Перезапуск httpd прояснит ситуацию, но потребуется 5-10 минут, чтобы все вернулось в нормальное русло.

Моя цель - сделать так, чтобы очистка кэша не ставит сайт на колени. Во-первых, если я использую отдельные функции очистки кэша admin_menu (например, "CSS и JS", затем "Меню", затем "Реестр тем" и т. Д.), Все идет гладко, пока я не нажму на опцию "Страница и остальное". Это происходит, когда кэш представлений сбрасывается (очень интенсивная работа с ЦП и базой данных с количеством представлений, которые необходимо кэшировать), и когда кэш информации о полях сбрасывается (что также является интенсивным для ЦП и базы данных на этом сайте).

Итак... мой вопросы/идеи:

  • Используя drush и/или другие сценарии оболочки, могу ли я очистить кэши более разумным способом, чем "взорвать все кэши сразу и надеяться на чистое восстановление"?
  • Могу ли я блокировать http-запросы во время очистки кэша, чтобы apache не был забит кучей запросов, вызывающих панику в кэше?
  • Если я смогу очистить кэш за пределами Drupal/обычного запроса httpd, я мог бы предположительно установить более высокий PHP memory_limit для очистки кэша операция, и отключите мой универсальный memory_limit (сейчас установлено значение 256 МБ, на случай, если какому-либо отдельному потоку httpd потребуется очистить кэш...).

В принципе: Есть ли какой-либо разумный и изящный способ очистить все кэши с помощью Drupal, кроме простого нажатия кнопки в пользовательском интерфейсе или использования drush cc all?

[ Редактировать для уточнения: Основная проблема, с которой я сталкиваюсь, - это перестроение кэша, которое (а) занимает некоторое время и (б) блокирует все другие запросы до завершения перестроений. Я хотелось бы найти способ сделать так, чтобы перестройки не были такими смертоносными во время интенсивного движения.]

Author: geerlingguy, 2012-11-08
Source

4 answers

Существует ли какой-либо разумный и изящный способ очистить все кэши с помощью Drupal, кроме простого нажатия кнопки в пользовательском интерфейсе или использования drush cc all?

Модуль действия кэша делает это. Это зависит от правила. Например, вы можете настроить правило для очистки определенного представления при добавлении или обновлении узла типа "x". Проверьте документы для получения более подробной информации.

Также взгляните на модуль кэширования - еще не пробовал, но выглядит интересно.

 10
Author: uwe, 2012-11-17 02:14:04

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

Я советую вместо этого использовать Memcache. Это значительно повысит производительность системы кэширования и даст вам 2 больших преимущества:

  1. Memcache намного быстрее для операций чтения и записи, чем MySQL - все ваши операции кэширования (и полное восстановление кэша) будут работать быстрее.
  2. Поскольку данные кэша больше не хранятся в БД - очистка кэш не будет блокировать никакие другие запросы MySQL.

Вот пример Конфигурации Memcache для Drupal 7.

 3
Author: Eugene Fidelin, 2012-11-14 09:13:19

Используя drush и/или другие сценарии оболочки, могу ли я очистить кэши более разумным способом, чем "взорвать все кэши сразу и надеяться на чистое восстановление"?

Если вы не хотите взламывать все кэши, используйте: drush cc type_of_cache для очистки определенного или определите свой собственный.

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

echo "SHOW TABLES LIKE 'cache%'" | $(drush sql-connect) | tail -n +2 | xargs -L1 -I% echo "DELETE FROM %;" | $(drush sql-connect) -v

Если вы используете memcached (синтаксис Bash), попробуйте: 

pgrep memcached && echo flush_all > /dev/tcp/127.0.0.1/11211

Могу ли я блокировать http-запросы в то время как происходит очистка кэша, чтобы apache не засорялся кучей запросов на кэширование?

Включите режим обслуживания (drush -y vset maintenance_mode 1), чтобы запретить людям доступ к сайту. Или настройте интерфейс для перенаправления в другое место (например, в Varnish, перенаправление в Apache или изменение .htaccess).

Если я смогу очистить кэш за пределами Drupal/обычного запроса httpd, я, вероятно, мог бы установить более высокий PHP memory_limit для операции очистки кэша и отказаться от своего универсального memory_limit (прямо сейчас установите значение 256 МБ, на случай, если какому-либо отдельному потоку httpd потребуется очистить кэш...).

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

time php -n -d memory_limit=-1 time $(which drush) cc registry
PHP_OPTIONS='-d memory_limit="2G"' drush cron
php -d memory_limit=1G ./scripts/drupal.sh http://localhost/

Укажите -n, чтобы игнорировать обработку php.ini, которая может дополнительно ускорить процесс очистки кэша.

 1
Author: kenorb, 2016-03-24 16:32:36

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

Недостаток: в зависимости от того, сколько секунд/минут простоя рабочего сервера по сравнению с вашими настройками времени ожидания VCL, Varnish может обновиться в течение этого времени, и вы увидите экран ошибки Varnish 503.

Но этот подход вдоль с помощью Redis или Memcache может помочь.

 0
Author: mulderjoe, 2015-07-08 16:40:17