Настройка Redis для объектного кэша WordPress на VPS

Для чего нужен объектный кэш Redis в WordPress

Объектный кэш Redis для WordPress сохраняет результаты запросов к базе данных в оперативной памяти, поэтому при следующем запросе данные считываются из Redis, а не из MySQL. В ядре WordPress уже есть объектный кэш, WP_Object_Cache, но он существует только в памяти PHP и удаляется после завершения запроса. Специальный drop-in файл заменяет его на кэш, взаимодействующий с Redis, благодаря чему данные сохраняются между запросами.

Объектное кэширование — это не то же самое, что кэширование страниц, и понимание этой разницы определит, стоит ли вам следовать этому руководству. Кэш страниц сохраняет готовый HTML-код URL-адреса и отдаёт его повторно, не запуская PHP вообще. Это быстрее любого решения на базе Redis, и такой подход работает для неавторизованных посетителей. Как только пользователь входит в систему, добавляет товар в корзину или открывает панель администратора, кэш страниц отключается, и WordPress выполняет весь запрос целиком: загрузку ядра, плагинов и выполнение запросов. Объектный кэш делает такой запрос менее ресурсоёмким. Это инструмент для трафика, который не может обработать кэш страниц: сессии авторизованных пользователей, корзины, оформление заказов, wp-admin. В магазине на базе WooCommerce это большая часть наиболее «тяжёлого» трафика.

Эти два вида кэширования дополняют друг друга, и на нагруженном сайте нужны оба. Чётко определите, какую проблему вы решаете. Сайт-визитка с анонимными читателями получает почти весь прирост скорости от кэша страниц, и добавление Redis практически ничего не изменит.

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

Что потребуется для начала

• VPS под управлением Linux с доступом к оболочке и sudo. Панель управления не требуется.
• WordPress, работающий через PHP-FPM, например, на стеке LAMP в Ubuntu 24.04.
• Утилита WP-CLI на сервере. У каждого действия есть аналог в панели администратора, но версия для командной строки работает быстрее.
• Redis на той же машине, где запущен PHP. Низкая задержка — главная цель, а сетевой переход сводит её на нет.

Приведенные ниже команды написаны для Ubuntu 24.04 с PHP 8.3 и веб-пользователем www-data. Отрегулируйте версию PHP и имя пользователя в соответствии с настройками вашей системы. Выполняйте команды wp из корневого каталога WordPress, в котором находится файл wp-config.php.

Установка Redis и расширения PHP

sudo apt update
sudo apt install -y redis-server php-redis
sudo systemctl enable --now redis-server
redis-cli ping

redis-cli ping должен вернуть PONG. Если выводится Could not connect to Redis at 127.0.0.1:6379: Connection refused, значит сервер не запущен, поэтому ознакомьтесь с systemctl status redis-server, прежде чем продолжать.

php-redis — это PhpRedis, C-расширение из PECL. Оно работает быстрее, чем Predis, написанный на чистом PHP, и плагин использует его автоматически при наличии. PHP-FPM загружает расширения при запуске, поэтому новое расширение не будет видно, пока вы не перезапустите пул.

sudo systemctl restart php8.3-fpm
php -m | grep redis

Будьте внимательны с последней проверкой: php -m выводит список модулей для PHP в командной строке, а FPM может загружать другой набор. Решающей является проверка в диагностике самого плагина, которая приведена ниже.

По состоянию на август 2026 года в Ubuntu 24.04 поставляется Redis 7.0.15, чего достаточно для объектного кэширования. Если вам нужна более актуальная версия, Redis предоставляет собственный репозиторий APT.

sudo apt install -y lsb-release curl gpg
curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
sudo chmod 644 /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list
sudo apt update
sudo apt install -y redis

Если ваш дистрибутив поставляет Valkey — форк, созданный после изменения лицензии в 2024 году, — он использует тот же протокол, и всё описанное ниже применимо без изменений.

