[linux][redis]bgsave引起的latency突刺问题分析

前言： redis启动的时候，可能会提示“WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.” redis的作者antirez的解释：http://ntireza.com/news/84 在stackoverflow上也能找到类似的问题，在执行bgsave的时候，redis的latency监控能看到明显的突刺。 作者看到这个问题后，比较担心THP对虚拟化产生影响，于是做了对比实验，以及分析了这个突刺问题发生的原因。 分析： 1，THP 前文《[linux][memory]hugetlb和hugepage技术分析 》中提到了透明大页，在复现bgsave引起的latency突刺问题的时候，关闭THP的情况下，依然可以复现到突刺现象。鉴于这种情况，先来关闭THP，分析一下bgsave对redis的影响。 2，复现现象 关闭THP：echo never > /sys/kernel/mm/transparent_hugepage/enabled 启动redis-server：redis-server /etc/redis.conf 启动压测：redis-benchmark -t set -n 1000000 -r 1000000 -d 1024 -l 抓取latency数据：while (true); do redis-cli --latency >> latency.log; done 抓取redis的major和minor fault数据：while (true); do ps -o majflt,minflt -p 16321 >>flt.log ; sleep 1; done 启动bgsave：redis-cli bgsave 停止抓取数据，处理 latency.log 执行：cat latency.log | awk '{print $3}' | tr "\n" "," 处理后的数据画图分析：

处理flt.log的数据： cat flt.log | grep -v "FLT" | awk '{print $2}' | tr "\n" "," 处理后的数据，计算minor fault的增量，画图分析：

可见，redis-server的latency增高的时间基本和minor fault的曲线趋势吻合。 Minor fault画图示例python代码： import numpy as np import matplotlib as mpl import matplotlib.pyplot as plt data = [4940016,4940023,4940026,4940029,4940029,4940033,5067128,5176081,5228731,5251478,5261030,5265256,5267831,5268176,5268389,5268470,5268534,5268576,5268584,5268588,5268592,5268593,5268621,5268625] delta = [] cnt = len(data) for index in range(1, cnt) : delta.append(data[index] - data[index-1]) #print "delta = %s"% delta plt.plot(delta) plt.show() 3，bgsave gbsave的实现在redis/src/rdb.c中：

由上面关键代码可以看到，background的save就是fork出来一个子进程执行save，父进程进度对外提供服务。 4，fork Linux的fork实现上，采用了轻量级的fork实现，尤其是内存，采用了COW（copy on write）策略。比如说作者的实验环境上，redis-server执行fork的时候，redis-server有超过1G的内存在运行，如果是完整的fork，则需要拷贝完整的1G的内存。而实际上，很多时候fork之后都会加上exec运行其他的进程（glibc的system函数就是这么实现的），执行exec则会刷新运行环境，那么复制的内存则没有太多价值。为了节约fork的成本，就有了COW策略。 5，minor fault 在内核中，缺页中断导致的异常叫做page fault。其中，因为filemap映射导致的缺页，或者swap导致的缺页，叫做major fault；匿名映射导致的page fault叫做minor fault。 作者一般这么区分：需要IO加载的是major fault；minor fault则不需要IO加载。 上文中提到了fork的COW策略，在执行fork之后，redis-server父进程的page table中也处于写保护状态，执行了大量的redis set命令，就意味着大量的写操作，于是产生了大量的minor fault。 6， redis-benchmark get 对比上述实验，使用 redis-benchmark执行get操作，执行bgsave，latency处理数据看到：

7，解决办法 作者看了madvise和mlock的实现，没有发现有什么好的解决办法。 请教了一个资深DBA朋友，给的建议是在凌晨或者深夜的时候执行bgsave，还有就是使用备机做bgsave操作。