VPSでWordPressにRedisオブジェクトキャッシュを設定

WordPress で Redis オブジェクトキャッシュが行うこと

WordPress 用の Redis オブジェクトキャッシュは、データベースクエリの結果をメモリに保存します。次回のリクエストでは、MySQL に再度問い合わせず、Redis から結果を読み取ります。WordPress にはコアにオブジェクトキャッシュがすでにありますが、WP_Object_Cache、これは PHP のメモリ上で動作し、リクエストが終了すると破棄されます。drop-in ファイルでこのキャッシュを Redis と通信するものに置き換えると、キャッシュがリクエスト間で保持されます。

オブジェクトキャッシュはページキャッシュではありません。この違いによって、このガイドが必要かどうかが決まります。ページキャッシュは URL の完成済み HTML を保存し、PHP をまったく実行せずに再度配信します。これは Redis が行える処理より高速で、ログインしていない訪問者にも機能します。誰かがログインしたり、商品をカートに入れたり、管理画面を開いたりすると、ページキャッシュは使われなくなり、WordPress がブートストラップ、プラグイン、クエリを含むリクエスト全体を実行します。オブジェクトキャッシュは、そのリクエストの処理を軽くします。これは、ページキャッシュが処理できないトラフィック、つまりログイン中のセッション、カート、チェックアウト、wp-admin に適した機能です。WooCommerce のショップでは、負荷の高いトラフィックの大部分がこれに該当します。

この2つは併用できます。負荷の高いサイトでは、両方を使う必要があります。どの問題を解決するのかを明確にしてください。匿名の閲覧者が利用するだけの案内サイトでは、速度の大部分をページキャッシュで改善できます。Redis を追加しても、変化はほとんどありません。

開始する前に、1つだけ明確にしておきます。オブジェクトキャッシュは、遅いクエリ自体を高速化しません。すでに実行されたクエリの再実行をなくします。キャッシュミス後の最初のリクエストでは、クエリの処理コストをそのまま負担します。そのため、インデックスのないクエリを実行するプラグインは、キャッシュの有効期間ごとに少なくとも1回はそのクエリを実行します。

最初に必要なもの

• シェルと sudo を利用できる Linux VPS。コントロールパネルは必要ありません。
• PHP-FPM で配信している WordPress。たとえば、Ubuntu 24.04 上の LAMP スタックです。
• サーバーに WP-CLI がインストールされていること。ここで説明するすべての手順には管理画面から行う方法もありますが、シェルのほうが高速です。
• PHP と同じマシン上の Redis。低遅延が目的なので、ネットワークを経由すると効果が失われます。

以下のコマンドは、PHP 8.3 と www-data Web ユーザーを使用する Ubuntu 24.04 向けです。サーバーに合わせて PHP のバージョンとユーザーを調整してください。wp コマンドは、wp-config.php を格納している WordPress ディレクトリから実行してください。

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 は PECL の C 拡張機能である PhpRedis です。純粋な PHP で実装された Predis より高速で、存在する場合はプラグインが自動的に使用します。PHP-FPM は起動時に拡張機能を読み込むため、新しい拡張機能はプールを再起動するまで認識されません。

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

最後の確認には注意してください。php -m が一覧表示するのは コマンドライン PHP のモジュールであり、FPM では異なる構成のモジュールが読み込まれる場合があります。確認すべきなのは、後述するプラグイン独自の診断結果です。

2026 年 8 月時点で、Ubuntu 24.04 の Redis パッケージは 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 を提供している場合も、以下の手順をそのまま適用できます。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 を同じホストで実行する場合は、ループバック TCP より Unix ソケットが適しています。通信経路に TCP スタックがなく、後から変更する可能性のあるファイアウォールルールではなく、ファイル権限でアクセスを制御できるためです。

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

ソケットの所有者は redis ユーザーとグループです。そのため、Web ユーザーをこのグループに追加する必要があります。

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 は、実際のワーカープロセス 1 つの常駐サイズに pm.max_children を掛けた分を消費します。プラグインの多いサイトでは、通常 64 MB から 128 MB です。カーネルと Web サーバーには数百 MB が必要です。残った容量が上限であり、その一部を Redis に割り当てます。

推測ではなく、実際に測定します。実際のトラフィックを 1 日処理した後に、次を実行します。

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

