登录
首页 >  数据库 >  Redis

Redis磁盘满问题及解决方法

时间:2026-04-09 22:22:35 352浏览 收藏

推广推荐
下载万磁搜索绿色版 ➜
支持 PC / 移动端,安全直达
Redis磁盘满并非偶然故障,而是配置失当(如未设maxmemory、AOF重写阈值过松、过期键堆积、数据与日志混放)与监控缺位共同引发的明确事故信号,典型表现为RDB写入失败、AOF重写卡死及bgsave子进程崩溃;文章直击根源,提供无需重启即可生效的三大应急措施(限内存、调重写阈值、分离存储路径),并详解hz与active-expire-effort的精准调优逻辑,最后给出从磁盘使用率、内存压力、过期键清理效率到持久化状态的多维告警组合策略——帮你把磁盘满从“救火现场”变成可预测、可拦截、可根治的运维常态。

Redis持久化过程中出现磁盘满_合理配置磁盘监控与过期策略

磁盘满不是 Redis 持久化失败的“结果”,而是配置失当+监控缺位共同导致的明确事故信号——RDB 快照写入失败、AOF 重写卡住、bgsave 子进程退出,这些都会直接暴露为 Can't save in background: fork: Cannot allocate memoryFailed to rewrite AOF: No space left on device

为什么 RDB/AOF 会突然把磁盘打满?

RDB 是全量快照,一次 bgsave 会先生成临时文件(如 temp-12345.rdb),再原子替换旧 dump.rdb。这意味着峰值磁盘占用 ≈ 2 × 当前数据集大小。AOF 更隐蔽:重写时会边读旧 AOF 边写新 AOF,同时保留旧文件直到重写完成,高峰期可能三份 AOF 文件并存(original + temp + new)。

常见诱因包括:

  • 未限制 maxmemory,导致内存持续膨胀,RDB/AOF 文件随之暴涨
  • AOF 重写触发条件设置过松(如 auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb),小实例也频繁重写
  • 业务误设超长 TTL 或不设 TTL,过期键堆积后仍占内存,间接推高 RDB 大小
  • 日志/备份文件和 Redis 数据混放同一分区(如都放在 /var/lib/redis

如何用最小改动堵住磁盘满漏洞?

优先做三件事,不改代码、不重启服务也能快速生效:

  • 立即执行 config set maxmemory 4gb(按物理内存 70% 设定),避免内存无节制增长 → 从源头压低 RDB/AOF 体积
  • 检查并收紧 AOF 重写阈值:config set auto-aof-rewrite-percentage 50 + config set auto-aof-rewrite-min-size 256mb,减少小文件频繁重写
  • 确认 dir 配置指向独立大容量分区(如 /data/redis),且该路径下无其他服务日志堆积

执行后用 info persistence 观察 rdb_last_bgsave_status:okaof_rewrite_in_progress:0 是否稳定,再查磁盘使用率是否回落。

hz 和 active-expire-effort 怎么调才能减少过期键对磁盘的影响?

过期键不清理 → 内存不释放 → RDB 文件更大 → 磁盘压力更重,这是隐性传导链。关键参数不是“删得快”,而是“删得稳”:

  • hz 默认 10,对中等规模实例足够;若 INFO stats | grep expired_keys 显示每秒仅删几十个,但 used_memory_human 持续逼近 maxmemory,可 config set hz 20 提升扫描频次
  • active-expire-effort(Redis 7.0+)控制每次扫描的样本量,默认 1,设为 2 可让定期删除更积极,但不要设为 10 —— 这会导致 CPU 使用率突增,反而拖慢 bgsave fork
  • 必须确保 lazyfree-lazy-expire yes(默认开启),否则大 Key 过期会阻塞主线程,进一步延误持久化调度

哪些监控项必须加进告警?

只看 disk usage > 90% 是马后炮。真正有效的指标是组合判断:

  • 磁盘层面:df -h /data/redis | awk '{print $5}' | sed 's/%//' > 85% 触发一级告警
  • Redis 层面:INFO memory | grep used_memory_human 接近 maxmemory 的 90% 时,说明过期/淘汰机制已承压
  • 关键状态:INFO stats | grep expired_stale_perc > 25% 表示定期删除严重跟不上过期速度,需立刻调 hz
  • 失败信号:INFO persistence | grep rdb_last_save_time 停滞超过 1 小时,或 rdb_last_bgsave_status:err 必须人工介入

最易被忽略的是 AOF 重写日志残留:ls -lh /data/redis/appendonly.aof.* 若发现多个带数字后缀的临时文件,说明重写失败后未自动清理,要手动 rm -f appendonly.aof.* 并检查 auto-aof-rewrite-percentage 设置。

今天关于《Redis磁盘满问题及解决方法》的内容介绍就到此结束,如果有什么疑问或者建议,可以在golang学习网公众号下多多回复交流;文中若有不正之处,也希望回复留言以告知!

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>