故障分析 | bgsave 导致 redis 定期卡顿案例一则

作者：任坤

现居珠海，先后担任专职 Oracle 和 MySQL DBA，现在主要负责 MySQL、mongoDB 和 Redis 维护工作。

本文来源：原创投稿

*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

1、背景

线上有套 redis 主从，版本4.0，开发抱怨说经常会出现周期性卡顿。

应用日志显示每隔10多分钟出现一次，一个普通调用就需要执行1s左右，然后自动恢复，get/set 均受影响

2、诊断

查看 redis qps 和 cpu 监控，均未发现有用线索。

evicted_keys 指标一直是 0 ，expired_keys 数量虽然很多，但是一直没有明显波动，不太可能是驱逐过期键导致。

经组里同事提醒注意到 latest_fork_usec 指标，执行一次接近1s左右，大约每15分钟触发一次 bgsave ，和应用出现慢查询的频率大致吻合，现在初步认定是 redis 实例定期 bgsave 导致的应用卡顿。

在相当长的一段时间内，我一直认为 redis 的 bgsave 衍生出1个子进程并且采用 copy-on- write 机制，不会对 redis 本身有太多影响，顶多落盘时占用点 IO 资源而已。

潜在瓶颈点出现fork()调用上

Under Linux, fork() is implemented using copy‐on‐write pages, so the
only penalty that it incurs is the time and memory required to duplicate the
parent's page tables, and to create a unique task structure for the child.

如果父进程的页表比较大，fork()耗时就会相应延长，且 redis 采用了单工作进程模型， fork()执行期间会阻塞所有用户请求。

当前 redis 实例的 RSS 已经达到了16G

页表大小33M

cat /proc/8844/status | grep ‐i pte
VmPTE: 33840 kB

采用 strace 跟踪一下fork()耗时，在 glibc 里 fork 的调用实际上映射到了更底层的 clone 系统调用，因指定-e trace=clone

# strace ‐p 20324 ‐e trace=clone ‐T
...
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHL D, child_tidptr=0x7f409d771a10) = 30793 <1.013945>
...

于此对应的 redis 监控指标为

latest_fork_usec:1014778

两者吻合，由此可以确认是 redis 定期 bgsave 引发的。

最简单的方法是禁用 bgsave ，但这种行为有很大的风险，一旦主库被误杀且在主从切换前又被迅速拉起，会导致 redis 数据全部丢失。

查看 redis 的内存利用率，存在很严重的内存碎片，

used_memory_human 8.7G
......
used_memory_rss_human 16.1G

这套 redis 马上就要迁移，新环境实例的 RSS 只有8.8G，latest_fork_usec 指标也下降达到了0.25s左右，和开发确认后可以满足应用需求，迁移后应用的定期卡顿现象有了很明显的缓解。

redis 4.0 引入了碎片自动回收功能，由参数 activedefrag 调控，默认关闭。迁移后对老 redis 开启了 activedefrag(其余参数保持默认值)，最终 used_memory_rss_human 固定在11G左右，latest_fork_usec 在0.76s左右。新环境以后也可能会遭遇严重内存碎片，届时要么开启activedefrag，要么在维护时间段重启实例，后者效果显然更好一点。

3、小结

我们线上 redis 主从都开启了 bgsave ，之前一直忽视了bgsave/fork()可能引发的性能波动，最好的解决办法就是控制单个 redis 的内存上限，如果业务端无法瘦身可以考虑 redis cluster 或者设置 maxmemory 。以后如果遇到了 redis 定期卡顿现象，可以优先从 latest_fork_usec 监控指标入手。