Redis内存碎片率需通过redis-cli INFO memory命令手动查看，宝塔面板仅显示易读内存字段而未计算并展示mem_fragmentation_ratio这一诊断指标。
Redis内存碎片率不能直接在宝塔面板图形界面里看到，必须通过 INFO memory 命令手动查，否则你看到的只是表面内存用量，根本发现不了碎片问题。
为什么宝塔Redis管理页不显示 mem_fragmentation_ratio
宝塔的“Redis管理”页面只聚合了 used_memory_human、used_memory_rss_human 这类易读字段，但刻意隐藏了计算碎片率必需的原始比值 mem_fragmentation_ratio。它不展示这个值，不是遗漏，而是因为：
- 该指标需要实时计算（
used_memory_rss / used_memory），而宝塔前端不做除法运算 - 碎片率本身是诊断指标，不是运维常规监控项，宝塔默认聚焦于“是否爆内存”，而非“内存是否被浪费”
- 如果你只看面板上显示的“内存使用 1.2GB”，而实际
mem_fragmentation_ratio是 2.8，说明操作系统给了 Redis 3.4GB 物理内存，但 Redis 自己只用了 1.2GB——剩下 2.2GB 是碎片，无法被其他进程利用
用宝塔终端执行 redis-cli INFO memory 查真实碎片率
这是最直接、最可靠的方式，不需要额外工具或权限升级：
- 登录宝塔 → 左侧「终端」→ 新建终端
- 输入命令：
redis-cli INFO memory（如果 Redis 配了密码，加-a your_password） - 重点找这三行：
used_memory:123456789、used_memory_rss:345678901、mem_fragmentation_ratio:2.80 - 若没返回
mem_fragmentation_ratio字段，说明 Redis 版本太低（echo "scale=2; 345678901 / 123456789" | bc
注意：used_memory_rss 小于 used_memory 是危险信号（比如 ratio = 0.7），代表部分内存被 swap 出去了，Redis 响应会明显卡顿。
用 MEMORY STATS 补充验证碎片成因
INFO memory 只给总比值，看不出碎片来自哪。这时候运行 MEMORY STATS 能定位根源：
- 执行：
redis-cli MEMORY STATS - 关注：
allocator_active（分配器当前活跃内存）、allocator_resident（实际驻留物理内存）、allocator_allocated（分配器已分配但未释放的内存） - 如果
allocator_resident > allocator_active显著，说明 jemalloc/tcmalloc 没把空闲内存还给 OS——这是外部碎片主因 - 如果
allocator_allocated远大于used_memory，说明 Redis 内部数据结构（如 hash、zset）存在大量小对象未合并，属于内部碎片
宝塔终端里跑这条命令没问题，但返回内容较长，建议配合 grep 筛选：redis-cli MEMORY STATS | grep -E "(allocator_|total_chunks)"
别信 top 或 htop 显示的 Redis 内存值
Linux 的 top 显示的是 used_memory_rss，但它混入了 Redis 子进程（如 RDB fork、AOF rewrite）的瞬时内存峰值，且无法区分真实数据和碎片。更糟的是：
- 当 Redis 正在做 bgsave，
top可能显示 4GB，但INFO memory里used_memory才 1GB——多出的全是 copy-on-write 副本，不是碎片，也不是泄漏 - 如果服务器开了 Transparent Huge Pages（THP），
mem_fragmentation_ratio会虚高，这不是 Redis 的锅，得关 THP：echo never > /sys/kernel/mm/transparent_hugepage/enabled - 宝塔「进程管理」里看到的 Redis 进程内存占用，和
used_memory_rss不一致是正常的，因为它统计方式不同（VSS vs RSS）
真正要盯的只有两个数：used_memory（你存了多少数据）、mem_fragmentation_ratio（这些数据把系统内存糟蹋成什么样了）。其他全是干扰项。
