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


30

Один из моих сайтов в 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?

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


2
Интересный вопрос. Если вы отключите кэширование, будет ли производительность вашего сайта достаточной? Итак, вы оптимизировали Apache / PHP / MySQL для работы, так как он может быть включен без кэширования? Очевидно, я не видел вашу систему, но установка apc.stat = 0 и проверка наличия достаточного объема памяти для APC поможет сократить использование диска. Использование mysqltuner.pl также покажет, является ли MySQL узким местом. Затем вы можете включить кэширование и настроить (это увеличит использование БД, поэтому вам может потребоваться настроить параметры MySQL).
mpdonadio

Я использую Redis (похожий на memcache) для хранения таблиц кэша представлений в памяти. Это значительно улучшило время загрузки. Надеемся, что в стабильном выпуске появится функция «Кэширование представлений», что имеет большой смысл.
Uwe

@MPD - отключение кэширования быстро убьет весь сайт; обычно 100-500 аутентифицированных пользователей, а некоторые разделы сайта довольно тяжелые. Самая большая проблема для меня - не чтение кеша (для этого я экспериментировал с кешем Memcached, Redis и APC), а с перестройкой кеша, которая сильно загружает процессор.
geerlingguy

В идеале вы хотите использовать старые данные кеша, пока новый кеш перестраивается. Это верно?
mikeytown2

@ mikeytown2 - правильно - это было бы идеально.
geerlingguy

Ответы:


9

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

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

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


Я уже использую его drush cc [type]для очистки конкретного кеша (аналогично действиям в кеше), но меня больше интересует поиск путей более изящной очистки кеша и обеспечение того, чтобы другие потоки httpd не убивали сервер Apache.
geerlingguy

1
похоже, что drush cc очистит все кэши представлений. С помощью действий кэша вы можете просто очистить конкретный вид или отображение. Вероятно, в версии views есть ошибка, иначе восстановление кешей займет не одну или две минуты. У вас есть та же проблема с использованием представлений 7.x-3.5? Также взгляните на drupal.org/project/cache_graceful - еще не пробовал, но выглядит интересно
uwe

Представления dev разбивает отображения представлений на собственные строки кэша, чтобы повысить производительность чтения кэша. Это означает, что представления тратят, вероятно, в 5 раз больше времени на создание кэша (но это помогает уменьшить использование памяти при очень большом чтении кэшей!).
geerlingguy

Не могли бы вы добавить информацию о Cache Graceful в ваш оригинальный ответ? Я приму это, поскольку этот конкретный модуль немного помогает (но не решает проблему полностью для меня). Я думаю, что мне придется немного изменить архитектуру сайта, чтобы использовать меньше полей и типов сущностей, чтобы действительно решить мою проблему.
geerlingguy

хорошо. Мне было бы интересно услышать о вашем опыте с cache_graceful. Какую часть это не исправить?
Uwe

2

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

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

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

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


Я использовал memcached и APC по-разному, и хотя они очень помогают при чтении из кэша, главная проблема, которую я имею, - это реальная перестройка; база данных почти ничего не делает, пока веб-сервер штампует кеш во время (очень медленного / длинного) процесса перестройки.
geerlingguy

APC и Memcached делают разные вещи. Я думаю, что правильная конфигурация Memcached поможет вам. Кстати, если ваш сайт в основном посещают анонимные пользователи - вы можете использовать Varnish. В этом случае Varnish будет использовать свою собственную систему кэширования, и Apache не будет выполняться для анонимных запросов.
Евгений Фиделин

На сайте почти 100% аутентифицированный трафик, в противном случае я бы подумал об использовании Varnish. Я мог бы заглянуть в модуль Cache Graceful на этом этапе.
geerlingguy

0

Используя 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

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

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

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


Этот вопрос относится только к внутренним кешам Drupal; перестройка кешей Drupal заняла вечность, и дополнительные уровни кеширования вне / перед Drupal не сильно помогли бы фактической перестройке данных кеша (кроме разгрузки некоторого трафика, который в противном случае веб-серверу пришлось бы удерживать некоторое время, пока кешировались перестроены).
geerlingguy

В этом случае я обнаружил, что Zend OpCache работает хорошо. :-)
mulderjoe
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.