Привязка Redis для ограничения доступа

По умолчанию у Redis нет пароля. Любой, кто может установить соединение с портом 6379, способен прочитать все кэшированные значения и выполнить FLUSHALL. Экземпляры, доступные из Интернета, обнаруживаются сканерами в течение нескольких часов, поэтому настройка сети важнее оптимизации производительности.

Откройте /etc/redis/redis.conf и убедитесь в наличии следующих строк:

bind 127.0.0.1 -::1
protected-mode yes

Затем проверьте, что именно прослушивает порт, так как файл конфигурации — это лишь декларация, а ss — фактическое подтверждение.

sudo ss -lntp | grep 6379

127.0.0.1:6379 — это желаемый результат. 0.0.0.0:6379 означает, что Redis отвечает на публичном интерфейсе: исправьте строку bind и перезапустите службу.

Если PHP и Redis находятся на одном сервере, Unix-сокет предпочтительнее loopback TCP. В этом случае в пути передачи данных отсутствует TCP-стек, а доступ определяется правами доступа к файлу, а не правилами межсетевого экрана, которые можно случайно изменить в будущем.

unixsocket /run/redis/redis-server.sock
unixsocketperm 770

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

sudo systemctl restart redis-server
sudo usermod -aG redis www-data
sudo systemctl restart php8.3-fpm
redis-cli -s /run/redis/redis-server.sock ping

Эта команда также должна вывести PONG. Could not connect to Redis at /run/redis/redis-server.sock: Permission denied означает, что изменения группы не вступили в силу. Проверьте id www-data и помните, что запущенный процесс PHP-FPM сохраняет группы, которые были у него при старте, поэтому перезапуск обязателен. Оставьте TCP включенным, пока не убедитесь в работоспособности сокета, иначе опечатка может лишить вас обоих способов подключения одновременно.

Сколько памяти выделить для Redis?

Рассчитайте это значение исходя из характеристик вашего сервера. Redis без настройки maxmemory будет потреблять память до тех пор, пока она не закончится, после чего сработает OOM killer и завершит какой-либо процесс — обычно самый «тяжелый», которым на сервере с WordPress часто оказывается MySQL. journalctl -k | grep -i "out of memory" покажет факт завершения процесса уже постфактум, когда сайт будет недоступен.

Начните с общего объема RAM и вычтите из него необходимое. MySQL или MariaDB резервирует innodb_buffer_pool_size плюс буферы на каждое соединение. PHP-FPM потребляет pm.max_children, умноженные на реальный размер резидентной памяти одного воркера (обычно от 64 MB до 128 MB для сайтов с большим количеством плагинов). Ядру и веб-серверу также требуется несколько сотен мегабайт. Оставшийся объем — это ваш потолок, часть которого можно выделить для Redis.

Теперь переходите от догадок к измерениям. После дня работы под реальной нагрузкой:

redis-cli info memory | grep -E 'used_memory_human|maxmemory_human|maxmemory_policy'
redis-cli dbsize

Если used_memory_human значительно ниже вашего лимита, уменьшите его и верните память MySQL — она распорядится ею эффективнее. Если потребление упирается в лимит, а evicted_keys растет в течение дня, увеличьте его. Установите значение в /etc/redis/redis.conf.

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb применяется немедленно, но сбрасывается после перезагрузки — это та же ловушка, что и при использовании простого sysctl -w. Отредактируйте файл, затем sudo systemctl restart redis-server и проверьте значение снова. Стоит установить второй рубеж защиты: лимит MemoryMax в юните systemd не позволит неправильно настроенному Redis вывести сервер из строя. Установите его выше maxmemory, но никогда не делайте их равными, так как лимит cgroup принудительно завершит процесс, вместо того чтобы вытеснить ключ. Если Redis работает в контейнере рядом с WordPress, то же самое значение следует указать в лимитах памяти в вашем файле Compose, при этом те же соображения определяют выбор между запуском базы данных в Docker или на хосте.

