三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

Redis内存管理：高占用原因与优化实践

发布时间：2026/8/9 13:15:31 三亩地 编程学习日记
Redis内存管理：高占用原因与优化实践

1. Redis内存占用高的现象解析

第一次遇到Redis内存居高不下的情况时，我正负责一个日活百万级的电商系统。当时为了紧急处理一个缓存穿透问题，我们批量删除了大量异常key，但通过INFO memory命令查看时，发现used_memory_human显示的值几乎没有变化。这种"删了但没完全删"的现象，让我开始深入研究Redis内存管理的底层机制。

Redis的内存占用主要分为三部分：数据内存、缓冲内存和内存碎片。当我们执行DEL命令时，只是标记数据为"已删除"，实际内存并不会立即释放。这种设计类似于办公室的文件归档——你把文件扔进废纸篓（删除key），但废纸篓还放在办公室里（内存未释放），直到清洁工真正把废纸篓清空（内存回收）。

关键指标：通过redis-cli info memory查看内存详情时，要特别关注mem_fragmentation_ratio（内存碎片率）。当这个值大于1.5时，说明碎片化已经比较严重。

2. 内存未释放的四大核心原因

2.1 惰性删除机制的工作原理解析

Redis采用惰性删除(Lazy Free)策略，这是性能与资源权衡的结果。当执行DEL命令时：

  1. 主线程仅将key从keyspace删除
  2. 对应的内存释放操作会被包装成异步任务
  3. 由后台线程(BIO)在系统空闲时逐步处理

这种机制在删除大对象时尤为明显。我们曾删除过一个存储50MB商品数据的Hash，内存监控显示释放过程持续了约2分钟。可以通过以下命令查看惰性删除状态：

redis-cli config get lazyfree-lazy-*

2.2 内存碎片化的形成与影响

内存碎片就像硬盘存储文件后产生的"空隙"。Redis使用jemalloc内存分配器，虽然比glibc的malloc更高效，但仍无法避免碎片问题。我们做过一个实验：

  1. 先写入10000个16KB的String
  2. 然后随机删除其中3000个
  3. 再写入3000个18KB的String

结果发现内存用量比预期高出23%，这就是典型的大小不一数据交替写入删除导致的内存空洞。

2.3 子进程内存占用问题

在执行BGSAVE或BGREWRITEAOF时，Redis会fork子进程。在Linux的copy-on-write机制下，如果父进程有大量写操作，会导致子进程占用额外内存。我们遇到过一次AOF重写期间内存翻倍的情况，通过调整以下参数缓解：

# 控制重写时机 auto-aof-rewrite-percentage 70 auto-aof-rewrite-min-size 64mb

2.4 操作系统级别的内存分配

Redis向操作系统申请内存时，是通过分配内存页（通常4KB）来实现的。即使只存储1字节的数据，也会占用整个内存页。我们曾有个存储大量小key的实例，实际数据只有3GB，但Redis报告的内存使用却达到5GB。

3. 实战诊断与解决方案

3.1 内存状态深度检查方法

完整的诊断应该包含以下步骤：

# 1. 查看整体内存情况 redis-cli info memory | grep -E 'used_memory|mem_fragmentation_ratio' # 2. 检查大key分布 redis-cli --bigkeys # 3. 分析内存详细分配 redis-cli memory stats redis-cli memory malloc-stats

我曾通过这些命令发现过一个隐藏问题：一个只有10万key的实例，mem_fragmentation_ratio却高达2.3。进一步排查发现是大量使用SORT命令导致的临时内存没有及时释放。

3.2 主动内存碎片整理配置

Redis 4.0+提供了主动碎片整理功能，我们的生产环境配置如下：

# 开启自动碎片整理 activedefrag yes # 当碎片率超过100%时触发 active-defrag-ignore-bytes 100mb active-defrag-threshold-lower 50 active-defrag-threshold-upper 100 # 占用CPU时间比例限制 active-defrag-cycle-min 5 active-defrag-cycle-max 75

