Redis入门完整教程：问题定位与优化

Redis持久化功能一直是影响Redis性能的高发地，本节我们结合常见的
持久化问题进行分析定位和优化。

5.3.1　fork操作
当Redis做RDB或AOF重写时，一个必不可少的操作就是执行fork操作创
建子进程，对于大多数操作系统来说fork是个重量级错误。虽然fork创建的
子进程不需要拷贝父进程的物理内存空间，但是会复制父进程的空间内存页
表。例如对于10GB的Redis进程，需要复制大约20MB的内存页表，因此fork
操作耗时跟进程总内存量息息相关，如果使用虚拟化技术，特别是Xen虚拟
机，fork操作会更耗时。
fork耗时问题定位：对于高流量的Redis实例OPS可达5万以上，如果fork
操作耗时在秒级别将拖慢Redis几万条命令执行，对线上应用延迟影响非常
明显。正常情况下fork耗时应该是每GB消耗20毫秒左右。可以在info stats统
计中查latest_fork_usec指标获取最近一次fork操作耗时，单位微秒。
如何改善fork操作的耗时：
1）优先使用物理机或者高效支持fork操作的虚拟化技术，避免使用
Xen。
2）控制Redis实例最大可用内存，fork耗时跟内存量成正比，线上建议
每个Redis实例内存控制在10GB以内。
3）合理配置Linux内存分配策略，避免物理内存不足导致fork失败，具
体细节见12.1节“Linux配置优化”。
4）降低fork操作的频率，如适度放宽AOF自动触发时机，避免不必要
的全量复制等。

5.3.2　子进程开销监控和优化
子进程负责AOF或者RDB文件的重写，它的运行过程主要涉及CPU、内
存、硬盘三部分的消耗。
1.CPU
·CPU开销分析。子进程负责把进程内的数据分批写入文件，这个过程
属于CPU密集操作，通常子进程对单核CPU利用率接近90%.
·CPU消耗优化。Redis是CPU密集型服务，不要做绑定单核CPU操作。
由于子进程非常消耗CPU，会和父进程产生单核资源竞争。
不要和其他CPU密集型服务部署在一起，造成CPU过度竞争。
如果部署多个Redis实例，尽量保证同一时刻只有一个子进程执行重写
工作，具体细节见5.4节多实例部署”。
2.内存
·内存消耗分析。子进程通过fork操作产生，占用内存大小等同于父进
程，理论上需要两倍的内存来完成持久化操作，但Linux有写时复制机制
（copy-on-write）。父子进程会共享相同的物理内存页，当父进程处理写请
求时会把要修改的页创建副本，而子进程在fork操作过程中共享整个父进程
内存快照。
·内存消耗监控。RDB重写时，Redis日志输出容如下：
* Background saving started by pid 7692
* DB saved on disk
* RDB: 5 MB of memory used by copy-on-write
* Background saving terminated with success
如果重写过程中存在内存修改操作，父进程负责创建所修改内存页的副
本，从日志中可以看出这部分内存消耗了5MB，可以等价认为RDB重写消耗
了5MB的内存。
AOF重写时，Redis日志输出容如下：
* Background append only file rewriting started by pid 8937
* AOF rewrite child asks to stop sending diffs.
* Parent agreed to stop sending diffs. Finalizing AOF...
* Concatenating 0.00 MB of AOF diff received from parent.
* SYNC append only file rewrite performed
* AOF rewrite: 53 MB of memory used by copy-on-write
* Background AOF rewrite terminated with success
* Residual parent diff successfully flushed to the rewritten AOF (1.49 MB)
* Background AOF rewrite finished successfully
父进程维护页副本消耗同RDB重写过程类似，不同之处在于AOF重写需
要AOF重写缓冲区，因此根据以上日志可以预估内存消耗为：
53MB+1.49MB，也就是AOF重写时子进程消耗的内存量。
运维提示
编写shell脚本根据Redis日志可快速定位子进程重写期间内存过度消耗
情况。
内存消耗优化：
1）同CPU优化一样，如果部署多个Redis实例，尽量保证同一时刻只有
一个子进程在工作。
2）避免在大量写入时做子进程重写操作，这样将导致父进程维护大量
页副本，造成内存消耗。
Linux kernel在2.6.38内核增加了Transparent Huge Pages（THP），支持
huge page（2MB）的页分配，默认开启。当开启时可以降低fork创建子进程
的速度，但执行fork之后，如果开启THP，复制页单位从原来4KB变为
2MB，会大幅增加重写期间父进程内存消耗。建议设置“sudo echo
never>/sys/kernel/mm/transparent_hugepage/enabled”关闭THP。更多THP细节
和配置见12.1节Linux配置优化”。
3.硬盘
·硬盘开销分析。子进程主要职责是把AOF或者RDB文件写入硬盘持久
化。势必造成硬盘写入压力。根据Redis重写AOF/RDB的数据量，结合系统
工具如sar、iostat、iotop等，可分析出重写期间硬盘负载情况。
·硬盘开销优化。优化方法如下：
a）不要和其他高硬盘负载的服务部署在一起。如：存储服务、消息队
列服务等。
b）AOF重写时会消耗大量硬盘IO，可以开启配置no-appendfsync-on-
rewrite，默认关闭。表示在AOF重写期间不做fsync操作。
c）当开启AOF功能的Redis用于高流量写入场景时，如果使用普通机械
磁盘，写入吞吐一般在100MB/s左右，这时Redis实例的瓶颈主要在AOF同步
硬盘上。
343
d）对于单机配置多个Redis实例的情况，可以配置不同实例分盘存储
AOF文件，分摊硬盘写入压力。
运维提示
配置no-appendfsync-on-rewrite=yes时，在极端情况下可能丢失整个AOF
重写期间的数据，需要根据数据安全性决定是否配置。

