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

1、故障分析| bgsave导致redis定 期卡顿案例一那么1、背景线上有套redis主从，版本4.0,开发抱怨说经常会出现周期性卡 顿。应用日志显示每隔10多分钟出现一次，一个普通调用就需要执行1s 左右，然后自动恢复，get/set均受影响ts econtent 今2022-03-11 09:34:222022-03-11 09:3422278 -nio-5151 -exec-9 INFOr- redis se| use: 1047ms2022-03-11 09:34:222022-03-11 09:34:22277 -nio-5151-exec-5 (INFO) redi use: 110

2、5ms2022-03-11 09:34:222022-03-11 09:34:22277 -nio-5151-exec-2 (INFO 厂 redis se| use: 217ms2、诊断查看redis qps和epu监控，均未发现有用线索。登录redis查看slowlog ,也没有吻合时间点的慢查询。evicted_keys指标一直是0 , expired_keys数量虽然很多，但是 一直没有明显波动，不太可能是驱逐过期键导致。经组里同事提醒注意到latest_fork_usec指标，执行一次接近1s 左右，大约每15分钟触发一次bgsave ,和应用出现慢查询的频率大致 吻合，现在初步认定

3、是redis实例定期bgsave导致的应用卡顿。在相当长的一段时间内，我一直认为redis的bgsave衍生出1个 子进程并旦采用copy-on- write机制，不会对redis本身有太多影 响，顶多落盘时占用点10资源而已。潜在瓶颈点出现fork。调用上Under Linux, fork() is implemented using copy - on - wri te pages, so the only penalty that it incurs is the time and memory required to duplicate theparent* s page tables

4、, and to create a unique task structure for the child.如果父进程的页表比拟大，fork()耗时就会相应延长，且redis采 用了单工作进程模型，fork。执行期间会阻塞所有用户请求。当前redis实例的RSS已经到达了 16Gtop - 07:46:06 up 996 days, 16:51,1 user,load average: 0.00, 0.00, 0.02Tasks: 162 total,1 running, 161 sleeping, 0 stopped, 0 zombieCpu(s): 0.5%us, 0.9%sy, 0.0%

5、ni, 98.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 32878868k total, 23987712k used, 8891156k free,394488k buffersSwap: 4194300k total,8180k used, 4186120k free, 5719452k cachedPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND姆丝 root 为 9竺g ：!我8 Q.Q 5” 4死？* s-server页表大小33Mcatyproc/8844/status | grep

6、 - i pte VmPTE? 33840 kB采用strace跟踪一下fork()耗时，在glibc里fork的调用实际 上映射到了更底层的clone系统调用，因指定-e trace:clone# strace - p 20324 - e trace=clone - Tclone (child stack=0,flags=CLONE_CHILDCLEARTIDCLONE_CHILD SETTID SIGCHL D, child_tidptr=0 x7f409d771a!0)130793 于此对应的redis监控指标为latest_fork usee:1014778两者吻合，由此可以确认是re

7、dis定期bgsave引发的。最简单的方法是禁用bgsave ,但这种行为有很大的风险，一旦主库 被误杀且在主从切换前又被迅速拉起，会导致redis数据全部丧失。查看redis的内存利用率，存在很严重的内存碎片，used_memory_human 8. 7Gused 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()