redis超时缘由排查

1.低效操做产生的延迟。单命令操做一半很快不会形成这样，SORT,LREM, SUNION，keys ，＊ 等操做都会影响响应时间。

 

使用进程监控程序（top, htop, prstat, 等...）来快速查看Redis进程的CPU使用率。若是traffic不高而CPU占用很高，八成说明有慢操做。(top -p pid)

 

slowlog 查询引起延迟的慢命令：(默认超过10毫秒就算慢命令) 只针对慢命令进行统计

 

slowly get 10 查看前十条慢命令

 

config get slowlog-log-slower-than  设置慢命令时间（默认10000us） 10ms

 

2.客户端链接数量，默认为10000 ，超过5000就会影响性能

 

3.客户端链接数的限制

 

4.增强内存管理

 

5.命令处理总数的影响：total_commands_processed

 

6.延迟命令查询：

 

文中出现的延迟（latency）均指从客户端发出一条命令到客户端接受到该命令的反馈所用的最长响应时间

 

redis-cli --latency -h host -p port 

 

7.网络和通讯引发的延迟

 

当用户链接到Redis经过TCP/IP链接或Unix域链接，千兆网络的典型延迟大概200us，而Unix域socket可能低到30us。这彻底基于你的网络和系统硬件。在通讯自己之上，系统增长了更多的延迟（线程调度，CPU缓存，NUMA替换等等）。系统引发的延迟在虚拟机环境远远高于在物理机器环境。

 

8.redis使用优化

 

客户机和服务器之间的交互也必然消耗系统相关的延迟，所以在使用redis操做时能够经过捆绑多个命令在一块儿的方式减小客户端和服务端的交互次数。聚合命令象MSET/MGET也能够用做这个目的。

 

9.不要常常的去进行链接与断开的操做，尤为是基于web的应用。

 

尽量的延长与服务器链接的时间

 

10.swap到硬盘操做形成的延迟 /proc/pid

 

由于smaps文件包括有redis进程的多个不一样的的内存映射区域的使用状况（进程的内存布局远不是线性排列那么简单）。

 

cat smaps | egrep '^(Swap|Size)' (grep -e ‘’ -e ‘’)

 

11.AOF 和硬盘I/O操做延迟

 

主redis不建议使用相关的持久化操做，

 

从redis建议打开aof操做

 

由于主从同步是将🐷的内存线dump出来后传给从，从进行内存中load。之后每次同步就是按期进行dump核load？

 

经过设置AOF相关的appendfsync项，可使用三种不一样的方式来执行文件同步（也能够在运行时使用CONFIG SET 命令来修改这个配置）。

 

- appendfsync 的值设置为no，redis不执行fsync。这种状况下形成延迟的惟一缘由就是写操做。这种延迟没有办法能够解决，由于redis接收到数据的速度是不可控的，不过这种状况也不常见，除非有其余的进程占用I/O使得硬盘速度忽然降低。

 

- appendfsync 的值设置为everysec，每秒都会执行fsync。fsync 由一个单独线程执行，若是须要写操做的时候有fsync正在执行redis就会用一个buffer来延迟写入2秒（由于在Linux若是一个fsync 正在运行那么对该文件的写操做就会被堵塞）。若是fsync 耗时过长（译者注：超过了2秒），即便fsync 还在进行redis也会执行写操做，这就会形成延迟。

 

- appendfsync 的值设置为always ，fsync 会在每次写操做返回成功代码以前执行（事实上redis会积累多个命令在一次fsync 过程当中执行）。这种模式下的性能表现是很是差劲的，因此最好使用一个快速的磁盘和文件系统以加快fsync 的执行。

 

大多数redis用户都会把这个值设成 no 或者 everysec。要减小延迟，最好避免在同一个机器上有其余耗费I/O的程序。用SSD也有益于下降延迟，不过即便不使用SSD，若是能有冗余的硬盘专用于AOF也会减小寻址时间，从而下降延迟。

 

若是你想诊断AOF相关的延迟缘由可使用strace 命令：

 

sudo strace -p $(pidof redis-server) -T -e trace=fdatasync

 

12.数据过时形成的延迟

 

redis有两种方式来去除过时的key：

 

- lazy 方式，在key被请求的时候才检查是否过时。 to be already expired.

 

- active 方式，每0.1秒进行一次过时检查。

 

