Redis 阻塞之外在因素

排查Redis自身原因引起的阻塞原因之后， 如果还没有定位问题， 需要排查是否由外部原因引起。 围绕以下三个方面进行排查：

·CPU竞争

·内存交换

·网络问题

CPU竞争

CPU竞争问题如下：

·进程竞争： Redis是典型的CPU密集型应用， 不建议和其他多核CPU密集型服务部署在一起。 当其他进程过度消耗CPU时， 将严重影响Redis吞吐量。 可以通过top、 sar等命令定位到CPU消耗的时间点和具体进程， 这个问题比较容易发现， 需要调整服务之间部署结构。

·绑定CPU： 部署Redis时为了充分利用多核CPU， 通常一台机器部署多个实例。 常见的一种优化是把Redis进程绑定到CPU上， 用于降低CPU频繁上下文切换的开销。 这个优化技巧正常情况下没有问题， 但是存在例外情况，如图所示。

当Redis父进程创建子进程进行RDB/AOF重写时， 如果做了CPU绑定，会与父进程共享使用一个CPU。 子进程重写时对单核CPU使用率通常在90%以上， 父进程与子进程将产生激烈CPU竞争， 极大影响Redis稳定性。 因此对于开启了持久化或参与复制的主节点不建议绑定CPU。

内存交换

内存交换（swap） 对于Redis来说是非常致命的， Redis保证高性能的一个重要前提是所有的数据在内存中。 如果操作系统把Redis使用的部分内存换出到硬盘， 由于内存与硬盘读写速度差几个数量级， 会导致发生交换后的Redis性能急剧下降。 识别Redis内存交换的检查方法如下：

1） 查询Redis进程号：

# redis-cli -p 6383 info server | grep process_id
process_id:4476      

2） 根据进程号查询内存交换信息：

# cat /proc/4476/smaps | grep Swap
Swap: 0 kB
Swap: 0 kB
Swap: 4 kB
Swap: 0 kB
Swap: 0 kB
.....      

如果交换量都是0KB或者个别的是4KB， 则是正常现象， 说明Redis进程内存没有被交换。 预防内存交换的方法有：