Redis性能分析案例一：RDB引起的linux io负载高问题

一、 背景

反馈linux磁盘IO高，部署在服务器上的服务，响应很慢，需要排查解决；

二、 问题分析及解决

1. 确定是什么进程占用的IO

进入服务器后，直接top分析 ，下图的wa值很高，说明IO负载很高；

进一步查看是哪些进程比较吃IO，发现是redis-sever进程的写IO很高，如下图，那我兴趣就来了，立马准备好了截图记录这个问题的分析过程；

写文件很高，不用确认都知道是Redis的RDB进程，快照内存写入磁盘的过程慢;

2. 为什么要占用这么高

为什么这么吃IO呢？
由上图可知，该进程的写入速度大概是30M/s，那么我们查下RDB文件有多大；如下图大概是4个G； 那么按照30M/s的速度，大概需要耗时40000/30=1333s左右，这个说明的是磁盘写入的速度太慢了，服务器还io报警，我正常的一个window机器的磁盘基本都可以达到近100m/s。所以此刻怀疑是服务器的io能力比较差；

如何验证服务器的IO性能：执行下述命令，意思是往磁盘写入一个G的文件，查看耗时情况，基本峰值在60M/s；

自己的一个linux测试环境测试磁盘性能：370M/s
即本地写入一个4g文件，不到10s;

3. 如何解决

由上述分析可得知，服务器本身的磁盘性能IO比较差导致Redis 的RDB过程写入一个4G的文件到磁盘都很慢，3M/s的写入速度，稍微正常点的磁盘IO 基本可以达达几百M/s，故反馈给运维检查磁盘性能或者更换硬件；

三、总结

      从上述的过程来看，RDB的过程是很依赖磁盘IO性能的，但是RDB的过程是不阻塞Redis的正常的执行，一旦是RDB文件的写入导致的服务器IO高，是会影响到该服务器上的其他服务进程的性能；
      也从另外一个角度来讲，RDB的过程似乎把内存大小控制在4g左右是个比较合理的值，因为内存大的实例，Fork子进程这个过程必然会相对耗时些，同时持续会写入会更长，对磁盘性能是考验；如果内存不足，但是需求很高，并发很高，倒是可以部署多节点的集群模式，即表达的意思是，部署20个4g的redis节点，比部署4个20G的redis集群节点，性能更佳，但是带来的是运维上和机器的成本；