如何在Redis 7.0中利用新命令监控内存分布_使用MEMORY STATS分析淘汰风险-Redis-PHP中文网

memory stats 比 info memory 更能预判淘汰，因其拆解内存来源定位失控模块；关键字段包括 used_memory_dataset、clients.normal、aof.buffer 等，需结合 maxmemory-policy 综合判断淘汰风险。

如何在redis 7.0中利用新命令监控内存分布_使用memory stats分析淘汰风险

Redis 7.0 的 MEMORY STATS 能直接暴露淘汰风险，但必须看对字段——只盯 used_memory 和 mem_fragmentation_ratio 会漏掉真正要命的问题。

INFO memory 返回的是聚合值，比如 used_memory 是总估算量，mem_fragmentation_ratio 是 RSS/used_memory 的比值；它看不出内存“长在哪”。而 MEMORY STATS 拆解了每一块的来源，能定位到哪类开销正在失控：

Redis 7.0+ 的 MEMORY STATS 返回嵌套数组结构，关键字段需手动解析。真正影响淘汰决策的不是总量，而是“可被释放的那部分”是否已逼近阈值：

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

下载

used_memory_dataset：你存的所有 key-value + 编码结构（如 listpack、dictEntry）实际占用，这是淘汰策略真正作用的对象
used_memory_overhead：固定开销（连接、缓冲、Lua 等），这部分不参与淘汰，但若占比 >30%，说明系统级资源已被挤占，淘汰前就可能 OOM
db.X.expires（X 是 db 编号）：带过期时间的 key 数量。如果该值很大但 db.X.avg_ttl 很低（比如
allocator_active 和 allocator_allocated：当 allocator_active >> allocator_allocated，jemalloc 在 hold 大量页，OS 层内存压力已高，哪怕 used_memory 没超限，maxmemory-policy 也可能提前介入

这个命令本身不耗时，但结果解读极易误判：

字段名带点号（如 db.0.keys）不是嵌套 JSON，而是 flat key，Redis 7.0+ 返回的是数组对（["db.0.keys", 12345]），脚本解析时别当成对象遍历
peak.allocated 是进程启动以来峰值，不是当前值，不能用来判断实时压力
普通用户无权限执行，报错 (error) NOPERM this user has no permissions to run the 'memory' command，需确认 ACL 权限含 ~* +memory
集群环境下，MEMORY STATS 只返回当前节点数据，不能跨节点聚合；想看全局分布，得逐个节点采集并汇总 used_memory_dataset 和 clients.normal

光有内存数字不够，得和淘汰策略联动判断：

用 volatile-lru 但 db.X.expires = 0？策略自动退化为 noeviction，写操作开始报错 (error) OOM command not allowed when used memory > 'maxmemory'
用 allkeys-lru 但 used_memory_dataset 增速远快于 used_memory_overhead？说明业务写入激增，LRU 采样数（maxmemory-samples）若仍为默认 5，淘汰精度下降，冷热 key 辨识失真
allocator_fragmentation_ratio > 1.8 且 used_memory_dataset / maxmemory > 0.9？此时即使淘汰 key，碎片内存也无法归还 OS，真实可用内存持续萎缩，必须考虑 MEMORY PURGE 或重启