Redis被广泛使用的一个很重要的原因是它的高性能。因此我们必要要重视所有可能影响Redis性能的因素、机制以及应对方案。影响Redis性能的五大方面的潜在因素,分别是:
在前面的2讲中,学习了会导致Redis变慢的潜在阻塞点以及相应的解决方案,即异步线程机制和CPU绑核。除此之外,还有一些因素会导致Redis变慢。
这一讲,介绍如何系统性应对Redis变慢这个问题。从问题认定、系统性排查和应对方案这3个方面来讲解。
最直接的方法,查看Redis的响应延迟。通过绝对值来判断,比如执行时间突然增长到几秒。
但是这个方法在不同配置的机器上的误差比较大。第二个方法是基于当前环境下的Redis基线性能做判断。
基线性能指一个系统在低压力、无干扰下的基本性能。
怎么确定基线性能?从2.8.7版本开始,redis-cli命令提供了-intrinsic-latency选项,可以用来监测和统计测试期间内的最大延迟,这个延迟可以作为Redis的基线性能。其中,测试时长可以用-intrinsic-latency选项的参数来指定。
一般来说,运行时延和基线性能对比,如果运行时延是基线性能的2倍及以上时,就可以认定Redis变慢了。为了避免网络对基线性能的影响,直接在服务器端运行。
影响Redis的关键因素有三个:Redis自身的操作特性、文件系统和操作系统。
Redis有两个操作会对性能造成较大影响,分别是慢查询命令和过期key操作。
慢查询命令,就是指在Redis中执行速度慢的命令,这会导致Redis延迟增加。
排查:通过Redis日志、或者是latency monitor工具。
解决方法:
还有一个比较容易遗漏的慢查询命令是KEYS命令,它用于返回和输入模式的所有key。因为KEYS命令需要遍历存储的键值对,所以操作延时高。KEYS命令一般不被建议用于生产环境中。
过期key的自动删除机制,它是Redis用来回收内存空间的常用机制,本身会引起Redis操作阻塞,导致性能变慢。
排查:检查业务代码在使用EXPIREAT命令设置key过期时间时,是否使用了相同的UNIX时间戳。因为这会造成大量key在同一时间过期,导致性能变慢。
解决方法:
在基础篇讲过,为了保证数据可靠性,Redis会采用AOF日志或者RDB快照。其中,AOF日志提供了三种日志写回策略:no、everysec、always。这三种写回策略依赖文件系统的两个系统调用完成:write和fsync。
排查:
解决方法:
如果业务应用对延迟非常敏感,但同时允许一定量的数据丢失,把配置项no-appendfsync-on-rewrite设置为yes:
no-appendfsync-on-rewrite yes
如果的确需要高性能,同时也需要高可靠数据保证,考虑采用高速的固态硬盘作为AOF日志的写入设备。
一个潜在的瓶颈:操作系统的内存swap。
内存swap是操作系统里将内存数据在内存和磁盘间来回换入和换出的机制,涉及到磁盘的读写。
Redis一旦swap被触发,Redis的请求操作需要等到磁盘数据读写完成。并且swap触发后影响的是Redis主IO线程,这会极大地增加Redis的响应时间。
通常触发swap的原因主要是物理机器内存不足。
排查:
首先,查找Redis的进程号:
$ redis-cli info | grep process_id process_id: 5332
其次,进入Redis所在机器的/proc目录下的该进程目录中:
$ cd /proc/5332
最后,运行下面命令,查看Redis进程的使用情况:
$cat smaps | egrep '^(Swap|Size)' Size: 584 kB Swap: 0 kB Size: 4 kB Swap: 4 kB Size: 4 kB Swap: 0 kB Size: 462044 kB Swap: 462008 kB Size: 21392 kB Swap: 0 kB
解决方法:增加机器的内存或者使用Redis集群。
还有一个和内存相关的因素,即内存大页机制(Transparent Huge Page,THP),也会影响Redis性能。
排查:
首先,在Redis实例运行的机器上执行:
cat /sys/kernel/mm/transparent_hugepage/enabled
如果,执行结果是always,表示内存大页机制启动了;如果是never,表示禁止了。
解决方法:关闭内存大页。
echo never /sys/kernel/mm/transparent_hugepage/enabled
总结一份关于Redis变慢的Checklist: