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

Один из моих сайтов в Drupal 7 имеет тысячи полей, несколько типов контента, более 25 просмотров и сотни (скоро будут тысячи) типов профилей. Из-за этого я использую основной патч, который лучше кэширует информацию о полях сущностей (http://drupal.org/node/1040790), и версию Views -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?

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

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

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

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

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

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

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

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

Используя 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обработку, которая может дополнительно ускорить процесс очистки кэша.}

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

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

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