ガイド

著者 Matt Connor 2026-08-15

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

Q: 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 対象オプション値があると、すべてのリクエストで接続経由の転送が発生します。

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

注意して設定すれば共有できます。各サイトに一意の WP_REDIS_PREFIX を指定し、キー名が衝突しないようにしてください。また、サイトごとに別の WP_REDIS_DATABASE インデックスを指定し、一方のサイトをフラッシュしても別のサイトが空にならないようにします。ただし、メモリは共有されます。maxmemory と eviction はインスタンス全体に適用されるため、負荷の高いサイトが負荷の低いサイトのキーを削除する可能性があります。互いに影響を与えてはならないサイトには、それぞれ独自の上限を設定した別々の Redis インスタンスが必要です。

WordPressのRedisオブジェクトキャッシュをVPSに構築します。localhostへのbind、maxmemory容量、eviction policyの選び方と、実際にキャッシュが効いているかの確認方法を解説します。

WordPress 用 Redis オブジェクトキャッシュの役割

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

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

両者は併用でき、負荷の高いサイトではどちらも必要です。どの問題を解決しようとしているのかを明確にしてください。匿名の閲覧者が利用する案内サイトでは、速度のほぼすべてをページキャッシュで得られます。そこに Redis を追加しても、変化はほとんどありません。

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

最初に必要なもの

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

以下のコマンドは、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 は起動時に拡張機能を読み込むため、新しい拡張機能を認識させるには pool を再起動する必要があります。

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 年のライセンス変更後に開始された fork で、同じプロトコルに対応しているため、以下の手順をそのまま適用できます。

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 に割り当てるメモリ量

自分のサーバーから値を算出します。maxmemory を設定していない Redis は、kernel のメモリが枯渇して OOM killer がプロセスを終了するまでメモリを使い続けます。通常は最大のプロセスが終了されます。WordPress サーバーでは、MySQL が対象になることがよくあります。journalctl -k | grep -i "out of memory" で終了した事実を後から確認できますが、その時点ではサイトはすでに停止しています。

総 RAM から不要な分を差し引いて考えます。MySQL または MariaDB は innodb_buffer_pool_size に加えて、接続ごとのバッファを確保します。PHP-FPM は、実際の worker 1 個の resident size に pm.max_children を掛けた分を使用します。プラグインが多いサイトでは、通常 64 MB から 128 MB です。kernel と Web サーバーにも数百 MB が必要です。残った容量が上限であり、その一部を Redis に割り当てます。

4 GB VPS で 1 店舗を運用する場合の計算例

以下は例示であり、実際のサーバーで測定した値ではありません。各値を、自分のサーバーが報告する値に置き換えてください。

1 GB の buffer pool を持つ MariaDB: 1024 MB
PHP-FPM、96 MB の worker 10 個: 960 MB
kernel、nginx または Apache、sshd、ログ: 512 MB
残り: 約 1.5 GB

この構成では、maxmemory を 256 MB にするのが妥当な開始値です。十分な余裕を残せます。WordPress サイト 1 件で、それ以上が必要になることはほとんどありません。

推測ではなく、実際に測定します。実際のトラフィックを 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 が一日中増加している場合は、上限を上げます。値は /etc/redis/redis.conf に設定します。

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb は直ちに適用されますが、次回の再起動時に失われます。これは裸の sysctl -w と同じ落とし穴です。ファイルを編集し、sudo systemctl restart redis-server を実行してから、値を読み戻します。二重の制限も設定すると安全です。systemd unit の MemoryMax 制限により、設定を誤った Redis がサーバー全体を停止させることを防げます。これを maxmemory より大きく設定してください。等しくしてはいけません。cgroup の制限に達すると、key を eviction するのではなくプロセスが終了されるためです。Redis を WordPress と同じコンテナで実行する場合は、同じ値を Compose ファイルのメモリ制限に設定します。また、データベースを Docker で実行するか host で実行するかも同じ考え方で選択します。

意図を持って eviction policy を選択する

新しい Redis のデフォルトは noeviction です。現在の設定を確認します。

redis-cli config get maxmemory-policy