5.3.3　AOF追加阻塞
当开启AOF持久化时，常用的同步硬盘的策略是everysec，用于平衡性
能和数据安全性。对于这种方式，Redis使用另一条线程每秒执行fsync同步
硬盘。当系统硬盘资源繁忙时，会造成Redis主线程阻塞，如图5-5所示。

 

 阻塞流程分析：
1）主线程负责写入AOF缓冲区。
2）AOF线程负责每秒执行一次同步磁盘操作，并记录最近一次同步时
间。
3）主线程负责对比上次AOF同步时间：
·如果距上次同步成功时间在2秒内，主线程直接返回。
·如果距上次同步成功时间超过2秒，主线程将会阻塞，直到同步操作完
成。
通过对AOF阻塞流程可以发现两个问题：
1）everysec配置最多可能丢失2秒数据，不是1秒。
2）如果系统fsync缓慢，将会导致Redis主线程阻塞影响效率。
AOF阻塞问题定位：
1）发生AOF阻塞时，Redis输出如下日志，用于记录AOF fsync阻塞导致
拖慢Redis服务的行为：
Asynchronous AOF fsync is taking too long (disk is busy). Writing the AOF buffer
without waiting for fsync to complete, this may slow down Redis
2）每当发生AOF追加阻塞事件发生时，在info Persistence统计中，
aof_delayed_fsync指标会累加，查看这个指标方便定位AOF阻塞问题。
3）AOF同步最多允许2秒的延迟，当延迟发生时说明硬盘存在高负载问
题，可以通过监控工具如iotop，定位消耗硬盘IO资源的进程。
优化AOF追加阻塞问题主要是优化系统硬盘负载，优化方式见上一节。

5.4　多实例部署
Redis单线程架构导致无法充分利用CPU多核特性，通常的做法是在一
台机器上部署多个Redis实例。当多个实例开启AOF重写后，彼此之间会产
生对CPU和IO的竞争。本节主要介绍针对这种场景的分析和优化。
上一节介绍了持久化相关的子进程开销。对于单机多Redis部署，如果
同一时刻运行多个子进程，对当前系统影响将非常明显，因此需要采用一种
措施，把子进程工作进行隔离。Redis在info Persistence中为我们提供了监控
子进程运行状况的度量指标，如表5-2所示。

我们基于以上指标，可以通过外部程序轮询控制AOF重写操作的执行，
整个过程如图5-6所示。

 

 流程说明：
1）外部程序定时轮询监控机器（machine）上所有Redis实例。
2）对于开启AOF的实例，查看（aof_current_size-
aof_base_size）/aof_base_size确认增长率。
3）当增长率超过特定阈值（如100%），执行bgrewriteaof命令手动触发
当前实例的AOF重写。
4）运行期间循环检查aof_rewrite_in_progress和
aof_current_rewrite_time_sec指标，直到AOF重写结束。
5）确认实例AOF重写完成后，再检查其他实例并重复2）~4）步操作。
从而保证机器内每个Redis实例AOF重写串行化执行。