好烦，一封报警邮件，大量服务节点 redis 响应超时，又要加班了

因实际应用中出现经常 Redis 超时问题，StackExchange.Redis 在 Github 上 Timeouts 一文从多个方面进行分析，并提供相应的解决方案， 为方便日后再次出现该问题时快速查阅，特写下本文作为技术笔记，同时给英文不太好的程序员（媛）提供参考。

 

对于使用过 StackExchange.Redis 的程序员（媛），经常碰到类似于以下的异常：

Timeout performing GET keyName, inst: 1, mgr: ExecuteSelect, err: never, queue: 2, qu: 2, qs: 0, qc: 0, wr: 0, wq: 0, in: 0, ar: 0, clientName: computerName, IOCP: (Busy=0,Free=1000,Min=4,Max=1000), WORKER: (Busy=4,Free=32763,Min=4,Max=32767), Local-CPU: unavailable (Please take a look at this article for some common client-side issues that can cause timeouts:

即 Redis 执行超时，原因可能为以下几个方面的问题：

一、redis 服务节点受到外部关联影响

redis服务所在服务器，物理机的资源竞争及网络状况等。同一台服务器上的服务必然面对着服务资源的竞争，CPU，内存，固存等。

1、CPU资源竞争

redis属于CPU密集型服务，对CPU资源依赖尤为紧密，当所在服务器存在其它CPU密集型应用时，必然会影响redis的服务能力，尤其是在其它服务对CPU资源消耗不稳定的情况下。

因此，在实际规划redis这种基础性数据服务时应该注意一下几点：

• 一般不要和其它类型的服务进行混部。
• 同类型的redis服务，也应该针对所服务的不同上层应用进行资源隔离。

说到CPU关联性，可能有人会问是否应该对redis服务进行CPU绑定，以降低由CPU上下文切换带来的性能消耗及关联影响？

简单来说，是可以的，这种优化可以针对任何CPU亲和性要求比较高的服务，但是在此处，有一点我们也应该特别注意：我们在 关于redis内存分析，内存优化 中介绍内存时，曾经提到过子进程内存消耗，也就是redis持久化时会fork出子进程进行AOF/