【redis】问题定位与优化

1.fork操作 

redis持久化功能一直影响redis性能的高发地。
fork操作:
当redis做RDB或AOF重写时，一个必不可少的操作就是执行fork操作创建子进程，
对于大多数操作系统来说fork是个重量级操作。虽然fork创建的子进程不需要拷贝
父进程的物理内存空间，但是会复制父进程的空间内存页表。例如对于10GB的redis
进程，需要复制大约20Mb的内存页表，因此fork操作耗时跟进程总内存嘻嘻相关。
如果使用虚拟化技术，特别是Xen虚拟机，fork操作会更耗时。

fork耗时问题定位:对于高流量的redis实例OPS可达5W以上，如果fork操作耗时在
秒级将拖慢redis几万条命令执行，对线上应用延迟影响非常明显。正常情况下fork 
耗时应该在每GB消耗20ms左右。可以在info stats 统计中查 lastest_fork_usec 
指标获取最近一次fork操作耗时，单位微秒。

如何改善fork操作的耗时 
(1)优先使用物理机或者高效支持fork操作的虚拟化技术，避免使用Xen;
(2)控制redis实例最大可用内存，fork耗时跟内存量成正比，线上建议每个redis 
实例内存控制在10GB以内。
(3)合理配置linux内存分配策略，避免物理内存不足导致fork失败。
(4)降低fork操作的频率，如适度放宽AOF自动触发时机，避免不必要的全量
复制等。

2.子进程开销监控和优化

子进程负责AOF或者RDB文件重写，涉及CPU,内存，硬盘三个部分的消耗。
(1)CPU;
CPU开销分析。子进程负责把进程内的数据分批写入文件，这个过程属于CPU密集操作。
通常子进程对单核CPU利用率接近90%;
CPU消耗优化，Redis是CPU密集型服务，不要做绑定单核CPU操作。由于子进程非常消耗
CPU,会和父进程产生单核资源竞争。
不要和其他CPU密集型服务部署在一起，造成CPU过度竞争。
(2)内存 
内存消耗分析:子进程通过fork操作产生，占用内存大小等于父进程，理论上需要两倍
的内存来完成持久化操作，但linux有写时复制机制(copy-on-write).父子进程会共享
相同的物理内存页，当父进程处理写请求时会把要修改的页创建副本，而子进程在fork
操作过程中共享整个父进程内存快照。
内存消耗监控。

--内存消耗优化 
(1)同CPU优化一样，如果部署多个redis实例，尽量保证同一时刻只有一个子进程在工作。
(2)避免在大量写入时做子进程重写操作，这样将导致父进程维护大量页副本，造成内存消耗。

关闭透明大页，防止fork之后，父进程内存大幅增加。
(3)硬盘 
硬盘开销分析。子进程主要职责是把AOF或者RDB文件写入硬盘持久化。必然造成硬盘
写入压力。根据redis重写AOF/RDB的数据量，结合系统工具如:sar,
iostat,iotop，可以分析重写期间硬盘负载情况。

--硬盘开销优化 
不要和其他高硬盘负载的服务器部署在一起。如:存储服务，消息队列服务等。
AOF重写时会消耗大量硬盘IO,可以开启配置no-appendfsync-on-rewrite,
默认关闭，表示在AOF重写期间不做fsync操作。
当开启AOF功能的redis用于高流量写入场景时，如果使用普通机械磁盘，写入 
吞吐一般在100M/s，这时redis实例的瓶颈主要在AOF同步硬盘上。
对于单机配置多个redis实例的情况，可以配置不同实例分盘存储AOF文件，
分摊硬盘写入压力。

配置no-appendfsync-on-rewrite=yes 时，在极端情况下可能丢失整个AOF重写
期间的数据，需要根据数据安全性决定是否配置。

3.AOF追加

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

阻塞流程分析：
(1)主线程负责写如AOF缓冲区 
(2)AOF线程负责每秒执行一次同步硬盘操作。
并记录最近一次同步时间。
(3)主线程负责对比上次AOF同步时间:
如果距上次同步成功时间在2秒内，主线程直接返回。
如果距上次同步成功时间超过2秒，主线程将会阻塞，直到同步操作完成。

--通过对aof阻塞流程可以发现两个问题。
everysync配置最多可能丢失2秒数据，不是1秒。
如果系统fsync缓慢，将会导致redis主线程阻塞影响效率。

4.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 追加阻塞问题主要是优化系统硬盘负载。