used_memory_human が上限を大幅に下回っている場合は、上限を下げて RAM を MySQL に戻します。MySQL のほうがその RAM を有効に使えます。上限に張り付き、evicted_keys が 1 日を通して増加する場合は、上限を引き上げます。値は /etc/redis/redis.conf に設定します。

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb は直ちに適用されますが、次回の再起動で失われます。これは単独の sysctl -w と同じ落とし穴です。ファイルを編集し、sudo systemctl restart redis-server を実行してから、値を読み戻します。第 2 の上限も設定しておくと安全です。systemd unit の MemoryMax 上限により、設定を誤った 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 のエラーログに現れるため、キャッシュを追加した後にサイトが遅くなった場合は OOM command not allowed を grep で検索します。

allkeys-lru が、この用途に適したデフォルトです。メモリが逼迫すると、Redis は最も長く使われていないキーを破棄します。これはオブジェクトキャッシュに適しています。キャッシュ内の各値は、MySQL にまだ存在するデータのコピーだからです。キーを1つ失うコストは、クエリ1回です。書き込みを拒否すると、誰かが気付くまで、すべてのリクエストでクエリが発生します。

この用途では volatile-* ポリシーを避けます。これらは有効期限が設定されたキーだけを対象とします。また、キーに有効期限がない場合は noeviction と同じ動作になると Redis は説明しています。WordPress は、ほとんどのオブジェクトキャッシュエントリに TTL を設定しません。そのため、オブジェクトキャッシュで volatile-lru を使用すると、容量を使い切って書き込みを拒否し始める可能性があります。トラフィックが少数のキーに頻繁に集中する場合は、使用頻度に基づいてエビクションを行う allkeys-lfu も適切な代替案です。どれを選ぶかを明確に決め、その理由を記録してください。

永続化: 理由がない限り無効にする

パッケージで提供される redis.conf は、save 900 1 のような行によって RDB スナップショットを有効にし、append-only file は無効にしています。純粋なオブジェクトキャッシュでは、スナップショットに利点はありません。データは定義上再生成でき、20 分前のファイルから復元されたキャッシュには古い値が含まれるため、WordPress はその値を信頼してしまいます。

スナップショットにはコストもあります。BGSAVE はプロセスを fork し、copy-on-write によって子プロセスが書き込む間にメモリ使用量が急増することがあります。小規模な VPS では、Redis のログに次のように現れます。

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

また、起動時に次の警告が表示されることもあります。これは、後で fork に失敗する可能性が高いと Redis が伝えているものです。

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

スナップショットを無効にするには、/etc/redis/redis.conf で空の save スケジュールを設定して再起動し、値が空に戻ったことを確認します。

save ""

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

同じインスタンスに、ジョブキューやレート制限カウンターなど、再構築できないデータを保持する場合に限り、永続化を有効にしてください。その場合は、2 つに分離します。キャッシュではキーを追い出せるようにし、永続データではキーを保持する必要があります。また、maxmemory と eviction は、個々のデータベースインデックスではなくインスタンス全体に適用されます。2 つのソケットで 2 つのインスタンスを動かすのが、適切な構成です。

プラグインをインストールし、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-CLIを実行するユーザーにはwp-contentへの書き込み権限がありません。A foreign object cache drop-in was found.は、別のキャッシュプラグインがすでにそのファイル名を使用していることを示します。この場合の対処はwp redis update-dropinです。Redis server is unreachable:で終わるメッセージの後にクライアントエラーが表示される場合は、接続設定が誤っています。redis-cli pingに戻って確認してください。

権限が原因でコピーに失敗した場合は、手動で配置し、Webユーザーに所有させます。

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 socket を使用する場合は、scheme とパスを設定します。この場合、Host とポートは無視されます。

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 1 台で複数サイトを運用する: プレフィックスとデータベース

Redis では、デフォルトで番号付きのデータベースが 16 個用意され、各データベース内には 1 つのフラットなキースペースがあります。プレフィックスを指定せず、2 つの WordPress インストールをデータベース 0 に接続すると、同じキースペースに同じキー名が書き込まれます。そのため、一方のサイトがもう一方のサイトのオプションを読み取り、それを提供する可能性があります。サイトごとに異なるプレフィックスを設定してください。

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

プレフィックスはキー名を分離します。データベースインデックスはキースペースを分離します。これはフラッシュ時に重要です。1 つのインデックスを空にしても、他のインデックスには影響しません。プラグインには WP_REDIS_SELECTIVE_FLUSH も記載されています。これはデータベース全体ではなく、指定したプレフィックスに一致するキーだけを削除します。ただし、対象キーを検索するためのスキャンが必要です。

