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

Зачем WordPress нужен объектный кэш Redis

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

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

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

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

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

• VPS под управлением Linux с доступом к shell и правами sudo. Панель управления не требуется.
• WordPress, работающий через PHP-FPM, например, на базе стека LAMP в Ubuntu 24.04.
• Установленный WP-CLI. У каждого действия есть аналог в панели администратора, но версия для shell работает быстрее.
• 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, умноженное на реальный размер резидентного набора (RSS) одного рабочего процесса, что обычно составляет от 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 file отключен. Для чистого кэша объектов снимки не дают преимуществ. Данные по определению можно восстановить, а кэш, загруженный из файла двадцатиминутной давности, содержит устаревшие значения, которым 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 и политика вытеснения ключей применяются ко всему экземпляру 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 на том же сервере или в частной сети с задержкой менее миллисекунды. Насколько случай с локальным размещением выигрывает от работы ядра — отдельный вопрос: планировщик с учетом кэша, добавленный в Linux 7.2, пытается удерживать интенсивно взаимодействующие процессы, такие как PHP-FPM и Redis, на ядрах, разделяющих кэш, однако в виртуальной среде (VPS) это работает менее эффективно, чем на «железе».

Третья причина — огромная таблица автоматически загружаемых опций (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, вычтите размер MySQL buffer pool и буферы на каждое соединение, вычтите 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 недоступен или работает некорректно, а у вас нет доступа к панели администратора.