Redis内存诊断需重点关注used_memory、used_memory_rss、mem_fragmentation_ratio和used_memory_peak四个字段：mem_fragmentation_ratio>1.5提示碎片明显，>2.0需排查；used_memory_rss远超used_memory（如2倍以上）是典型碎片信号；used_memory_peak持续接近或超可用内存预示泄漏风险。
redis-cli info memory 输出哪些字段关键看内存和碎片
info memory 是最直接的入口，但不是所有字段都相关。重点关注这四个：used_memory（Redis 实际分配的字节数）、used_memory_rss（操作系统看到的物理内存占用）、mem_fragmentation_ratio（碎片率）、used_memory_peak（历史峰值）。
-
mem_fragmentation_ratio> 1.5 通常说明存在明显内存碎片，> 2.0 就得查了 -
used_memory_rss远大于used_memory（比如差 2 倍以上）是碎片典型的信号 -
used_memory_peak持续接近或超过机器可用内存，说明有内存泄漏风险
别只盯着 used_memory 看——它不包含 Redis 自身开销、jemalloc 元数据、页对齐浪费，更不反映 OS 层面真实压力。
为什么 mem_fragmentation_ratio 高不一定代表 Redis 有问题
高碎片率常被误判为 Redis 故障，其实它更多反映的是内存分配器行为和业务模式：
- 使用 jemalloc（Redis 默认）时，小对象频繁增删容易导致内部碎片，尤其在
maxmemory接近但未触发淘汰时 - 如果
used_memory_rss稳定、used_memory无持续上涨，那只是分配器“囤着没还”，未必影响服务 -
CONFIG RESETSTAT不重置碎片率，它只统计当前内存映射状态，跟命令计数无关
真正危险的组合是：mem_fragmentation_ratio 高 + used_memory 持续爬升 + evicted_keys 开始非零 —— 这说明淘汰已启动，但内存还是收不回来，大概率是大 key 或 hash/set 内部膨胀。
用 redis-cli --stat 快速盯住内存波动趋势
redis-cli --stat 是最轻量的实时观察方式，每秒刷新一行，比反复敲 info memory 更适合盯异常：
- 它默认显示
used_memory、used_memory_rss、mem_fragmentation_ratio三列，刚好覆盖核心指标 - 加
-i 0.5可缩短间隔（如redis-cli -i 0.5 --stat），适合压测中抓突刺 - 注意：它不显示
used_memory_peak，所以发现碎片率跳变后，还得切回info memory查峰值和淘汰情况
别用它替代监控系统——没有历史曲线、无法告警，但它能让你在 SSH 里 3 秒内判断“是不是现在出问题了”。
内存碎片本身不会触发 OOM，但会放大 OOM 风险
Linux OOM killer 杀进程看的是 used_memory_rss，不是 used_memory。碎片率高意味着：
- 同样的
used_memory，RSS 更高，更快触碰 cgroup limit 或系统总内存上限 - 即使配置了
maxmemory，Redis 也不会主动把内存还给 OS（jemalloc 默认行为），used_memory_rss可能长期卡在高位 -
MEMORY PURGE（Redis 6.0+）可尝试强制 jemalloc 归还空闲页，但效果取决于 workload 和 jemalloc 版本，不是万能药
最容易被忽略的一点：容器环境下，mem_fragmentation_ratio 正常但 used_memory_rss 超过 cgroup memory.limit_in_bytes，照样被 kill——这时候看碎片率没用，得看 RSS 绝对值和容器监控。