プレフィックスとインデックスで分離できないのはメモリです。maxmemory と eviction policy は Redis インスタンス全体に適用されます。そのため、負荷の高いサイトが負荷の低いサイトのキーを追い出す可能性があり、どちらのサイトにもその事実は報告されません。互いに影響を与えてはならないサイトには、個別の Redis インスタンスが必要です。各インスタンスに専用のソケットと専用の上限を設定してください。

ステージングを本番のキャッシュから分離する

ステージングサイトは通常、本番のファイルとデータベースのコピーです。つまり、wp-config.php のコピーであり、同じプレフィックスと同じデータベースインデックスを使用します。同じ Redis を指定すると、本番のキーにステージングの値を書き込みます。テスト用の価格や変更したオプションが、デプロイも痕跡もないままライブサイトに表示される可能性があります。

環境ごとに手動でソルトを設定します。ステージングの wp-config.php に次を設定します。

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

より確実なのは、ステージング専用の 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 は使用中の拡張機能を示します。ここで Predis ではなく PhpRedis が使われていることを確認します。

次に、プラグインの判断に頼らず、WordPress core に直接確認します。

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) は、core が外部オブジェクトキャッシュと通信していることを示します。

次に、設定した prefix を使って、key が到着していることを確認します。

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

サイトを操作している間に dbsize が増加すれば、それが証拠です。有効な drop-in があるのに key が 0 の場合は、接続がひそかに失敗しているか、prefix が想定したものと異なります。

最後に、Redis が計測している値を確認します。

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

hit ratio は keyspace_hits / (keyspace_hits + keyspace_misses) です。Redis のドキュメントにはこの計算式が示されています。ただし、2 点に注意してください。カウンターは直近の再起動以降、インスタンス全体を対象とするため、同じインスタンスを共有するすべてのサイトとアプリケーションの値が混在します。また、flush や再起動の直後の比率には意味がありません。キャッシュがまだ蓄積中だからです。通常のトラフィックが発生する 1 日を通して稼働させてください。

ホスティング会社が公開している hit rate や query 数と、自分の値を比較しないでください。それらは、その会社のサイトとプラグイン構成を対象にした値です。重要なのは、ページキャッシュでは配信できないページで、導入前後に自分で測定した値です。

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

ログイン済みの cookie jar を使い、cache を無効にした状態（WP_REDIS_DISABLED）と有効にした状態で、それぞれ複数回実行します。その差が結果です。

Redis によって WordPress が遅くなる場合

誤ったポリシーを設定したインスタンスの容量不足が最大の原因です。前述のとおり、ログには OOM command not allowed when used memory > 'maxmemory'. と記録され、データベースとキャッシュの両方に料金を支払うことになります。

2 つ目の原因は、Redis を別のホストで実行することです。WordPress は 1 回のリクエストで、オブジェクトキャッシュを数百回呼び出します。1 回のリクエストで 500 回呼び出し、各ラウンドトリップに 1 ms かかる場合、ローカルソケットなら発生しない 0.5 秒の待ち時間が生じます。Redis は同じサーバー上で実行するか、サブミリ秒のレイテンシを確保できるプライベートネットワーク上に配置してください。同じサーバーに置いた場合にカーネルによってどれだけ改善するかは別の問題です。Linux 7.2 で追加されたキャッシュを考慮したスケジューリングは、PHP-FPM や Redis のように頻繁に通信するプロセスを、同じキャッシュを共有するコア上で実行し続けようとします。ただし、VPS のゲスト環境では、ベアメタル環境ほどその効果は得られません。

3 つ目の原因は、autoload 対象の options テーブルが巨大なことです。古いサイトではよくあります。WordPress は autoload 対象のすべての options を 1 つのキーとしてキャッシュするため、リクエストのたびに 1 MB のデータが接続を通過します。測定してください。

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 では新しい autoload 値が追加されました。そのため、'yes' だけに一致する古いクエリでは、最新のインストール環境の値を過少に見積もります。1 MB を超える場合は、Redis ではなく options テーブルを修正すべき問題です。

再起動するとすべてのデータが消えるため、systemctl restart redis-server の直後の数分間はすべてキャッシュミスとなり、データベース処理もすべて発生します。トラフィックが少ない時間帯に再起動してください。また、オブジェクトキャッシュを導入しても、訪問者のページ読み込み時に wp-cron.php が実行されることは防げません。これもリクエストを遅くする原因です。この機会に、WP-Cron を通常の system cron ジョブに移行してください。

