实验室克星无限资源版
77.11MB · 2025-11-20
想象一下你的房间（内存），你买了很多不同大小的箱子（数据）来装东西。当你不断扔掉一些旧箱子（删除数据），又换一些更大的新箱子（修改数据）时，房间里就会留下很多放不下新箱子的角落缝隙。这些无法被有效利用的零散空间，就是内存碎片。
Redis提供了强大的监控命令 INFO memory，其中我们最关注的指标是 mem_fragmentation_ratio（内存碎片率）。
计算公式：
mem_fragmentation_ratio = used_memory_rss / used_memory
used_memory_rss：从操作系统角度看到的，Redis进程占用的总物理内存大小（Resident Set Size）。used_memory：Redis为了存储数据，实际申请的内存大小。┌─────────────────────────────────────────────────────┐
│ │
│ used_memory_rss (总物理内存) │
│ │
│ ┌─────────────────────────────────────────┐ │
│ │ │ │
│ │ used_memory (实际使用) │ │
│ │ │ │
│ └─────────────────────────────────────────┘ │
│ ███████████ 内存碎片 ████████████████████ │
│ │
└─────────────────────────────────────────────────────┘
图1: 内存碎片示意图 - used_memory_rss 与 used_memory 的关系
碎片率解读：
| 碎片率范围 | 状态说明 | 建议 |
|---|---|---|
| ≈ 1.0 | 健康。内存几乎无碎片，RSS与使用内存基本相等。 | 理想状态，保持即可。 |
| > 1.5 | 碎片较多。内存利用率开始降低，需要关注。 | 建议调查原因或启用自动整理。 |
| < 1.0 | 危险。表示部分Redis数据被交换（Swap）到了磁盘上。 | 性能会急剧下降，需立即处理，增加物理内存或调整Swap配置。 |
PDF中指出了两大主要原因：
jemalloc为例，其设计就会天然产生碎片。
PDF中为我们揭示了jemalloc的内部机制，这对于理解碎片至关重要：
Huge Allocation
(多个Chunk)
↑
Large Allocation
(多个Page组成)
↑
Small Allocation
┌───────┬───────┬───────┬───────┐
│ Run A │ Run B │ Run C │ Run D │
├───────┼───────┼───────┼───────┤
│▓▓▓ ▓▓▓│▓▓▓▓ ▓▓│▓ ▓▓▓▓▓│▓▓ ▓▓▓▓│ ← Region (实际存储数据)
│▓ ▓▓ ▓▓│▓▓ ▓▓▓▓│▓▓▓ ▓▓▓│▓▓▓ ▓▓▓│
└───────┴───────┴───────┴───────┘
↓
4MB Chunk (向操作系统申请的基本单位)
图2: jemalloc内存分配结构图 - 金字塔式的内存管理
jemalloc将内存请求分为三类：
碎片产生的本质：当不同Run中的Region被频繁、不均衡地分配和释放时，就会在Chunk内部形成大量无法被利用的"空洞"，这就是我们看到的碎片。
从Redis 4.0开始，引入了自动内存碎片整理（Active Defragmentation） 功能，它可以在服务不中断的情况下，在线回收和合并碎片。
其核心思想是：移动数据，腾出连续空间。
整理前（碎片化状态）： 整理后（紧凑状态）：
┌─┬─┬─┬─┬─┬─┬─┬─┐ ┌─┬─┬─┬─┬─┬─┬─┬─┐
│A│ │B│ │C│ │ │ │ │A│B│C│D│E│ │ │ │
├─┼─┼─┼─┼─┼─┼─┼─┤ ├─┼─┼─┼─┼─┼─┼─┼─┤
│ │D│ │E│ │ │ │ │ → │F│G│H│I│ │ │ │ │
├─┼─┼─┼─┼─┼─┼─┼─┤ ├─┼─┼─┼─┼─┼─┼─┼─┤
│F│ │G│ │H│ │I│ │ │ │ │ │ │ │ │ │ │
└─┴─┴─┴─┴─┴─┴─┴─┘ └─┴─┴─┴─┴─┴─┴─┴─┘
↑ ↑
数据分散，空闲空间零散 数据紧凑，空闲空间连续
内存利用率低 内存利用率高
图3: 碎片整理过程示意图 - 从碎片化到紧凑的转变
Redis的整理并非"暴力"全盘整理，而是非常智能。PDF中指出，它会判断：
整理的理想目标是：将利用率低的Run中的Region，移动到利用率高的Run中，用最少的"搬移"工作，实现最高的内存紧凑度。
移动前： 移动后：
低利用率Run (40%) 高利用率Run (80%)
┌─┬─┬─┬─┬─┐ ┌─┬─┬─┬─┬─┐
│▓│ │▓│ │ │ │▓│▓│▓│▓│▓│
├─┼─┼─┼─┼─┤ ├─┼─┼─┼─┼─┤
│ │▓│ │ │ │ → │▓│▓│▓│▓│▓│
├─┼─┼─┼─┼─┤ ├─┼─┼─┼─┼─┤
│▓│ │ │▓│ │ │ │ │ │ │ │
└─┴─┴─┴─┴─┘ └─┴─┴─┴─┴─┘
↑ ↑
移动这些Region到高利用率Run 清空的Run可被整体回收
最小化"搬移工作量" 最大化内存利用率
图4: 从低利用率Run向高利用率Run迁移Region示意图
在redis.conf中，你可以通过以下参数精细控制整理行为，在效率和性能开销之间取得平衡。
# 启用自动碎片整理
activedefrag yes
# 触发整理的阈值
# 当碎片大小超过100MB时
active-defrag-ignore-bytes 100mb
# 当碎片率超过10%时
active-defrag-threshold-lower 10
# 当碎片率超过100%，整理会变得更加积极
active-defrag-threshold-upper 100
# 控制整理对CPU的影响（百分比）
# 保证最小努力程度
active-defrag-cycle-min 5
# 限制最大努力程度，防止影响正常请求
active-defrag-cycle-max 75
在执行BGSAVE或BGREWRITEAOF时，Redis会fork一个子进程。子进程与父进程共享内存页。当父进程修改某个内存页时，操作系统会触发写时复制（Copy-on-Write, COW），为该页创建一个副本。
问题根源：透明大页（Transparent Huge Pages, THP） 在CentOS 7等系统中，THP默认开启。它会尝试将多个4KB小页合并为2MB的大页。这导致在COW时，即使只修改一个大页中的一个小数据，也需要复制整个2MB的大页，从而引发内存用量急剧上升，极端情况下可达父进程内存的2倍。
PDF中的测试数据：
| 内存 | 开启THP时COW内存 | 总内存 | 关闭THP后COW内存 | 总内存 |
|---|---|---|---|---|
| 1G | 875M | 1.85G | 131M | 1.13G |
| 8G | 7.8G | 15.8G | 1.6G | 9.6G |
| 16G | 15.2G | 31.2G | 3.8G | 19.8G |
THP开启 (2MB大页) 普通分页 (4KB小页)
父进程 子进程 父进程 子进程
┌──────────┐ ┌──────────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐
│ ABCDEF │→│ ABCDEF │ │ A │→│ A │ │ B │→│ B │
└──────────┘ └──────────┘ └────┘ └────┘ └────┘ └────┘
修改字母C后的COW: 修改页面A后的COW:
┌──────────┐ ┌──────────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐
│ ABXDEF │ │ ABCDEF │ │ X │ │ A │ │ B │→│ B │
└──────────┘ └──────────┘ └────┘ └────┘ └────┘ └────┘
↑ ↑
复制了整个2MB! 只复制了4KB!
内存开销: 2MB 内存开销: 4KB
性能影响: 严重 性能影响: 轻微
图5: COW与THP关系示意图 - 大页导致的内存放大效应
解决方案：
# 永久关闭THP
echo 'never' > /sys/kernel/mm/transparent_hugepage/enabled
# 将其加入 /etc/rc.local 以确保开机生效
建议：
Linux通过/proc/sys/vm/swappiness来控制使用Swap的倾向性。
Linux内存回收机制：
┌─────────────────┐ ┌─────────────────┐
│ 匿名页 │ │ File-backed │
│ (Anonymous) │ │ (Page Cache) │
│ │ │ │
│ Redis数据 │ │ 文件数据缓存 │
│ 堆、栈数据 │ │ │
└─────────────────┘ └─────────────────┘
↑ ↑
swappiness高 → 优先回收 → swappiness低 → 优先回收
图6: Linux内存回收与swappiness关系
建议：
0。10），以防止容器因内存超用而被系统OOM Killer直接杀死。当Redis执行AOF fsync或RDB持久化时，可能会遇到磁盘I/O瓶颈，导致写操作被阻塞。日志中可能出现：Asynchronous AOF fsync is taking too long (disk is busy?)。
这与Linux的脏页回写机制有关。当系统脏页（已被修改但未写入磁盘的内存页）比例超过dirty_ratio时，发起写操作的程序会被阻塞，直到脏页被刷回磁盘。
优化内核参数（在/etc/sysctl.conf中）：
# 减少系统脏页总大小阈值
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
# 加快脏页回写频率（单位：百分之一秒）
vm.dirty_writeback_centisecs = 100
vm.dirty_expire_centisecs = 500
这会让系统更频繁地、小批量地回写脏页，避免I/O请求堆积造成长时间的阻塞。
PDF中特别指出了客户端库实现的重要性。例如，PHPRedis在早期版本中，遇到网络异常或协议解析错误时，可能不会主动关闭无效连接，导致连接池被污染。而Java的Jedis则会在上层捕获异常并关闭连接。
Redis客户端请求处理流程：
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Socket │ → │ InputBuf │ → │ Command │ → │ OutputBuf │
│ Recv() │ │ (默认16KB) │ │ Process │ │ │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
↓
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Socket │ ← │ OutputBuf │ ← │ Result │ ← │ Command │
│ Send() │ │ (写入>64KB │ │ Format │ │ Execution │
│ │ │ 则退出) │ │ │ │ │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
图7: Redis命令处理与网络I/O流程
最佳实践：
Redis的内存管理是一个与操作系统紧密交互的复杂过程。一个稳定的Redis服务需要从多方面进行调优：
mem_fragmentation_ratio，启用并调优 activedefrag。通过以上这些步骤，你可以系统地解决Redis在内存和持久化方面遇到的大部分疑难杂症，从而保障线上服务的高性能与高可用性。
