Redis bgsave 线上分析

redis在做RDB（快照）持久化时会fork一个子进程出来，把内存中的数据持久化到磁盘的rdb文件。

线上有个接口响应延迟P99波动较大，后对其进行了优化。响应延迟折线图如下：

优化完成后，P99趋于平稳，平均在70ms左右。

1 思考接口的执行过程

这个接口一共会经过三个服务，最终返回给客户端。执行流程如下：

 

 

按照箭头所示流程，先访问服务1，服务1的结果返回给接口层，在请求服务2，服务2请求服务3，然后将结果返回给接口层。

2 分析

然后分别观察了服务1、服务2、服务3，主要观察的指标如下：

• 服务对外响应延迟
• CPU负载
• 网络抖动

观察后，服务2和服务3的这几个指标都没啥问题。

服务2的对外响应延迟波动情况与接口的波动颇为相似，再针对服务2分析。服务2是个IO密集型的服务，平均QPS在3K左右。

主要的几个IO操作包括：

• 单点Redis的读取
• 集群Redis的读取
• 数据库的读取
• 两个http接口的拉取
• 一次其他服务的调用

集群Redis的响应很快，平均在5ms左右（加上来回的网络消耗），数据库在10ms左右，http接口只有偶尔的慢请求，其他服务的调用也没问题。

最后发现单点的Redis响应时间过长

如图所示，服务2接受到的每次请求会访问三次这个单点redis，这三次加起来有接近100ms，然后针对这个单点redis进行分析。

发现这台redis的CPU有如下波动趋势

基本上每一分钟会波动一次。

马上反应过来是开启了bgsave引起的（基本1分钟bgsave一次），因为之前有过类似的经验，就直接关掉bgsave再观察

3 解决方案

线上的bgsave不能一直关闭，万一出现故障，会造成大量数据丢失。

具体方案如下：

• 先开启这台机器的bgsave
• 申请一台从服务器，并从这台机器上同步数据
• 同步完成后，主节点关闭bgsave，从节点开启bgsave

这样一来，主节点的读写不再受bgsave影响，同时也能用从节点保证数据不丢失。

4 bgsave引起CPU波动原因探索

首先要说一下bgsave的执行机制。执行bgsave时（无论以哪种方式执行），会先fork出一个子进程来，由子进程把数据库的快照写入硬盘，父进程会继续处理客户端的请求。

所以在平时没有bgsave的时候，进程状态如下：

bgsave时，进程状态如下：

最上面CPU占用100%的就是fork出来的子进程，在执行bgsave，同时他完全独占了一个CPU（上面的红框）。

所以得出结论，这个CPU的波动是正常的，每一个波峰都是子进程bgsave所致。

 

RDB为了将数据持久化到硬盘，需要经常fork一个子进程出来。数据集如果过大的话，fork()的执行可能会非常耗时，如果数据集非常大的话，可能会导致Redis服务器产生几毫秒甚至几秒钟的拒绝服务，并且CPU的性能会急剧下降。

这个停顿的时间长短取决于redis所在的系统，对于真实硬件、VMWare虚拟机或者KVM虚拟机来说，Redis进程每占用1个GB的内存，fork子进程的时间就增加10-20ms，对于Xen虚拟机来说，Redis进程每占用1个GB的内存，fork子进程的时间需要增加200-300ms。

但对于一个访问量大的Redis来说，10-20ms已经是很长时间了（我们的redis占用了10个G左右内存，估计停顿时间在100ms左右）。

 

转载：https://zhuanlan.zhihu.com/p/89248752