Redis故障检查：延迟测量

目录

网络延迟测量

固有延迟

往返延迟

检查CPU利用率

检查持久化操作

---

      Redis的故障检查，上一篇日志总结到的是找出一些慢查询操作，也就是这些查询花费了很长的时间才能完成，但是这个慢操作识别只记录的是命令执行消耗的时间，不包括网络传输消耗的时间以及磁盘读写消耗的时间，所以，当Redis出现较大延迟问题时，除了检查执行的操作命令外，还应检查一下是否网络延迟、CPU使用率过高或者是持久化操作造成的。

网络延迟测量

固有延迟

      在Redis运行前，我们可以先对运行它的主机进行一次固有延迟的测量，固有延迟指的是操作系统调用进程的最大延迟，它不会连接到Redis服务，所以说它是固有的，是系统的延迟大小，不包括Redis实例的延迟。在Redis部署运行后，其延迟不会比固有延迟还小，因为有诸多因素影响。运行Redis服务的机器上固有延迟也会对Redis服务延迟产生影响，我们可以用命令redis-cli --intrinsic-latency 30来测试本主机的固有延迟：

命令最后的30表示测试时长为30秒，这个数值可以自己指定。

往返延迟

      上面测试的是操作系统的进程调用延迟，除此之外还应测试网络往返延迟，也就是PING命令，我们可以使用redis-cli –latency来测试基础的网络往返延迟：

      测出来的指标有四个，最小值min、最大值max、平均值avg和统计的样本数，单位是毫秒，由上图可以看到，一共统计了2479个样本数据（可以按ctrl+c来停止测试），平均往返延迟是0.21毫秒。不过要注意的是这个命令测试网络时没有加上两端建立连接的时间。

      固有延迟和网络往返延迟都测试完后，我们就可以大概估算出延迟的基线是0.049（约等于0.05吧）+0.21约等于0.26毫秒。

检查CPU利用率

      上面进行的固有延迟测量，是操作系统调用进程的最大延迟，还没连接到Redis服务，也就是说，有时候延迟大，除了检查网络外，还可以检查一下部署运行Redis的主机，看问题是不是出在了主机身上，例如CPU利用率高导致的：

      因为Redis是单进程的，也就是说一个redis-server进程需要占用一个CPU核心，如果大量的客户端连接发生，可能会导致Redis进程对CPU的利用率变高，还有大量的数据操作，或者进行排序，有大量数据却使用了keys *命令而不是scan时，都可能导致CPU占满的情况，造成Redis服务极大的延迟。例如大量的客户端连接，我们可以用命令INFO STATES |grep total_connections_received来检查：

      如果这个客户端连接数在短时间里增大，证明有些客户端频繁地与Redis建立连接，这不仅会增加客户端和服务器端的延迟，还会提高Redis服务器的CPU使用率。

检查持久化操作

       还有一种可能会造成Redis延迟问题的情况是，我们的持久化操作，因为持久化操作是需要读写磁盘的，AOF中系统会调用fsync（）将缓冲区中的数据刷新到磁盘中完成持久化保存，但这个fsync（）是一个阻塞调用，每次往磁盘中写入数据时，需要等待磁盘报告写入完成后才会返回，所以磁盘性能也很重要，如果持久化操作占用时间太长，一样会导致Redis延迟增加。另一方面，在进行AOF重写时（随着AOF文件大小的增加，aof文件越来越大，AOF重写可以对aof文件进行一定的压缩，例如Redis中一些键已经过期或者被删除了，那么在aof文件中该数据的命令就可以不要了），Redis进程会fork（）一个子进程来完成，具体是在子进程中创建一个新的aof文件来存储重写的结果，如果重写的数据量太大，消耗的时间太多，同样会造成Redis高延迟。我们可以通过命令：

INFO |grep aof_delayed_fsync

来查看同步延迟个数，也就是每次发生AOF阻塞事件时，这个指标都会累加。