Осознанный выбор политики вытеснения

В свежеустановленном Redis по умолчанию используется noeviction. Проверьте свою настройку:

redis-cli config get maxmemory-policy

При noeviction экземпляр полностью перестает принимать записи и отвечает следующим сообщением:

(error) OOM command not allowed when used memory > 'maxmemory'.

Эта единственная строка — худший сценарий сбоя в данном руководстве, так как сайт не падает, а просто начинает работать медленнее. Каждая попытка записи в кэш завершается неудачей, поэтому WordPress обращается за данными в базу данных, а затем пытается снова сохранить их при следующем запросе и снова получает отказ. В итоге сайт тратит ресурсы на выполнение всех исходных запросов к базе данных плюс на каждый сетевой запрос к Redis для каждого ключа. В панели администратора WordPress нет никаких уведомлений об этой проблеме. Эта строка появляется в журнале ошибок PHP, поэтому используйте grep для поиска OOM command not allowed, если сайт замедлился после настройки кэширования.

allkeys-lru — правильный выбор по умолчанию в данном случае. Redis удаляет ключ, который дольше всего не использовался, когда память заканчивается. Это именно то, что нужно для объектного кэша, так как каждое значение в нем — это копия данных, которые все еще существуют в MySQL. Потеря ключа стоит одного запроса к БД. Отказ в записи стоит выполнения всех запросов при каждом обращении, пока кто-то не заметит проблему.

Избегайте политик volatile-* для этой задачи. Они учитывают только ключи с установленным сроком действия, и, как указано в документации Redis, ведут себя как noeviction, если таких ключей нет. WordPress хранит большинство записей объектного кэша без TTL, поэтому volatile-lru при использовании в качестве объектного кэша может привести к заполнению памяти и отказу в записи. allkeys-lfu — неплохая альтернатива, если ваш трафик часто обращается к небольшому набору ключей, так как вытеснение происходит на основе частоты, а не времени последнего использования. Выберите политику осознанно и задокументируйте причину своего выбора.

Персистентность: отключайте, если нет веских причин

Поставляемый в пакете redis.conf включает RDB-снимки с помощью директив вида save 900 1 и оставляет append-only файл отключенным. Для чистого кэша объектов снимки не дают преимуществ. Данные по определению можно восстановить, а кэш, загруженный из файла двадцатиминутной давности, содержит устаревшие значения, которым WordPress будет доверять.

Снимки также требуют ресурсов. BGSAVE выполняет fork процесса, а механизм copy-on-write может привести к резкому росту потребления памяти во время записи дочерним процессом. На небольшом VPS это отражается в логе Redis:

Can't save in background: fork: Cannot allocate memory

и часто сопровождается предупреждением при запуске, которое означает, что Redis ожидает сбой fork в будущем:

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition.

Чтобы отключить снимки, установите пустое расписание сохранения в /etc/redis/redis.conf, перезапустите сервис и убедитесь, что значение стало пустым.

save ""

sudo systemctl restart redis-server
redis-cli config get save

Сохраняйте персистентность только в том случае, если в этом же экземпляре хранятся данные, которые невозможно восстановить, например, очередь задач или счетчики ограничения частоты запросов (rate-limit). В таком случае разделите их. Кэш требует вытеснения ключей, а для долговечных данных ключи должны сохраняться, при этом maxmemory и правила вытеснения применяются ко всему экземпляру, а не к отдельному индексу базы данных. Использование двух экземпляров на разных сокетах — правильное решение.

Установка плагина и понимание принципа работы drop-in

wp plugin install redis-cache --activate
wp redis enable
wp redis status