需要注意：在碎片整理期间，Redis的CPU使用率可能会短暂飙升到80%以上，建议在业务低峰期进行。

3.3 关键参数调优经验

根据不同的使用场景，我们总结出这些配置组合：

场景1：频繁写入/删除大量数据

# 启用异步删除 lazyfree-lazy-eviction yes lazyfree-lazy-expire yes lazyfree-lazy-server-del yes # 调整内存回收策略 maxmemory-policy volatile-lru

场景2：需要持久化的大内存实例

# 控制子进程内存使用 stop-writes-on-bgsave-error yes rdb-save-incremental-fsync yes # 优化AOF写入 aof-rewrite-incremental-fsync yes

4. 生产环境中的经典案例

4.1 电商促销期间的OOM问题

去年双11大促时，我们的商品缓存实例突然报OOM。事后分析发现：

  1. 高峰期间每秒执行约2000次DEL操作
  2. 惰性删除队列积压超过50万个任务
  3. 内存碎片率达到1.8

解决方案是：

  1. 改用UNLINK替代DEL（异步删除）
  2. 设置lazyfree-lazy-user-del yes
  3. 增加定时任务，在凌晨主动执行MEMORY PURGE

4.2 社交网络Feed流的内存碎片优化

一个存储用户动态的Redis实例，存储结构为：

  • key: user_id
  • value: zset(时间戳, 动态内容)

随着用户不断发布和删除动态，内存碎片持续增长。我们最终采用以下方案：

  1. 将大zset拆分为多个小zset
  2. 启用activedefrag配置
  3. 设置hash-max-ziplist-entries 512压缩存储

优化后内存使用降低40%，碎片率从1.7降至1.1。

5. 高级技巧与深度优化

5.1 内存碎片的手动清理

当activedefrag效果不佳时，可以手动触发清理：

# 1. 先执行内存分析 redis-cli memory purge # 2. 必要时重启并加载RDB # 保存数据 redis-cli bgsave # 关闭时强制生成RDB redis-cli shutdown save

重要提示：MEMORY PURGE会阻塞主线程，在大型实例上可能导致秒级延迟，务必在维护窗口操作。

5.2 Redis 7.0新特性实践

Redis 7.0引入了更多内存优化选项：

# 启用新内存分配器 jemalloc-bg-thread yes # 更精细的内存控制 overcommit-memory 1

我们在测试环境中验证，相同负载下7.0比6.0减少约15%的内存碎片。

5.3 监控体系的建立

完善的监控应该包括：

  1. 实时碎片率监控
  2. 惰性删除队列长度告警
  3. 内存使用趋势预测

这是我们使用的Prometheus监控配置片段：

- name: redis_memory rules: - alert: HighMemoryFragmentation expr: redis_mem_fragmentation_ratio > 1.5 for: 30m labels: severity: warning

6. 避坑指南与最佳实践

  1. Key设计原则：

    • 避免使用过长的key（超过32字节）
    • 不同业务使用不同database隔离
    • 设置合理的TTL

  2. 写入模式优化：

    • 批量写入使用pipeline
    • 更新操作使用HSET而非重新SET整个Hash
    • 删除操作优先使用UNLINK

  3. 容量规划建议：

    # 预留30%内存缓冲 maxmemory 14gb # 对于20GB的机器 maxmemory-policy allkeys-lru

  4. 日常维护命令：

    # 定期检查内存状态 redis-cli --latency-history -i 60 # 查找异常key模式 redis-cli --scan --pattern '*tmp*' | xargs redis-cli memory usage

经过这些年的实践，我发现Redis内存管理就像整理一间仓库——需要定期清理、合理分类，并留出足够的操作空间。那些看似"消失"的内存，其实都藏在细节的设计之中。

编程学习 学习日记 实战经验
← 返回列表