之前有用户联系我们阿里云，反映在使用OCS时会出现超时错误，希望我们阿里云技术团队能够帮忙解决。通常用户会将热点数据存放到OCS中，用以提高用户的业务处理响应速度，因此超时问题对于OCS来讲非常敏感，这引起了阿里云OCS团队的重视，随即开始了调查分析。
对于一个网络服务，通常导致超时的原因包括：网络抖动、CPU某个核心负载过高、内存不足导致的频繁swap、网卡负载过高、协议BUG导致的回包有误。通过分析，我们发现了客户端自身存在的某些问题导致OCS超时；除此之外，进一步的分析表明在某些特殊情况下OCS自身的一些问题也会导致超时。下面我们来看看阿里云OCS团队的工程师们是怎么样分析并解决这些超时问题的。
在进入技术细节分析之前，先简单介绍一下阿里云OCS的大致工作机制：基于Memcached协议的用户请求从阿里云ECS服务器上发出，通过阿里云SLB（负载均衡）连到阿里云OCS的前端proxy，再连接后端底层的服务器集群进行最终处理。
对于超时问题，我们最先考虑问题可能在于客户端到SLB，SLB到proxy之间的网络及协议问题。为了直观分析排查问题，在考虑proxy承受能力之后，我们建议用户不经过阿里云SLB直接连我们的proxy，这样可以直接在服务器抓包了解异常情况时的报文交互，同时也排除了SLB可能出问题的干扰。
在用户将自己的服务器切到我们的proxy上后，我们对每个客户端抓包，其中一台的报文如下：
我们看到截图片段中有两个客户端给proxy的回报，超过了200ms，这说明客户端负载有问题，经过与用户确认这一情况得到了证实。由此我们知道：某些情况下使用OCS出现超时是用户客户端负载问题导致，只要合理配置客户端就能解决此类问题。
接下来我们进一步调查发现，另外还有一些超时是因为阿里云OCS自身的原因导致的。阿里云OCS对于存储数据的大小是有限制的，即Value最大为1MB。若超出此限制，客户端会收到“Value too large”的错误信息。某些OCS超时错误恰恰是这个尺寸大小导致的。上文提到OCS的处理流程是proxy调用底层后端服务，我们分析OCS代码发现底层后端代码中对报文Value长度的限制是 1000 * 1000字节，而proxy层根据memcached协议是1024 * 1024字节。这种不一致导致当客户端发送的Value长度处于1000 * 1000 ~ 1024 * 1024字节的临界区间时， set eplaceadd操作没有任何信息返回，即没有response；而客户端会一直等待这个response，直到抛出超时异常。虽然是个看起来很初级的BUG，但由于它仅在某些特殊情况下出现，所以定位它还是花了一点时间。找到了这个问题，解决起来就容易了。
解决了上述客户端负载和尺寸检测BUG的问题，仍有另外的用户给我们报告OCS超时问题。莫非还有其他的原因？
对于新出现的这些超时情况，我们还是采取在客户端抓包的办法，看到的数据如下：
从图中可以得知，客户端10.162.108.239到OCS服务器端10.160.124.220的连接在18:06分开始休眠到18:41被唤醒，发起一次Get请求；之后客户端经历多次重试后，TCP才知道连接已断。这期间客户端未从服务器端收到任何报文。
上文提到过，用户的请求要通过阿里云SLB（负载均衡）连到阿里云OCS的多台proxy，再连接后端底层的服务器集群。所以我们考虑是否存在SLB导致超时问题的可能性。
经过与阿里云SLB部门的同学沟通得知，SLB会断开15分钟未活跃的连接，且不会给客户端和服务器发任何FIN或RST报文。这样就可能出现一个问题，即客户端和服务器都认为连接正常。然而当客户端应用层发起一个请求时，该请求被交至TCP层，而TCP层不知道此时链接已经断开，于是重发该请求数次，直到应用层的超时时间到，就返回Timeout。在某些极端情况下，如果应用层没有设过期或者过期时间非常长，就会一直等到TCP层超时才会返回。
在得知了SLB的这个情况后，为了绕开这个问题，我们在OCS服务器上设置了TCP层的keepAlive包。将/proc/sys/net/ipv4/tcp_keepalive_time由默认的7200s改为450s一次。接着我们做测试，客户端连接到OCS服务器上，然后抓包如下：
图中显示在20:58分时，服务端TCP层触发keepalive包，但始终不能发出去。即客户端依然收不到任何信息。在客户端同时抓包，抓不到任何来自服务器11211端口的KeepAlive报文。接下来我们查看客户端的netstat状态如下：
即客户端依然认为自己还处于连接状态，因为没有收到服务器的任何消息。如果此时用户发起请求，仍然会得到最初用户反馈的现象，即继续重传直至超时。
看来这个问题还没有解决。我们继续分析，考虑到一个可能性：我们阿里云OCS的客户端都是跑在阿里云ECS上，会不会这里有什么情况？
于是我们与阿里云ECS团队的同学沟通了解到：ECS上开启了netfilter，其中一条过滤规则是对于空闲时间大于180s的连接，netfilter会将它从established表中剔除，且不会通知客户端服务器，当客户端或者服务端还在该链接上面发送报文时，NODE将不再转发。
至此情况大致明朗了：因为是通过ECS和SLB建立的连接，而ECS和SLB对于连接空闲时间都有各自不同的限制，所以可能出现OCS服务器与客户端之间的KeepAlive包丢失，从而导致超时情况的发生。于是我们把OCS服务器的KeepAlive改为90s，绕过SLB、ECS，启动应用再重新测试，问题解决。
表面上看起来同样都是OCS超时的问题，其真正的原因却是各不相同。我们在这里描述起来看似很轻松，但是在实际工作中能够迅速及时的解决这些问题却绝非易事。有的很容易就被发现解决，有的原因找起来却是破费脑筋。通过我们阿里云工程师们的努力，能够让用户更好的使用阿里云服务，这是我们工作最大的乐趣和价值所在。