wp redis enable выводит Object cache enabled. в случае успеха. Фактически команда копирует wp-content/plugins/redis-cache/includes/object-cache.php в wp-content/object-cache.php. Эта копия и является drop-in файлом, который выполняет основную работу. WordPress загружает wp-content/object-cache.php на очень раннем этапе, еще до выполнения кода любого плагина, благодаря чему кэш доступен на протяжении всего запроса. Активный плагин без установленного drop-in файла ничего не кэширует.

Сообщения об ошибках указывают, на каком этапе произошел сбой. Object cache could not be enabled. означает, что копирование не удалось, так как wp-content недоступен для записи пользователем, от имени которого запущен WP-CLI. A foreign object cache drop-in was found. означает, что этот файл уже занят другим плагином кэширования; для исправления используйте wp redis update-dropin. Сообщение, заканчивающееся на Redis server is unreachable:, за которым следует ошибка клиента, указывает на неверные настройки подключения — вернитесь к redis-cli ping.

Если копирование не удалось из-за прав доступа, разместите файл вручную и передайте его владельцу, под которым работает веб-сервер.

cp wp-content/plugins/redis-cache/includes/object-cache.php wp-content/object-cache.php
sudo chown www-data:www-data wp-content/object-cache.php

Удаление плагина не приводит к удалению drop-in файла. Сначала выполните wp redis disable: команда выведет Object cache disabled. и удалит файл. Если удалить директорию плагина, оставив drop-in файл на месте, сайт продолжит использовать старый код кэширования, который больше не будет обновляться плагином.

Настройки подключения в wp-config.php

Добавьте их перед строкой /* That's all, stop editing! */, так как константы, определенные после нее, не будут обработаны.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'shop_prod:' );

Для Unix-сокета укажите схему и путь. В этом случае параметры host и port игнорируются.

define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/run/redis/redis-server.sock' );
define( 'WP_REDIS_PREFIX', 'shop_prod:' );

WP_REDIS_MAXTTL принудительно задает время жизни для каждого ключа в секундах. Этот параметр не требуется при использовании allkeys-lru, но он полезен, если вы хотите установить жесткий верхний предел устаревания кэшированных значений.

Один Redis, несколько сайтов: префиксы и базы данных

По умолчанию Redis предоставляет шестнадцать нумерованных баз данных, каждая из которых содержит единое плоское пространство ключей. Если две установки WordPress используют базу данных 0 без указания префикса, они записывают ключи с одинаковыми именами в одно и то же пространство. В результате один сайт может прочитать настройки другого и использовать их. Назначайте каждому сайту собственный префикс.

define( 'WP_REDIS_PREFIX', 'shopA_prod:' );
define( 'WP_REDIS_DATABASE', 1 );

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

Префиксы и индексы не разделяют память. Параметр maxmemory и политика вытеснения (eviction policy) применяются ко всему экземпляру Redis целиком. Активный сайт может вытеснить ключи менее нагруженного сайта, при этом ни один из них не сообщит об ошибке. Если сайты не должны влиять друг на друга, используйте отдельные экземпляры Redis, каждый со своим сокетом и собственным лимитом памяти.

Изоляция кэша staging-среды от production

Staging-сайт обычно является копией файлов и базы данных production, что означает копирование wp-config.php с тем же префиксом и тем же индексом базы данных. Если направить его на тот же Redis, он будет перезаписывать ключи production значениями из staging. В результате тестовая цена или измененная опция появятся на рабочем сайте без деплоя и каких-либо следов.

Задавайте уникальные префиксы для каждой среды вручную. В wp-config.php для staging:

define( 'WP_REDIS_PREFIX', 'shop_staging:' );
define( 'WP_REDIS_DATABASE', 5 );

Еще лучше — предоставьте staging собственный экземпляр Redis или вообще отключите объектный кэш. define( 'WP_REDIS_DISABLED', true ); отключает кэш во время выполнения, оставляя drop-in файл на месте; это также самый быстрый способ проверить, связан ли баг с кэшем.