運用整理

オプションまたはテーマコードを変更してデプロイした後は、wp cache flush でフラッシュします。プラグインの更新後に drop-in 自体が更新されていなければ、wp redis update-dropin を実行します。古いプラグインバージョンの drop-in を新しいプラグインで使用すると、実際に予期しない挙動の原因になるためです。稼働中のサーバーは redis-cli --stat で監視できます。これは 1 秒ごとに 1 行を出力します。redis-cli monitor はすべてのコマンドを出力し、負荷の高いインスタンスでは実際に CPU を消費します。そのため、現象を再現する数秒間だけ使用し、その後停止します。

最後に、知っておく価値のある数値が 1 つあります。redis-cli info clients は connected_clients を報告します。PHP-FPM は worker ごとに 1 つの接続を保持するため、この値は pm.max_children に対応するはずであり、桁違いに上回るべきではありません。上回る場合は、接続を開いたまま閉じていない処理があります。

FAQ

Redis オブジェクトキャッシュを使う場合も、ページキャッシュは必要ですか？

匿名トラフィックでは必要です。ページキャッシュは PHP を実行せずに保存済みの HTML を返すため、ウォーム状態のオブジェクトキャッシュを使って WordPress を実行するより常に低コストです。オブジェクトキャッシュは、ページキャッシュが対象外にするリクエストを処理します。対象は、ログインユーザー、カート、チェックアウト、wp-admin です。ショップや会員制サイトでは、両方を導入する価値があります。訪問者がログインしないサイトでは、ほぼすべての処理をページキャッシュでまかなえます。

WordPress 用に Redis へ割り当てるメモリ量はどの程度ですか？

他の環境の数値をそのまま使わず、自分のサーバーを基準に算出してください。総 RAM から、MySQL のバッファープールと接続ごとのバッファーを引きます。さらに、PHP-FPM worker 1 つの常駐サイズに pm.max_children を掛けた値を引き、kernel と web server 用に数百 MB を残します。残った容量の一部を Redis に割り当て、トラフィックを 1 日処理した後に redis-cli info memory の used_memory_human を確認して調整します。通常、1 つの WordPress サイトが使用する容量は数十 MB に収まるため、4 GB のサーバーでは 256 MB の maxmemory から始めれば十分な余裕があります。

Redis オブジェクトキャッシュを有効にした後、サイトが遅くなったのはなぜですか？

通常の原因は、noeviction ポリシーでインスタンスの容量が満杯になっていることです。Redis は新しい書き込みを拒否して OOM command not allowed when used memory > 'maxmemory'. を返すため、WordPress はすべての値についてデータベースへフォールバックします。そのうえ、不要な Redis への往復処理も発生します。redis-cli config get maxmemory-policy を確認し、allkeys-lru を設定して、maxmemory が小さすぎないことを確認してください。その他の一般的な原因には、リモートホスト上で Redis を実行していることがあります。リクエストごとに数百回の往復処理が発生すると、遅延が積み重なります。また、数 MB の autoload 対象 options 値があると、すべてのリクエストで接続経由の転送が発生します。

複数の WordPress サイトで 1 つの Redis サーバーを共有できますか？

注意して設定すれば共有できます。各サイトに一意の WP_REDIS_PREFIX を設定し、キー名が衝突しないようにします。また、サイトごとに別の WP_REDIS_DATABASE index を使用し、1 つのサイトを flush しても別のサイトのデータが空にならないようにします。ただし、メモリは共有されます。maxmemory と eviction はインスタンス全体に適用されるため、負荷の高いサイトが負荷の低いサイトのキーを eviction する可能性があります。相互に影響を与えてはならないサイトには、それぞれ独自の制限を持つ別の Redis instance が必要です。

wp-content/object-cache.php を削除しても安全ですか？

安全です。これは drop-in であり、WordPress core の一部ではありません。削除すると、WordPress は組み込みのリクエスト単位のキャッシュに戻ります。サイトは動作を続けますが、データベースクエリが増えます。Object cache disabled. を報告しながらファイルを適切に削除できる wp redis disable を優先してください。Redis が停止している、または正常に動作せず、管理画面へアクセスできない場合は、手動で削除するのが適切な緊急対応です。