noeviction では、インスタンスが満杯になると書き込みを受け付けなくなり、次のエラーを返します。

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

この 1 行は、このガイドで最も深刻な障害モードです。サイトは停止せず、遅くなります。すべてのキャッシュ書き込みが失敗するため、WordPress は値を取得するためにデータベースへ戻ります。その後、次のリクエストで再び保存しようとしますが、また失敗します。サイトは元から発生していたデータベース処理に加えて、すべてのキーについて Redis への往復処理も実行することになります。WordPress の管理画面には、この状態を知らせる情報がありません。この文字列は PHP のエラーログに出力されるため、キャッシュを追加した後にサイトが遅くなった場合は OOM command not allowed を grep で検索します。

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

この用途では volatile-* ポリシーを避けます。これらのポリシーは有効期限を持つキーだけを対象とします。Redis のドキュメントによると、有効期限を持つキーがない場合は noeviction と同じ動作になります。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 つを分離します。キャッシュではキーを eviction の対象にする必要がありますが、永続データではキーを保持する必要があります。maxmemory と eviction は、1 つのデータベースインデックスではなく、インスタンス全体に適用されます。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 であり、処理を実行するのも 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 個あり、それぞれに単一のフラットなキースペースがあります。データベース 0 を使用し、プレフィックスを設定していない 2 つの WordPress インストールは、同じキースペースに同じキー名を書き込みます。そのため、一方のサイトがもう一方のサイトのオプションを読み込み、それを提供する可能性があります。サイトごとに固有のプレフィックスを設定してください。

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

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

プレフィックスとインデックスで分離できないのは、メモリです。maxmemory と eviction policy はインスタンス全体に適用されます。そのため、負荷の高いサイトによって負荷の低いサイトのキーが追い出されても、どちらのサイトにもその事実は通知されません。互いに影響を与えてはならないサイトには、サイトごとに独立した 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 プラグインの認識ではなく、WordPress core に直接確認します。

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) は、core が外部の object cache と通信していることを示します。

次に、設定した 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 や再起動の直後の比率には意味がありません。キャッシュがまだ蓄積中だからです。通常のトラフィックが発生する日を通して動作させてください。

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

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

ログイン済みの cookie jar を使用して、これを複数回実行します。最初はキャッシュを無効にし（WP_REDIS_DISABLED）、次に有効にします。その差分が結果です。

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

誤ったポリシーが設定された容量いっぱいのインスタンスが最大の原因です。前述のとおり、ログに OOM command not allowed when used memory > 'maxmemory'. が出力され、データベースとキャッシュの両方に料金が発生します。

別のホストで Redis を実行することが2番目の原因です。WordPress は1回のリクエストで、オブジェクトキャッシュを何百回も呼び出します。1回のリクエストで500回呼び出し、各ラウンドトリップに1 msかかる場合、ローカルソケットなら発生しない待ち時間が合計で0.5秒になります。Redis は同じサーバー上で実行するか、サブミリ秒のレイテンシーを持つプライベートネットワーク上に配置してください。

autoload 対象の options テーブルが巨大であることが3番目の原因です。古いサイトではよくあります。WordPress は、autoload 対象のすべての options を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 のバッファプールと接続ごとのバッファを差し引きます。次に、pm.max_children に PHP-FPM ワーカー 1 つの常駐サイズを掛けた値を差し引き、さらにカーネルと Web サーバー用として数百 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 対象オプション値があると、すべてのリクエストで接続経由の転送が発生します。

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

注意して設定すれば共有できます。各サイトに一意の WP_REDIS_PREFIX を指定し、キー名が衝突しないようにしてください。また、サイトごとに別の WP_REDIS_DATABASE インデックスを指定し、一方のサイトをフラッシュしても別のサイトが空にならないようにします。ただし、メモリは共有されます。maxmemory と eviction はインスタンス全体に適用されるため、負荷の高いサイトが負荷の低いサイトのキーを削除する可能性があります。互いに影響を与えてはならないサイトには、それぞれ独自の上限を設定した別々の Redis インスタンスが必要です。

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

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

#wordpress#redis#caching#performance #vps