В старых руководствах для этого устанавливается WP_CACHE_KEY_SALT. В readme плагина эта константа помечена как устаревшая и замененная на WP_REDIS_PREFIX, поэтому используйте новое имя.

Проверяйте, а не доверяйте

Начните с собственной диагностики плагина.

wp redis status

Наиболее важная строка — Drop-in. Drop-in: Valid означает, что WordPress загружает файл этого плагина. Drop-in: Not installed означает, что копирование не произошло и на сайте нет постоянного кэша, как бы зелено ни выглядел экран администратора. Status сообщает о соединении, а Client указывает используемое расширение; здесь вы можете убедиться, что используется PhpRedis, а не Predis.

Затем обратитесь напрямую к ядру WordPress, так как ему не важно, что «думает» плагин.

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) означает, что ядро взаимодействует с внешним объектным кэшем.

Затем докажите, что ключи поступают, используя настроенный вами префикс.

redis-cli -n 0 dbsize
redis-cli -n 0 --scan --pattern 'shop_prod:*' | head

dbsize, увеличивающееся во время ваших переходов по сайту, является доказательством. Нулевое количество ключей при наличии корректного drop-in файла означает, что соединение молча обрывается или префикс не тот, который вы предполагаете.

Наконец, посмотрите на показатели, которые Redis собирает для вас.

redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses|evicted_keys|expired_keys'

Коэффициент попаданий — keyspace_hits / (keyspace_hits + keyspace_misses), формула для него приведена в документации Redis. Учитывайте два предостережения. Счетчики охватывают весь экземпляр с момента последнего перезапуска, поэтому они объединяют данные всех сайтов и приложений, использующих его. Кроме того, коэффициент сразу после очистки или перезапуска не имеет значения, так как кэш еще заполняется. Дайте системе поработать в течение обычного дня с типичным трафиком.

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

curl -o /dev/null -s -w '%{time_starttransfer}\n' -b cookies.txt https://example.com/my-account/

Запустите это с файлом cookie авторизованного пользователя, несколько раз, сначала с выключенным кэшем (WP_REDIS_DISABLED), а затем с включенным. Разница между ними и будет вашим результатом.

Когда Redis замедляет работу WordPress

Основная причина — переполнение экземпляра из-за неверной политики, описанной выше: OOM command not allowed when used memory > 'maxmemory'. в логах, когда сайт вынужден обращаться и к базе данных, и к кэшу одновременно.

Вторая причина — размещение Redis на другом хосте. WordPress выполняет сотни вызовов объектного кэша за один запрос. Если запрос делает 500 вызовов, и каждый сетевой обмен занимает 1 мс, это добавляет полсекунды ожидания, которых не было бы при использовании локального сокета. Держите Redis на том же сервере или в частной сети с задержкой менее миллисекунды.

Третья причина — огромная таблица автоматически загружаемых опций (autoloaded options), что часто встречается на старых сайтах. WordPress кэширует все такие опции как один ключ, поэтому мегабайт данных передаётся через соединение при каждом запросе. Проверьте это:

wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024) AS kb FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on');"

В WordPress 6.6 появились новые значения для автозагрузки, поэтому старые запросы, учитывающие только 'yes', показывают неполную картину на современных установках. Если объём превышает мегабайт, проблему нужно решать в таблице опций, а не в Redis.

Перезапуск очищает всё содержимое, поэтому в течение нескольких минут после systemctl restart redis-server все запросы будут промахами кэша, что создаст нагрузку на базу данных. Перезапускайте сервис в часы низкой посещаемости. Кроме того, объектный кэш не предотвращает выполнение wp-cron.php при загрузке страниц пользователями, что само по себе замедляет запросы: перенесите WP-Cron на системный cron во время выполнения этих работ.

Обслуживание

