Redis MEMORY STATS 里的 allocator_frag_ratio 怎么理解
来源:17golang原创
时间:2026-10-06 22:48:18 348浏览 收藏
看到 Redis 的 allocator_frag_ratio 偏高时,先不要把它当成“Redis 泄漏”。这个指标表示分配器已经向进程准备的内存,与 Redis 当前实际分配出去的内存之间的比例,官方定义为 allocator_active / allocator_allocated。比例要和 allocator_frag_bytes 一起看:前者说明相对差异,后者才告诉你多出来了多少字节。
官方地址:https://redis.io/docs/latest/commands/memory-stats/
allocator_frag_ratio关注分配器内部的外部碎片,不等于进程 RSS 碎片。- 比例高但字节数很小时,通常不应仅凭比例触发扩容或重启。
- 判断时同时记录
allocator_active、allocator_allocated、allocator_frag_bytes和三个 fragmentation 指标。
MEMORY STATS 返回值先按三层关系读
Redis 4.0 起提供 MEMORY STATS,时间复杂度为 O(1)。RESP2 返回嵌套数组,RESP3 返回键值映射;命令本身不做采样扫描,适合纳入低频巡检。
# 查看 Redis 返回的整体内存统计
redis-cli MEMORY STATS
# 只保留判断碎片和 RSS 差异所需的字段
redis-cli INFO memory | egrep 'used_memory:|used_memory_rss:|used_memory_peak:|allocator_(allocated|active|resident|rss_ratio|frag_ratio|frag_bytes)|mem_fragmentation_(ratio|bytes)'
重点字段可以先画成一个静态关系:allocator_allocated 是分配器实际分配给 Redis 的字节数,allocator_active 是分配器保持活跃的内存,二者相除得到 allocator_frag_ratio;二者相减得到 allocator_frag_bytes。因此,比例和绝对字节数必须成对读取。

用比例和字节数判断是否真的值得处理
可以用下面的简化公式复核返回值:
# 公式只用于理解返回值,数值以同一次采集结果为准
allocator_frag_ratio = allocator_active / allocator_allocated
allocator_frag_bytes = allocator_active - allocator_allocated
| 观察组合 | 更合理的解释 | 下一步 |
|---|---|---|
| ratio 接近 1,bytes 很小 | 分配器活跃内存与实际分配接近 | 保持趋势观察 |
| ratio 偏高,bytes 也很大 | 可能存在明显外部碎片或释放后未及时归还 | 结合峰值、业务 churn 和分配器配置排查 |
| ratio 很高,bytes 很小 | 分母较小导致比例被放大 | 不要仅凭比例报警 |
| allocator 正常但 mem_fragmentation_ratio 偏高 | RSS 还包含进程、库、线程栈等开销 | 拆开看 RSS 与 used_memory |
这里没有一个脱离规模的通用“超过多少就一定异常”阈值。尤其在 Redis 刚经历大量键创建、删除或过期之后,分配器保留活跃页并不等同于数据仍然占用同样多的有效对象空间。更有价值的是记录一段时间内的 allocator_frag_bytes、used_memory_peak 和业务操作波动,看它们是否持续扩大。
不要把三个 fragmentation 指标当成同一件事
allocator_frag_ratio 只描述 allocator active 与 allocated 的关系;allocator_rss_ratio 描述 allocator resident 与 active 的差异;mem_fragmentation_ratio 则通常由 used_memory_rss / used_memory 得出,范围还包括 Redis 进程本身的其他内存开销。三者数值相近,也不意味着含义相同。
例如,allocator_frag_ratio 接近 1 而 mem_fragmentation_ratio 较高,优先怀疑 RSS 中包含的代码段、共享库、线程栈或其他进程开销;如果 allocator 的 ratio 和 bytes 同时升高,再去看对象生命周期、批量删除、过期淘汰以及分配器回收行为。allocator_rss_ratio 可以帮助判断 resident 与 active 是否还有差距,但不能单独证明发生了泄漏。

生产排查时保留一份最小检查清单
每次采集至少保存以下字段,并附上采集时间、实例角色和业务峰值信息:
# 记录字段而不是只记录一个 ratio,避免后续无法还原判断依据
redis-cli INFO memory | egrep 'used_memory:|used_memory_rss:|used_memory_peak:|allocator_allocated:|allocator_active:|allocator_resident:|allocator_frag_ratio:|allocator_frag_bytes:|allocator_rss_ratio:|mem_fragmentation_ratio:|mem_fragmentation_bytes:'
# 仅在需要时查看 Redis 自带的内存问题提示
redis-cli MEMORY DOCTOR
如果碎片字节持续增长,先确认是否与流量峰值和对象 churn 同步,再评估主动碎片整理、分配器参数或平滑重启。若只是比例高、字节量小且趋势稳定,通常先观察更稳妥;不要用一次快照替代时间序列。
相关问题
allocator_frag_ratio 高就是内存泄漏吗?
不是。它反映分配器内部的活跃内存与实际分配内存之比,必须结合 allocator_frag_bytes、峰值和趋势判断。
mem_fragmentation_ratio 能替代 allocator_frag_ratio 吗?
不能。前者包含 RSS 与进程额外开销,后者聚焦 allocator 的外部碎片;排查时应分层读取。
为什么比例很高但实际多出的内存不多?
比例的分母可能很小,少量字节差异也会产生较大的倍数。此时字节数比单独的比例更有解释力。
-
117 收藏
-
426 收藏
-
171 收藏
-
113 收藏
-
195 收藏
-
288 收藏
-
208 收藏
-
291 收藏
-
149 收藏
-
115 收藏
-
463 收藏
-
433 收藏
-
228 收藏
-
295 收藏
-
198 收藏
-
401 收藏
-
216 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 立即学习 543次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 立即学习 516次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 立即学习 500次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 立即学习 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 立即学习 485次学习