active过时模式是自适应的，每过100毫秒开始一次过时检查（每秒10次），每次做以下操做：

 

- 根据 REDIS_EXPIRELOOKUPS_PER_CRON 的值去除已通过期的key（是指若是过时的key数量超过了REDIS_EXPIRELOOKUPS_PER_CRON 的值才会启动过时操做，太少就没必要了。这个值默认为10）, evicting all the keys already expired.

 

- 假如超过25%（是指REDIS_EXPIRELOOKUPS_PER_CRON这个值的25%，这个值默认为10，译者注）的key已通过期，则重复一遍检查失效的过程。

 

REDIS_EXPIRELOOKUPS_PER_CRON 默认为10， 过时检查一秒会执行10次，一般在actively模式下1秒能处理100个key。在过时的key有一段时间没被访问的状况下这个清理速度已经足够了，因此 lazy模式基本上没什么用。1秒只过时100个key也不会对redis形成多大的影响。

 

总而言之： 要知道大量key同时过时会对系统延迟形成影响。

 

13.redis看门狗形成的延迟

 

CONFIG SET watchdog-period 200 记录延迟事件

 

redis 单实例最大并发听说能够达到写1w+/s,可是这是在本地操做redis，远程redis操做至少相差1/3的数据，所以线上业务如今最大也支持7k＋每秒的读写操做以及。

 

那么若是并发上面没有问题，可是出现redis 的超时问题，就须要进行上面问题的排查啦。

 

reds的客户端链接数；top查看是否reds跑满了cpu；超时时间的设置(timeout/tcp-keepalive);网络延迟；数据量传输

 

测试qps/tps:

 

 /export/servers/redis-2.8.9/src/redis-benchmark -h 172.24.212.224 -p 6379 -c 50 -n 10000 -d 2

 

50个并发连接，10000个请求，每一个请求2kb。算下来最终的QPS为59000/s

 

可是估计线上的redis真实的qps和tps是具体须要考虑到如下几个方面的：

 

1.估计生产的报文大小，使用－d模拟

 

2.使用redis-cli命令查看info total_commands_processed 信息.经过两次时间差进行计算QPS

 

注意：监控reis的每秒操做数

 

经常使用监控redis命令：

 

info commandstats 查看命令状态

 

persistence : RDB 和 AOF 的相关信息

 

stats : 通常统计信息

 

replication : 主/从复制信息

 

cpu : CPU 计算量统计信息

 

commandstats : Redis 命令统计信息

 

cluster : Redis 集群信息

 

keyspace : 数据库相关的统计信息

 

client list       列出当前链接的客户端

 

redis-cli info clients | grep connected_clients 查看客户端已链接个数

 

redis-cli info memory | egrep '(used_memory_human|used_memory_peak_human)'  查看当前使用内存量，和历史最高峰值

 

经常使用监控信息：

 

redis-cli -h 172.24.184.1 -p 6379 info stats | grep total_commands   查看启动到当前处理命令总数

 

redis-cli -h 172.24.184.1 -p 6379 info stats | grep instantaneous_ops_per_sec  每秒操做数

 

redis-cli -h 172.24.184.1 -p 6379 info stats |grep expired_keys                已过时的key数量

 

redis-cli -h 172.24.184.1 -p 6379 info stats |grep net_io_in_per_sec    每秒进出流量(70444byte)0.07M

 

redis-cli -h 172.24.184.1 -p 6379 info stats |grep net_io_out_per_sec

 

redis-cli -h 172.24.184.1 -p 6379 info memory | grep mem_fragmentation_ratio   内存碎片率（若是超大于1表示存在内存碎片／是used_memory_rss与used_memory的比值。小于1说明内存被交换到swap里面去了）

 

1.slowlog 查询引起延迟的慢命令：(默认超过10毫秒就算慢命令) 只针对慢命令进行统计

 

slowly get 10 查看前十条慢命令

 

config get slowlog-log-slower-than  设置慢命令时间（默认10000us） 10ms

 

2.客户端链接数量，默认为10000 ，超过5000就会影响性能

 

3.客户端链接数的限制

 

4.增强内存管理

 

5.命令处理总数的影响：total_commands_processed

 

6.延迟命令查询：

 

redis-cli --latency 

我的公众号，不按期更新技术文章：