Redis设置多大的maxmemory配合淘汰策略最合适？-Redis-PHP中文网

maxmemory无固定值，须据真实内存余量、访问特征及业务容忍度动态设定：先查used_memory和mem_fragmentation_ratio（>1.5需警惕碎片），再结合系统可用内存（预留os 512mb+其他进程+aof/slave缓冲），建议maxmemory≤系统可用内存×0.7且≤used_memory_peak×1.3；淘汰策略须匹配key过期设置，volatile类策略要求所有缓存key带ex/px，否则退化为noeviction导致oom；调优后须监控evicted_keys与hit_rate，并用--bigkeys/--hotkeys验证热点分布以校准策略。

redis设置多大的maxmemory配合淘汰策略最合适？

没有“最合适”的固定值，maxmemory 必须基于你的真实内存余量、数据访问特征和业务容忍度来定，硬套 4GB 或 “总内存的 70%” 会直接导致频繁淘汰或 OOM。

怎么算出安全的 maxmemory 上限？

不能只看 Redis 自身 used_memory，得留足系统级缓冲：

用 redis-cli INFO memory 查当前 used_memory 和 mem_fragmentation_ratio（若 >1.5，说明内存碎片严重，实际物理内存占用比指标高）
用 free -h 或 cat /proc/meminfo 看系统剩余可用内存，减去：OS 预留（至少 512MB）、其他进程常驻内存、Redis 的 aof_buffer 和 slave_buf（主从场景下可能额外吃 1–2GB）
最终留给 Redis 的 maxmemory 建议 ≤ 系统可用内存 × 0.7，且必须 ≤ used_memory_peak × 1.3（防止突发写入打满）

淘汰策略选错，再大的 maxmemory 也白搭

策略和 maxmemory 是绑定生效的，不是独立配置：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

volatile-lru 或 volatile-ttl 要求你所有缓存 key 都带 EX/PX，否则淘汰范围为 0 —— 这时即使 maxmemory 设再小，也会退化成 noeviction，写入直接报 (error) OOM command not allowed when used memory > 'maxmemory'
allkeys-lfu 在 Redis 4.0+ 可用，但会额外记录访问频次，maxmemory_samples 默认 5，若设太高（如 100）会显著增加 CPU 开销，尤其在每秒数千写入的场景
如果业务中大量 key 没设过期时间（比如持久化配置项），又误配了 volatile-* 策略，等于关闭了淘汰能力 —— 此时 maxmemory 就只是个摆设

线上调优必须验证的两个动作

光改配置不观察，等于没调：

改完后，持续监控 evicted_keys 和 expired_keys 的每秒增量：若 evicted_keys 暴涨但 hit_rate（keyspace_hits / (keyspace_hits + keyspace_misses)）骤降，说明淘汰太激进，要么调大 maxmemory，要么换 allkeys-lfu 替代 allkeys-lru
用 redis-cli --bigkeys 和 redis-cli --hotkeys（Redis 4.0+）确认真实热点分布 —— 如果 95% 请求集中在 5% 的 key 上，allkeys-lfu 明显优于 allkeys-lru；反之，若访问时间局部性强（比如用户 session 按登录时间集中失效），volatile-ttl 更稳