Redisのメモリを最適化する基本は、「上限（maxmemory）を決める」「上限に達したときの動き（追い出しポリシー）を用途に合わせる」「何がメモリを使っているかを調べて減らす」の3つです。この記事では、まず現状の使用量を正しく読む方法を説明し、そのうえでmaxmemoryと追い出しポリシーの設定、大きなキーの見つけ方、データ構造とエンコーディングによる節約、断片化への対処を順に解説します。
まず現状を読む：INFO memory
設定を変える前に、今どれだけ使っているかを確認します。
redis-cli INFO memory見るべき項目は次のとおりです。
used_memory_human: Redisがデータなどのために確保しているメモリ量used_memory_rss_human: OSから見たRedisプロセスの実際のメモリ量used_memory_peak_human: これまでの最大使用量maxmemory_human: 設定されている上限（0なら上限なし）maxmemory_policy: 上限に達したときの動きmem_fragmentation_ratio: RSSをused_memoryで割った値。断片化の目安
maxmemory が0のままだと、Redisはサーバーのメモリを使い切るまで増え続け、最悪の場合はOSのOOM Killerにプロセスを止められます。キャッシュ用途で使っているのに上限が設定されていない状態は、最初に直したいポイントです。
あわせて INFO stats の evicted_keys（追い出されたキー数）、expired_keys（期限切れで消えたキー数）、keyspace_hits と keyspace_misses（ヒットとミスの回数）も見ておくと、設定変更の効果を比べやすくなります。
maxmemoryを設定する
上限はredis.confか、稼働中なら CONFIG SET で設定します。
# /etc/redis/redis.conf
maxmemory 1gb
maxmemory-policy allkeys-lruredis-cli CONFIG SET maxmemory 1gb
redis-cli CONFIG SET maxmemory-policy allkeys-lru
# 設定ファイルにも反映する（権限や設定ファイルの扱いによっては失敗するので、その場合は手で書き換える）
redis-cli CONFIG REWRITE値を決めるときは、サーバーの物理メモリいっぱいにしないことが大切です。Redis自身のバッファ、レプリケーション用のバッファ、RDB保存やAOFリライトでプロセスを複製（fork）したときの一時的な増加、同じサーバーで動くPHPやMySQLの分を差し引いて、余裕を持たせます。何割にすべきかは構成によって変わるので、まず控えめな値で始め、INFO memory のピーク値を見ながら調整します。
追い出しポリシーを用途で選ぶ
maxmemory-policy は、上限に達して新しいデータを書き込めなくなったときに、どのキーを消すかを決めます。主な選択肢は次のとおりです。
noeviction: 何も消さず、書き込みをエラーにする。既定値。消えては困るデータ向けallkeys-lru: 全キーの中から、最近使われていないものを消すallkeys-lfu: 全キーの中から、使用頻度の低いものを消すvolatile-lru/volatile-lfu: TTLが付いたキーの中だけで、上と同様に消すvolatile-ttl: TTLが付いたキーの中で、残り時間が短いものから消すallkeys-random/volatile-random: 無作為に消す
WordPressのオブジェクトキャッシュのように「消えても作り直せる」用途なら、allkeys-lru か allkeys-lfu が一般的です。一部の記事に長期間アクセスが集中するサイトでは、頻度を見るLFUのほうがよく使われるキーを残しやすい傾向があります。どちらが良いかはアクセスの傾向次第なので、切り替えたら keyspace_hits と keyspace_misses の比率を比べて判断します。
逆に、セッションやジョブキューなど消えると困るデータを同じRedisに置いている場合、allkeys系にすると大切なデータまで消されます。その場合は、キャッシュとそれ以外でRedisインスタンスを分けるのが安全で分かりやすい方法です。どうしても1台で済ませるなら、キャッシュにだけTTLを付けて volatile-lru にする方法もありますが、TTLの付け忘れがあるとメモリが減らないので注意してください。
なお、LRUやLFUは厳密な計算ではなく、いくつかのキーを抜き出して近似的に判断しています。抜き出す数は maxmemory-samples（既定は5）で調整できますが、通常は変更しなくて構いません。
何がメモリを使っているか調べる
大きなキーを探す
redis-cli --bigkeys
redis-cli --memkeys--bigkeys はデータ型ごとに要素数の多いキーを、--memkeys はメモリ使用量の多いキーを探します。内部でSCANを使うため本番でも動かせますが、キー数が多いと負荷がかかるので、アクセスの少ない時間帯に実行してください。-i 0.1 のように間隔を指定すると負荷を抑えられます。
個別のキーの使用量は MEMORY USAGE キー名 で確認できます。MEMORY DOCTOR を実行すると、断片化などの問題がある場合に、Redisが文章で指摘してくれます。
WordPressで多いパターン
WordPressのオブジェクトキャッシュでは、次のようなデータがメモリを多く使いがちです。
- 自動読み込みされるオプション（alloptions）が大きい。不要なプラグインの設定が残っていることが多い
- TTLなしで保存されたキャッシュが溜まり続ける
- 1つのRedisを複数サイトで共有していて、どのサイトのデータか分からない
Redis Object Cache プラグインでは、wp-config.php の定数でキーの接頭辞や最大TTLを指定できる仕組みがあり、サイトごとの区別や溜まりすぎの防止に使えます。定数名や挙動はバージョンで変わることがあるため、プラグインのドキュメントで確認してから設定してください（2026年10月現在）。
データ構造とエンコーディングで節約する
Redisは、要素数が少ないハッシュやソート済みセットを、コンパクトな形式（Redis 7以降はlistpack）で保存します。要素数や値の長さが一定を超えると通常の形式に切り替わり、メモリ使用量が増えます。現在の形式は OBJECT ENCODING キー名 で確認できます。
# Redis 7系の設定名（既定値の例）
hash-max-listpack-entries 128
hash-max-listpack-value 64
zset-max-listpack-entries 128
zset-max-listpack-value 64古いバージョンでは同じ役割の設定が ziplist という名前でした。しきい値を大きくするとメモリは減りますが、要素の検索が遅くなるため、むやみに上げるのは避けます。
設定より効果が大きいのは、データの持ち方を見直すことです。たとえば、ユーザーごとの細かい値を user:1000:name、user:1000:email のように別々のキーで持つより、1つのハッシュにまとめるほうが、キーごとの管理情報が減って小さくなります。キャッシュには必要な項目だけを入れ、長い文字列は圧縮してから保存する、といった工夫も効きます。
削除と断片化への対処
大きなキーを DEL で消すと、その間Redisが止まったように見えることがあります。UNLINK を使えば、キーを見えなくしてから実際の解放をバックグラウンドで行います。追い出しや期限切れによる削除もバックグラウンドで行わせたい場合は、lazyfree-lazy-eviction や lazyfree-lazy-expire を有効にする選択肢があります。
mem_fragmentation_ratio が1.5を大きく超える状態が続く場合は、データを消してもOSにメモリが返っていない（断片化している）可能性があります。標準のjemallocでビルドされたRedisなら、activedefrag yes で稼働中に断片化を解消できます。CPUを使う処理なので、有効にしたらCPU使用率も確認してください。逆に1を下回る場合は、メモリがスワップに追い出されている可能性があり、こちらは性能への影響が大きいため、maxmemoryの見直しやメモリ増設を優先します。
設定の変更は、本番の前にステージングで試し、永続化しているデータがある場合はバックアップを取ってから行ってください。
まとめ
INFO memoryとINFO statsで、使用量・上限・断片化・ヒット率を先に確認する- maxmemoryは物理メモリいっぱいにせず、forkや他のプロセスの分を残して設定する
- キャッシュ用途は
allkeys-lruかallkeys-lfu、消えては困るデータは別インスタンスかnoevictionにする --bigkeys、--memkeys、MEMORY USAGEで大きなキーを見つけ、データの持ち方を見直す- 大きなキーの削除は
UNLINK、断片化が続くときはactivedefragを検討する