开发者社区> 阿里云柳璃> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

阿里云OCS超时问题的分析与解决

简介:
+关注继续查看

之前有用户联系我们阿里云,反映在使用OCS时会出现超时错误,希望我们阿里云技术团队能够帮忙解决。通常用户会将热点数据存放到OCS中,用以提高用户的业务处理响应速度,因此超时问题对于OCS来讲非常敏感,这引起了阿里云OCS团队的重视,随即开始了调查分析。

 

对于一个网络服务,通常导致超时的原因包括:网络抖动、CPU某个核心负载过高、内存不足导致的频繁swap、网卡负载过高、协议BUG导致的回包有误。通过分析,我们发现了客户端自身存在的某些问题导致OCS超时;除此之外,进一步的分析表明在某些特殊情况下OCS自身的一些问题也会导致超时。下面我们来看看阿里云OCS团队的工程师们是怎么样分析并解决这些超时问题的。

在进入技术细节分析之前,先简单介绍一下阿里云OCS的大致工作机制:基于Memcached协议的用户请求从阿里云ECS服务器上发出,通过阿里云SLB(负载均衡)连到阿里云OCS的前端proxy,再连接后端底层的服务器集群进行最终处理。

 

对于超时问题,我们最先考虑问题可能在于客户端到SLB,SLB到proxy之间的网络及协议问题。为了直观分析排查问题,在考虑proxy承受能力之后,我们建议用户不经过阿里云SLB直接连我们的proxy,这样可以直接在服务器抓包了解异常情况时的报文交互,同时也排除了SLB可能出问题的干扰。

在用户将自己的服务器切到我们的proxy上后,我们对每个客户端抓包,其中一台的报文如下:

{67DE13B6-1281-484F-81C1-5830469A6910}

我们看到截图片段中有两个客户端给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\replace\add操作没有任何信息返回,即没有response;而客户端会一直等待这个response,直到抛出超时异常。虽然是个看起来很初级的BUG,但由于它仅在某些特殊情况下出现,所以定位它还是花了一点时间。找到了这个问题,解决起来就容易了。

 

解决了上述客户端负载和尺寸检测BUG的问题,仍有另外的用户给我们报告OCS超时问题。莫非还有其他的原因?

对于新出现的这些超时情况,我们还是采取在客户端抓包的办法,看到的数据如下:

{CDDE6712-1043-4F8D-9892-0E57F60A924C}

从图中可以得知,客户端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服务器上,然后抓包如下:

{91D82219-9995-4403-8E09-27E7017B2668}

 

图中显示在20:58分时,服务端TCP层触发keepalive包,但始终不能发出去。即客户端依然收不到任何信息。在客户端同时抓包,抓不到任何来自服务器11211端口的KeepAlive报文。接下来我们查看客户端的netstat状态如下:

{E5068D42-AE70-4B45-9D52-C821B526828E}

即客户端依然认为自己还处于连接状态,因为没有收到服务器的任何消息。如果此时用户发起请求,仍然会得到最初用户反馈的现象,即继续重传直至超时。

 

看来这个问题还没有解决。我们继续分析,考虑到一个可能性:我们阿里云OCS的客户端都是跑在阿里云ECS上,会不会这里有什么情况?

 

于是我们与阿里云ECS团队的同学沟通了解到:ECS上开启了netfilter,其中一条过滤规则是对于空闲时间大于180s的连接,netfilter会将它从established表中剔除,且不会通知客户端服务器,当客户端或者服务端还在该链接上面发送报文时,NODE将不再转发。

 

至此情况大致明朗了:因为是通过ECS和SLB建立的连接,而ECS和SLB对于连接空闲时间都有各自不同的限制,所以可能出现OCS服务器与客户端之间的KeepAlive包丢失,从而导致超时情况的发生。于是我们把OCS服务器的KeepAlive改为90s,绕过SLB、ECS,启动应用再重新测试,问题解决。

 

 

表面上看起来同样都是OCS超时的问题,其真正的原因却是各不相同。我们在这里描述起来看似很轻松,但是在实际工作中能够迅速及时的解决这些问题却绝非易事。有的很容易就被发现解决,有的原因找起来却是破费脑筋。通过我们阿里云工程师们的努力,能够让用户更好的使用阿里云服务,这是我们工作最大的乐趣和价值所在。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里云ECS使用体验
在申请高校学生免费体验阿里云ECS云服务器后的一些使用体验和感受。
10 0
我的阿里云ECS使用体验
阿里云ECS作为一个性能卓越、稳定可靠、弹性扩展的高级别云计算服务,多为广大学生所体验和使用。在使用ECS进行课程学习的这一短期时间内,我对于这一云服务器有了较以前更深层次的了解,同时根据网页设计与制作课程需要,我在老师的带领与指导下完成了ECS云服务器的注册、网站搭建等操作以及相关的初级运用,对此的体验感很好,自认为也学习到了不少的东西。
53 0
阿里云ECS使用体验
本篇主要涉及阿里云ECS的使用体验和本人的使用方向,以及本人对阿里云服务器的相关使用技巧、感悟。
42 0
阿里云ECS使用体验
作为一名计算机科学与技术系大一新生,在运用阿里云ECS完成《面向对象编程基础》课程的深入学习后分享有关阿里云ECS使用的体验和感想
71 0
阿里云ECS使用体验
我是一名大二学生,主修网络空间安全,在大一一年的学习中初步了解到了一些编程语言和一些软件开发流程,掌握一些基本计算机知识。在大学老师的引导下了解到一些开发知识。偶然之间在技术网站CSDN上看到阿里“飞天加速计划.高校学生在家实践”的活动。便油然而生自我动手的想法。并想在此平台上拓宽自己知识面。得益于阿里云的这个平台,我的学习劲头慢慢的激发出来。
136 0
文章
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载