Выполняйте очистку после развертывания, которое изменяет параметры или код темы, с помощью wp cache flush. Запускайте wp redis update-dropin после обновления плагина, если drop-in не обновился автоматически, так как использование drop-in от старой версии плагина с новой версией часто приводит к некорректной работе. Мониторьте работающий сервер с помощью redis-cli --stat, которая выводит одну строку в секунду. redis-cli monitor выводит каждую команду и потребляет значительные ресурсы CPU на нагруженном экземпляре, поэтому используйте её в течение нескольких секунд для воспроизведения проблемы, а затем останавливайте.

Последний показатель, который стоит знать: redis-cli info clients сообщает connected_clients. PHP-FPM удерживает по одному соединению на каждый worker, поэтому это число должно соответствовать вашему pm.max_children и не превышать его на порядок. Если это происходит, значит, какой-то процесс открывает соединения и не закрывает их.

FAQ

Нужен ли мне page cache, если я использую объектный кэш Redis?

Да, для анонимного трафика. Page cache отдает сохраненный HTML без выполнения PHP, что всегда менее ресурсоемко, чем работа WordPress даже с прогретым объектным кэшем. Объектный кэш обрабатывает запросы, которые page cache вынужден пропускать: авторизованные пользователи, корзины, оформление заказа и wp-admin. В интернет-магазинах или на сайтах с личными кабинетами стоит использовать оба решения. На сайтах, где посетители никогда не авторизуются, page cache выполняет почти всю работу.

Сколько памяти выделить Redis для WordPress?

Определяйте объем исходя из ресурсов вашего сервера, а не копируйте значения из инструкций. Возьмите общий объем RAM, вычтите размер buffer pool для MySQL и буферы на каждое соединение, вычтите pm.max_children, умноженное на резидентный размер одного процесса PHP-FPM, и вычтите несколько сотен мегабайт для ядра и веб-сервера. Выделите Redis часть того, что осталось, а затем проверьте used_memory_human в redis-cli info memory после дня работы под нагрузкой и скорректируйте значение. Одиночный сайт на WordPress обычно занимает десятки мегабайт, поэтому 256 MB maxmemory — это щедрый объем для старта на сервере с 4 GB RAM.

Почему мой сайт стал работать медленнее после включения объектного кэша Redis?

Обычно причина в переполнении экземпляра Redis при использовании политики noeviction. Redis отклоняет новые записи и возвращает ошибку OOM command not allowed when used memory > 'maxmemory'., поэтому WordPress вынужден обращаться к базе данных для получения каждого значения, при этом тратя время на лишний сетевой запрос к Redis. Проверьте redis-cli config get maxmemory-policy, установите allkeys-lru и убедитесь, что maxmemory не слишком мал. Другие частые причины — размещение Redis на удаленном хосте, где сотни сетевых запросов на одну страницу суммарно дают большую задержку, или наличие многомегабайтных значений в автозагружаемых опциях, которые передаются через соединение при каждом запросе.

Могут ли несколько сайтов на WordPress использовать один сервер Redis?

Могут, но с осторожностью. Назначьте каждому сайту уникальный WP_REDIS_PREFIX, чтобы ключи не конфликтовали, и отдельный индекс WP_REDIS_DATABASE, чтобы очистка кэша одного сайта не затрагивала другой. Память остается общей: maxmemory и политики вытеснения применяются ко всему экземпляру, поэтому активный сайт может вытеснить ключи менее нагруженного сайта. Сайты, которые не должны влиять друг на друга, требуют отдельных экземпляров Redis с собственными лимитами.

Безопасно ли удалять wp-content/object-cache.php?

Да. Это подключаемый модуль (drop-in), он не является частью ядра WordPress, и его удаление возвращает WordPress к встроенному кэшированию в рамках одного запроса. Сайт продолжит работать, просто возрастет количество запросов к базе данных. Рекомендуется использовать wp redis disable, который корректно удаляет файл и сообщает Object cache disabled.. Удаление вручную — верное экстренное решение, если Redis недоступен или работает некорректно, а у вас нет доступа к панели администратора.